This is episode two of the Roundup, a recurring conversation between Tristan Handy and Jason Ganz to cover data and AI news at the speed it moves. Four stories this time: 1) whether the AI buildout is a bubble; 2) what two new benchmarks say about how good agents have gotten at data engineering work; 3) why Stripe just paid $7 billion for an AI model router; 4) and how dbt can turn Gong data into something an agent can use without burning through the budget.
dbt Summit 2026 is almost here. Connect with the world’s largest gathering of dbt users, September 15-18 at The Cosmopolitan in Las Vegas. Level up your data and AI work: Register now.
Listen now: Spotify · Apple Podcasts · YouTube · Amazon Music · RSS
Topic one: Are we in an AI bubble?
Exponential View, the research operation Azeem Azhar built out of what used to be a newsletter, tracks five gauges to answer the bubble question with something other than vibes: economic strain (capex as a share of GDP), industry strain (investment relative to leverage), revenue, revenue growth, valuation heat, and funding quality.
In the update Azhar and Nathan Warren published Aug. 19 , the verdict is boom, not bubble: no gauge is in the red, two are in amber, and the rest are green. Funding quality is the one worth watching. AI capex has moved from hyperscaler cash flow into debt markets and now into equity raises, which pushes risk further out. Revenue is still doubling roughly every seven months, and capex remains under 1% of GDP, well below the 2.5% seen during the railroad build-out.
Condensed transcript
Tristan Handy: I want to start with the most recent Exponential View “are we in a bubble yet” gauges. For folks who don’t know it, Exponential View started as a newsletter about twelve years ago, written by a guy named Azeem Azhar, and has turned into more of a full-stack research operation, in the model of something like SemiAnalysis.
A couple of times a year they publish five gauges on whether AI is in a bubble: economic strain, which is total capex as a percentage of GDP; industry strain; the ratio of investment to revenue; revenue growth, how long it takes to double revenue; valuation heat, the price-to-earnings ratio; and funding quality. Spoiler: the five gauges say no, we’re not currently in a bubble.
Since the last update, these metrics have all moved flat or positive, meaning we’re less likely to be in a bubble than before. The one moving the wrong way, still yellow but drifting toward red, is funding quality. The original AI capex came out of the hyperscalers’ own cash flow. Then the debt markets got tapped, which is a bit riskier. Now it looks like the debt markets are getting tapped out too, and Google and a couple of others are actually raising equity to fund the buildout.
I found it interesting that capex is still below 1% of GDP, well under the 2.5% during the railroad build-out, and we’re doubling revenue every 0.6 years. It’s surprisingly healthy given the level of heat everyone assumes is happening.
Jason Ganz: It’s astonishing. I’ve been an LLM and AI booster since before ChatGPT, but ChatGPT was when it clicked that we’ve fundamentally altered the trajectory of technology, that there’s real enterprise value here. You always bring a quantitative lens to this, and I appreciate that, but I also like to read the vibes of public and industry opinion as they seesaw. There’s a very predictable pattern where it’s just time for the vibes to shift.
When GPT-5 came out, it was roughly on trend, but the narrative became “GPT-5 is a disappointment,” and that sparked the whole “AI is a bubble” wave last summer. A couple months later Opus 4.5 came out and we hit real revenue acceleration, and the vibe flipped to “this growth is unheard of.”
Now we’ve hit the point where the financial growth has been so impressive for so long that there’s a kind of narrative fatigue setting in, independent of the actual numbers. It was funny yesterday watching people call OpenAI’s revenue growth disappointing because it was “only” 19% quarter-over-quarter and “only” a billion dollars of added revenue.
Tristan Handy: You might as well wrap it all up and go home.
Jason Ganz: Right. So to a certain extent this all feels vibes driven. The one indicator that fits with funding quality, and I’ll admit this isn’t my area of expertise, is real yields on U.S. treasuries ticking higher. For years real yields kept going down, and now there’s an uptick. This was predicted a couple of years ago as a sign of either a bubble, or of transformative AI being close, since the future value of capital would rise either way. Something is happening. It’s frustratingly difficult to tell which story it is.
Tristan Handy: The is-it-or-isn’t-it-a-bubble conversation has been going for three years now. It’s short-term interesting, because a revenue slowdown in a now capital-heavy industry has real downstream effects on jobs.
But over the long term, what’s happening here is a big deal for human society, and the 40-year timeline doesn’t really care whether we’re technically in a bubble. Railroads had a bubble and still transformed the economy forever. The dot-com bubble happened and we’re still running the internet on dark fiber that WorldCom laid in the late nineties. Bubbles still create productive outcomes.
Even if there were an AI bubble, we’d still see the growth in power generation that’s happening as a result of this buildout. I’m a little ambivalent about the actual answer. I’m glad the industry looks healthy. But even if it weren’t, I’d be excited about everything happening here. It’s not going away.
Jason Ganz: That’s an important point, because I still talk to people who believe that because we’re in a bubble, the changes to our workflows and our industry should be expected to be temporary.
Tristan Handy: Right. It’s not temporary.
Jason Ganz: And when it “goes away,” they think they can go back to how things were. I’m sympathetic to that impulse, because the magnitude of what we’re dealing with is genuinely big. But people are poorly served by media that lets them conclude this is a bubble and therefore they don’t need to reckon with how it’s going to change their industry or education or anything else. Maybe large-scale regulation changes that, but a financial correction, even a large one, won’t undo it.
Topic two: Two new benchmarks say data engineering agents are ready
Data work has lagged software engineering when it comes to good benchmarks, and two arrived in the last two weeks. Snowflake open-sourced data-eng-bench: 103 dbt-specific tasks run against a simulated 579-table retail warehouse. In Snowflake’s own numbers, Opus 5 cleared 70%+ Pass@1 and GPT 5.6 Sol landed around 65%, with the agent harness itself accounting for a meaningful chunk of the spread.
Separately, Hex’s Izzy Miller has been running a benchmark against Shorelane Commerce, a fully simulated, deliberately messy business built to test open-ended analytical questions, and shared results showing a distinctive overthinking curve on the hardest questions.
Condensed transcript
Jason Ganz: We’re going from macro to deep in the details. How good models are at doing data work specifically, not just general knowledge work, is something I’ve been frustrated by the lack of good benchmarks for. Compare it to software engineering, where there are fifty new benchmarks a day.
We’ve been flying blind on how good agents are at the actual work of a data practitioner: building and maintaining pipelines, updating a dbt DAG, answering a well-specified or a higher-level analytical question. The good news is we got two pieces of high-quality work on this in the last two weeks. The first is a benchmark from Snowflake’s AI research team, called data-eng-bench.
Tristan Handy: Very creative.
Jason Ganz: It’s similar to, and draws on, the work we published last year on ADE-bench. It’s a bundle of tasks testing whether models can do your dbt work. They built a simulated business for it. One of the problems benchmarks like this consistently run into is finding a data source that’s complicated enough.
Tristan Handy: And messy enough.
Jason Ganz: Exactly, and messy enough. It has just over a hundred tasks, and it’s interesting to see new data points on how models perform, compared across models and across harnesses.
Tristan Handy: What were the tasks? Were they true data engineering and analytics engineering tasks, the kind of thing you’d do to build your gold layer, or more in the conversational analytics space?
Jason Ganz: Building and maintaining your gold layer. They split it into build tasks, author new models and keep the pipeline running, further divided into greenfield, scaffolding a new dbt project from nothing, and brownfield, adding a model into an existing multi-layer project, and fix tasks, where something’s broken and needs to be repaired.
Tristan Handy: And these tasks were actually dbt related?
Jason Ganz: All of them, yes. A hundred and three tasks of two variants. Each gives the agent a natural-language instruction, a starting dbt project, and the data warehouse.
Tristan Handy: What was their conclusion on how good agents are today?
Jason Ganz: This is where it gets interesting, because it’s no longer a simple “agents can or can’t do this.” There’s the model, and within the model, how much compute you’re allocating to it, since they all run at different thinking levels. Then there’s the harness.
This is all still assuming the information lives in a single repo, which won’t hold as we see more benchmarks like this, since it’s really about systems and loops and how business context gets fed in. They measure Pass@1, the percentage of tasks completed on the first try, and Pass^3, completing three of three consistently. The scores are hovering in the 60s to 70s.
Based on how every benchmark like this has trended, once scores hit that range they climb quickly into the 80s and high 90s, then taper off from diminishing returns.
Tristan Handy: Any standouts on models or harnesses?
Jason Ganz: No Fable on this one, looks like they didn’t spring for that budget. Opus 5 topped the list above 70% accuracy, GPT 5.6 Sol came in around 65%. Props to the Snowflake team for open-sourcing it; I’d like to see it run against GLM and the emerging set of open models.
The pattern we’re seeing, and we’ll see it again in the next benchmark, is that there’s a premium to the most expensive models on well-specified tasks, but smaller models do fine too. It’s when you hit things that require more human-like judgment, figuring out the question behind the question, that things get harder.
Tristan Handy: Hit me with the second benchmark.
Jason Ganz: This one asks how good models are at answering thorny, complicated data questions, not “update my dbt project” but “Jason, figure out why people aren’t upgrading from dbt 1.11 to 1.12” as a question posed straight to an agent instead of to me.
Tristan Handy: Gotta stay on message.
Jason Ganz: This was released by Izzy Miller at Hex. He built a simulated company based on years of real data problems, and the data is deliberately messy: labels that changed due to a system migration, IDs that don’t match.
What he found is that models are really good when the answer is somewhere in the dataset and you just need to keep chugging and trying new angles, which ties back to the Hugging Face story from last week about models getting persistent.
What they’re not good at is saying “I don’t know” or recognizing that a question needs reframing. The other interesting thing: there’s an overthinking curve with Opus 5, scoring around 70% at low effort, climbing to about 87% at high effort, then dropping back to around 70% at max effort. Sonnet 5 shows the same pattern. Fable, interestingly, just keeps climbing the more tokens you give it.
Tristan Handy: I saw something similar with the Qwen 3.8 release, performance increasing with more tokens and then degrading, the same overthinking territory. Interesting that Izzy saw it too. What’s your meta takeaway on where model and harness capability actually stands for data engineering agents right now?
Jason Ganz: If you can give a bounded task and surface the right data or context, models can perform arbitrarily complex data modeling and analysis to a pretty high standard. The worst model on the Hex benchmark, Kimi K2, still hit 50%. So we’re clearly at the point where a well-specified problem gets you a good shot at a real result.
The interesting questions now are what we actually want to ask, when it’s useful to ask it, and what we build now that this capability is something we can rely on. The last twelve to eighteen months have been proving out that we can get high-quality coding agents for our pipelines and high-quality data analysis back. The answer is yes. So the frontier now is what we build knowing that.
Tristan Handy: Good framing: we can now do the things we could do before, fairly reliably. The big caveat is that you need to be doing well on your fundamentals. All of this relies on a high-quality gold layer, real context around it, a real semantic layer. If you have that, you’re in good shape, and if you don’t, agents can help you build it, but the fundamentals are as necessary as they’ve ever been. Then we get to the actually interesting part: how this changes the way we use analytical data in organizations, which we’ll be answering for years.
Topic three: Stripe buys OpenRouter for $7 billion
Stripe acquired OpenRouter for more than $7 billion on August 17, roughly 90 days after the company had raised at a $1.3 billion valuation. OpenRouter runs $140 million in annualized revenue at a 70% gross margin, unusual for an AI company, because it owns no GPUs. It routes requests across 500-plus models and 80-plus providers, handling failover, price and latency optimization, and provider health.
Condensed transcript
Jason Ganz: Let’s talk about OpenRouter. How are we going to pay for all those tokens, and which model should we use?
Tristan Handy: The news, as of August 17, is that Stripe acquired OpenRouter for $7 billion. Not bad, given the company raised at a $1.3 billion valuation just 90 days earlier. The numbers are good, $140 million of annualized revenue at 70% gross margin, which is unusual for an AI company.
It’s because OpenRouter has no GPUs. It’s not a model provider, it’s an infrastructure provider, and it turns out infrastructure companies can carry software-company gross margins at scale. Clearly a very successful acquisition for the team.
The interesting question is what this means for the rest of us. I went straight to: do people actually need OpenRouter, or something like it? I’d recently implemented some basic model-switching in an agent I built, wanting to avoid the most expensive model for every task, and a lightweight wrapper wasn’t that hard to build.
So I was digging into whether this is a real business people need, and I asked ChatGPT to lay out what OpenRouter does: it advertises 500-plus models and 80-plus providers, it can route across multiple hosts serving the same model, avoid unhealthy providers, optimize for price, latency, or throughput, and fail over automatically. That’s a list of things I’d never build into my toy version. It’s genuinely interesting infrastructure, and a smart strategic acquisition for Stripe specifically, because the two businesses are similar.
Stripe’s whole job is making the complexity of moving money disappear, charging a percentage for it. OpenRouter’s job is making the complexity of model selection and routing disappear, charging about 5.5% for it. Maybe this becomes as boring and commonplace as payments infrastructure did once Stripe made it stupidly easy.
Jason Ganz: There’s a temptation to see model switching as two extremes: fully locked into one frontier lab, with all your evals and context engineering tuned to their best practices, or fully model-agnostic, fluidly switching the moment the Pareto frontier shifts. My guess is we land in the middle.
For your large-scale core workflows, you’ll build a relationship with one or two providers. But it’s really an ecosystem of different tasks, and some percentage of your workload is a long tail where OpenRouter makes total sense. What do you think?
Tristan Handy: Whether workloads can really become portable across models is a fascinating question. I recently spoke with a company called LightLLM that’s trying to make different models functionally equivalent to one another, changing how the prompt itself gets supplied.
I don’t fully understand the mechanics, but if intelligence becomes a substrate the way raw compute became one you could rent from the cloud, these services should become at least somewhat transferable. Was it historically inevitable that you could take a Docker image from EC2 to GCE? Someone had to solve that, and it feels like a necessary precondition for the internet we live in.
Jason Ganz: I buy that, but today the shape of GPT-5.6 Sol’s intelligence is genuinely different from Opus 5’s. Do these converge, so a workload on one looks like a workload on the other, or do they keep meaningful differences based on training strategy, constitutional AI versus whatever OpenAI does differently?
Tristan Handy: Congrats on working that in.
Jason Ganz: Ideally this looks like a utility. If I switch electricity providers, I want the electricity to be the same. It’s an open question how much fluidity we actually get at the highest layers. There will always be some addressable share of workloads; it’s a question of what percentage.
Tristan Handy: I’m bullish long term on the category OpenRouter represents, though that’s a long-term statement and it’s not settled. Benchmarks are a kind of evolutionary pressure, the environment models evolve inside of. To the extent every model responds to the same pressure, they converge on some time horizon. Or you get models explicitly tuned for different conditions, one class great at coding, another at something like conversational nuance.
Either way, the intelligence Stripe is going to extract from the roughly 50 trillion tokens a month flowing through OpenRouter, and growing, is going to be genuinely fascinating.
Jason Ganz: If you’re a data analyst at Stripe and want to come talk to us about tokenomics, let us know.
Topic four: Turning Gong calls into dbt models
Britton Stamper, who recently joined dbt Labs for AI enablement work, published a piece applying dbt’s own patterns to a problem that shows up the moment teams point agents at unstructured data. Giving an entire sales team direct access to a Gong MCP server means everyone re-runs the same expensive analysis, burns through API limits, and pays for the same tokens repeatedly.
Condensed transcript
Tristan Handy: Where are we going from here?
Jason Ganz: A good way to close. In the benchmarking section we talked about models getting good at what data orgs are already doing, with fundamentals still mattering. Now there’s an emerging category of things that can be done at all. The last thing I want to cover is in-house.
Britton Stamper, who joined dbt Labs and Fivetran recently for AI enablement, has been doing fascinating work applying the traditional levers of data and analytics engineering to context engineering at scale. He’s published a series of posts walking through real workloads on our actual data and the deliverables that would have previously been impossible.
First off, do you buy that data practitioners have a meaningful role in distributing context, and that this is part of the next level of unlocks we’ve been talking about?
Tristan Handy: Yes, absolutely, with one caveat. Context engineering is one of those terms where three different communities use the same word to mean different things, and sometimes don’t even realize it.
The context engineering that data and analytics engineers are highly relevant for is context engineering for analytics and data use cases specifically. There’s also the context engineering that happens inside something like Claude Code, managing your session, compaction, caching, and data and analytics engineers have essentially nothing to do with that, which is fine.
As long as we hold that caveat, yes, our people, you and me included, are very relevant here. Part of it is doing everything we’ve always done, but anticipating that agents will be the consumers, so we can’t skip steps or assume human cultural knowledge will paper over missing descriptions or tests. But there’s also a set of genuinely new things, and that’s where Britton is going.
Jason Ganz: Exactly right. The new things are roughly unstructured or semi-structured data, where analysis used to be impractical. Britton’s workflow is Gong calls. Gong is what most sales teams use to navigate customer calls and surface blockers and questions.
Historically, answering something like “Why aren’t people upgrading from dbt 1.11 to 1.12” would have meant manually watching tape, or doing rudimentary natural-language analysis, but you couldn’t pull out something like the top three customer asks in healthcare. That became genuinely practical with the combination of an LLM and the right context.
Tristan Handy: Can I interject? I was just talking to someone deeply involved in evaluating how different data platforms handle these queries, and while it’s more possible than ever, the implementations are still fairly naive. You can burn through a lot of credits or DBUs quickly if you’re not careful, so make it an incremental dbt model so you don’t blow through your credit budget.
Jason Ganz: Exactly, that’s what Britton’s talking about. The naive way is hooking the whole sales team up to the Gong MCP directly and letting everyone ask their own questions. You end up scanning hundreds of thousands of tokens repeatedly for the same requests and hitting API limits.
What Britton’s done instead is take the most common, relevant queries people ask of Gong data and aggregate them into our dbt project, incrementally. It’s an old pattern: instead of everyone recomputing the same analysis and wasting compute and tokens, you build the standard reporting once on data sources that would have been infeasible to analyze at all before. That doesn’t mean you never connect directly.
Prepping for a specific call and asking “remind me what I said last time” is a great MCP use case. It’s the larger-scale, pattern-level analytical queries where the dbt approach wins.
Tristan Handy: I think the entire world of unstructured data is going to become legible quickly, and that’s good for vendors, practitioners, and companies.
Structured and unstructured data have been separate worlds for basically forever, different tools, different technical cultures, with almost no cross-pollination, even though the underlying mental models are the same. I’m excited about the technical details, but even more that we might finally bring these two communities together.
Jason Ganz: Agreed. It’s hard to draw an exact roadmap for where this goes, but it feels like where conversational analytics or agentic development on dbt models was a year ago: just starting to be possible. If you want to build on the forefront, this is the area to watch, because the foundational patterns and best practices are probably going to get written over the next twelve to eighteen months.
Tristan Handy: Totally agree. The database eats everything, Jason. That’s the conclusion.
Jason Ganz: That’s the conclusion. And if you’re listening to this and thinking you’d like to hang out with Tristan, Jason, and Britton in person to talk about it: in about a month at dbt Summit, we’re having a live fireside chat on exactly this topic.
Tristan Handy: We just added it to the agenda. I’m excited, it’s going to be fun.
Please reach out at podcast@dbtlabs.com for questions, comments, and guest suggestions.
Chapters
Timestamps are approximate.
00:00 – Welcome back, episode two of the Roundup
00:55 – Topic one: Exponential View’s bubble gauges
05:01 – Is the bubble cycle actually vibes-driven?
07:40 – Real treasury yields as a hard-to-read signal
09:05 – Does the bubble question even matter long-term?
11:08 – Why “temporary correction” thinking is a trap
12:23 – Topic two: two new data engineering benchmarks
14:20 – Snowflake’s data-eng-bench, and what it tests
16:00 – Build, brownfield, and fix tasks, all dbt
17:09 – Why the harness matters as much as the model
19:48 – Opus 5, GPT 5.6 Sol, and where the scores land
21:02 – Hex’s benchmark on thorny analytical questions
22:00 – The overthinking curve: low, high, and max effort
25:06 – The meta takeaway: what do we build now?
27:19 – The fundamentals caveat
28:48 – Topic three: Stripe acquires OpenRouter for $7 billion
28:56 – What OpenRouter actually does across 500+ models
33:32 – Locked into one lab versus fully model-agnostic
35:38 – LightLLM, and whether workloads become portable
37:28 – Convergence versus real differences across labs
39:09 – Benchmarks as evolutionary pressure
40:55 – 50 trillion tokens a month, and what Stripe learns from it
41:21 – Topic four: Britton Stamper turns Gong calls into dbt models
43:16 – Defining context engineering precisely
45:12 – Why Gong calls were impractical to analyze before
46:59 – The naive approach, and why it burns your credit budget
47:43 – Britton’s approach: aggregate into incremental dbt models
49:59 – Structured and unstructured data communities converging
52:49 – The database eats everything
52:56 – The dbt Summit fireside chat
53:30 – Wrap-up and closing thoughts
Everything referenced in this episode
Topic one
Azeem Azhar and Nathan Warren, Exponential View: Is AI a bubble yet? Our five gauges say no
Topic two
Snowflake AI Research: Introducing data-eng-bench
data-eng-bench on GitHub
ADE-bench on GitHub (the dbt Labs / Benn Stancil benchmark referenced as prior work)
Izzy Miller, Hex: How we built a lab to evaluate data agents (Shorelane Commerce)
Izzy Miller on X: DataBench v1 results
Topic three
TechCrunch: Stripe will reportedly acquire AI gateway startup OpenRouter for $7B+
Topic four
Britton Stamper: From analytics engineer to context engineer; Model for the token, not the table
This newsletter is sponsored by dbt Labs. Discover why more than 80,000 data teams use dbt to accelerate their data development.