Buried in a dbt Labs post from early August is a number worth stopping on. Reading one sales call transcript cost them about $0.25 in tokens. One call, up to 50,000 tokens. They had over 500 million tokens of Gong transcript data and hundreds of salespeople querying it all day.

So dbt did the boring data-team thing. They pulled the raw transcripts into the warehouse, modeled a summary of each call, and served the summaries instead of the transcripts. Token cost fell by roughly 98%. Data volume shrank 20x. A 60-minute call went from tens of thousands of tokens to a few hundred.

They call this context engineering, and the pitch is that it's cheaper and better. No trade-off.

The number is real. What it proves is narrower than the headline suggests, and the honest version is more useful to you than the marketing one.

98% off what, exactly?

Every savings percentage has a denominator, and this one is the worst-case baseline: pushing a full raw transcript into the model's context every single time someone asks a question. Against that baseline, almost any intervention looks miraculous.

Do the arithmetic on dbt's own figure. Twenty-five cents for 50,000 tokens works out to $5 per million input tokens, which is frontier-tier pricing. Run the same read on a small model and the cost drops by most of an order of magnitude before you've modeled anything.

Then stack the cheap fixes that don't require a data warehouse at all. Prompt caching cuts repeated input dramatically. Batch processing is half price on most vendors. Picking a smaller model for a summarization pass is another large multiple. None of that is architecture. It's configuration.

So a chunk of the 98% is a story about what dbt was doing before, not about what warehouses uniquely enable.

Anthropic hit the same number without a warehouse

Here's the detail that should make you cautious. In November 2025, Anthropic published a token reduction of 98.7% on an agent workflow, taking it from about 150,000 tokens to 2,000. Their fix was progressive disclosure: stop loading every tool definition upfront, let the agent discover tools on demand, and filter intermediate results before they hit the model.

No warehouse. No data modeling. Different mechanism entirely, near-identical headline number. Anthropic's worked example is even the same artifact, a sales call transcript, and they note a two-hour meeting can burn an extra 50,000 tokens when the transcript passes through context twice.

When two unrelated fixes both land on 98%, the number is telling you about the baseline, not about either fix.

The useful part is that these two approaches solve different problems and compose rather than compete. Anthropic's targets tool-definition bloat and intermediate results. dbt's targets the size of the payload itself. Cloudflare arrived at the same code-execution conclusion independently. If your context window is drowning in schemas from fifteen connected MCP servers, a warehouse summary table will not save you.

The cost didn't vanish, it moved to your warehouse bill

Summarizing 500 million tokens is LLM inference. Somebody runs it, and somebody pays for it.

On Snowflake, AI functions bill in AI Credits per million tokens, and for generative functions like AI_COMPLETE both input and output tokens are billable. Snowflake moved to a separate AI Credit currency on April 1, 2026. Per-model rates live in the Service Consumption Table rather than the headline pricing page, and the spread across models is enormous. BigQuery and Databricks have their own equivalents with their own meters.

So the shape of the win is amortization, not compression. You pay a large one-time read, then divide it across every agent read that follows. dbt's own best-practice framing is read once, serve many, and there's a divisor sitting in that sentence.

	Direct MCP to source	Warehouse context layer
Where cost lands	Model vendor, on every read	Warehouse AI credits, once per refresh
Scales with	Questions asked	Source records ingested
Breaks when	Query volume is high	Queries are unpredictable
Freshness	Always live	As fresh as your last run

dbt had hundreds of salespeople hitting the same data many times a day. That's a large divisor. If ten people query a table twice a month, you will spend more building the context layer than you ever save on it.

What's new, and what's analytics engineering with a new business card

The rebrand is right there in the source. dbt describes context engineering as the same skillset as analytics engineering, and their four-step recipe (compress, enrich, describe, govern) is a dimensional modeling checklist with a fresh label. If you've built a conformed dimension, you already know how to do this.

Two things are genuinely new, though, and they matter.

Unstructured data became economically modelable. Warehouse-native LLM functions mean transcripts, PDFs and support tickets can go through an ordinary pipeline and come out as queryable tables. Data teams spent a decade correctly ignoring text because the tooling made it infeasible. That reason expired.

The consumer changed. A dashboard gets read by a person, sometimes. A context table gets read by many agents, concurrently, all day. That inverts the ROI math on modeling work that wasn't worth doing for BI, which is exactly what dbt reports happening with their Gong data.

On provenance: this post follows dbt Labs' merger with Fivetran, completed June 1, 2026, and its conclusion is to buy ingestion and modeling from the merged company. That doesn't make the mechanism wrong. It does mean the 98% arrives with no published methodology, no defined baseline, and a claim of maintaining or improving quality that is asserted rather than measured.

The precondition nobody puts on the slide

dbt notes, almost in passing, that their users were converging on near-identical questions against near-identical data. That sentence is the whole precondition.

Pre-summarization is a bet on query predictability. Summarizing is lossy by definition: you decide in advance which signal survives. When tomorrow's question needs the detail you discarded, the agent goes back to the raw source and you pay full freight anyway, plus the cost of the summary that didn't help.

The other thing worth noticing: dbt says the actual forcing function was running out of Gong API calls. Not the invoice. The vendor's rate limit. That's a far more common trigger than a finance team spotting token spend, and it's the one to watch for in your own stack.

What this means for you

• Calculate your fan-out before you build. Reads per summarized record per month. If that number is small, caching and a cheaper model will beat a context layer on both cost and effort.
• Exhaust the config-level fixes first. Caching, batch mode, and right-sizing the model for the summarization pass. Establish what your real baseline is before accepting anyone's percentage.
• Ask vendors for rate limits, not just prices. Per-endpoint quotas are what actually stop you. Get them in writing during procurement, not during an incident.
• Treat context tables as models, with tests and freshness SLAs. For each one, document what question it answers and what you threw away to make it small. That second list is what you'll need when the summaries stop being enough.
• Interrogate every token-reduction claim with three questions. What was the baseline, which model was it running, and how was output quality measured?

Every token-savings number has a divisor hiding inside it. Find yours before you believe the percentage.

Frequently asked

Is context engineering just analytics engineering renamed?

Mostly, and dbt says so themselves: same skills, same modeling patterns. What's actually new is that unstructured data is now cheap enough to model, and that the consumer is a fleet of agents rather than a person with a dashboard.

Does serving agents from a warehouse always cut token costs?

No. It shifts cost from per-query model spend to per-record warehouse inference. The saving depends entirely on how many times each summarized record gets read. Low read volume means you pay more, not less.

Should I disconnect my vendor MCP servers?

Not on the strength of one number. Direct MCP is the right call for live, low-volume, unpredictable queries. The warehouse pattern wins on high-volume, repetitive questions over data you already ingest.

What's the difference between dbt's approach and Anthropic's code execution?

dbt shrinks the payload before it reaches the model. Anthropic shrinks tool definitions and keeps intermediate results out of context. They address different sources of bloat and can be used together.

Related reading

• Snowflake Cortex cost control
• MCP servers for data teams
• dbt vs SQLMesh
• RAG vs long context windows
• Iceberg as an open table format

Sources

• dbt Labs - From analytics engineer to context engineer - 98% claim, $0.25 per transcript, 20x cut
• Anthropic - Code execution with MCP - 150k to 2k tokens, progressive disclosure
• Snowflake - Cortex AI function cost - input and output both billable
• Snowflake - AI pricing overview - AI credits per million tokens
• Fivetran - merger completion release - merger closed June 1, 2026
• Cloudflare - Code Mode - independent convergence on code execution
• TechTarget - Fivetran and dbt Labs merger - independent confirmation of terms

Snowflake's per-model AI Credit rates live in Table 6 of the Service Consumption Table and change over time. Figures cited from third-party cost analyses are directional; check the Consumption Table before budgeting.