Ask an AI builder to wire up a working login flow — form, validation, a route, a database check — and you'll typically wait somewhere between 35 and 90 seconds before a diff appears. Profile that request end to end and the model itself, the part actually generating tokens, accounts for about 3 to 4 seconds of it. Network round trips add another 1 to 2. The remaining 30-plus seconds, the part you experience as "the AI thinking," is almost entirely something else: your agent team reading files, running a build, and checking its own work before it shows you anything.
That ratio surprises almost everyone the first time they see it measured, including engineers who build this stuff for a living. The intuition is that a bigger, slower model must be the bottleneck, so the fix for a sluggish build must be a faster model. Sometimes that's true. Most of the time it isn't, and understanding why changes how you should think about prompt size, project size, and what to expect when a build feels like it's "hanging."
What's actually filling the clock
Break a single "add a feature" request into phases and a pattern shows up immediately: the model spends its time in short, cheap bursts — deciding what to do next, writing a tool call, reading a result — while the expensive, slow parts happen between those bursts, on disk and in a shell.
| Phase | Typical share of total time | What's happening |
|---|---|---|
| Model inference (generation) | 5–10% | Tokens being produced — the plan, the code, the tool-call arguments |
| File reads / context assembly | 10–15% | Pulling in existing files, prior run history, the project's conventions |
| Tool execution (writes, shell, package installs) | 35–45% | Actually changing files, running a linter, installing a dependency |
| Build / compile step | 15–25% | Framework builds, type checks, bundling — this scales with project size, not prompt size |
| Verification agents | 15–20% | A second pass checking the diff actually does what was asked before it's shown to you |
| Network / streaming overhead | 2–5% | Round trips between the model, the sandbox, and your browser |
Two things fall out of that table that aren't obvious until you see them side by side. First, the build step scales with the size of the whole project, not with the size of your prompt — a one-line CSS tweak on a 400-file app can take longer to verify than a five-file feature added to a fresh project, because the compiler has more to check either way. Second, the single biggest lever isn't the model at all. It's how much gets touched.
Why the illusion holds up
Streaming interfaces are partly to blame, in a good way. The first token usually appears within a second, so the UI feels responsive immediately — you see a plan forming, a sentence typing out, tool calls scrolling by. That first-token latency is what people mentally register as "the AI's speed." What they don't see clearly is that once the model finishes deciding what to do, it hands off to a build pipeline that has nothing to do with language modeling anymore. A `docker build`, an `npm install`, a type-checker walking an import graph — none of that gets faster because GPT-5 replaced GPT-4, or because Sonnet replaced an older Sonnet. It gets faster because someone cached a dependency layer or skipped a redundant check.
I've watched builders swap models mid-project hoping to fix a "slow" build, twice in the same week, before realizing the actual bottleneck was a verification pass re-running a full type check on every save instead of an incremental one. The model swap changed nothing, because the model was never the slow part.
Where this actually bites you
The practical consequence shows up in a few predictable places:
- Large, sprawling prompts feel disproportionately slow — not because the model struggles to parse them, but because a request that touches twelve files triggers twelve file reads, twelve writes, and a build that now has to reconcile all of them.
- Projects get slower to iterate on as they grow, even when each individual prompt stays simple, because the build and verification phases scale with total project size.
- "It's stuck" is rarely the model hanging. It's almost always a build step waiting on a package registry, or a verification agent re-running a check that didn't need to re-run.
- Splitting one big ask into several small ones often finishes faster in total, because each smaller request triggers a narrower build and a lighter verification pass, even though you're now waiting through more individual steps.
A maker on our Discord put it well: "I kept asking for a faster brain when what I needed was a smaller diff."
What actually shortens the wait
None of the real fixes involve a bigger model. Incremental builds that only recompile what changed instead of the whole project cut the build-phase share dramatically — this is the single largest lever available, often worth more than every other optimization combined. Caching dependency installs between runs removes a chunk of the tool-execution phase that has nothing to do with your specific prompt. Scoping verification to the actual diff, rather than re-checking the whole codebase every time, keeps that phase proportional to what changed instead of to what exists. And running independent tool calls in parallel — reading three unrelated files at once instead of in sequence — shaves real seconds off the file-I/O phase without touching the model at all.
None of that is glamorous. It's also the reason two builders can type nearly identical prompts into the same platform on the same day and have wildly different experiences of how "smart" or "fast" it feels, when the actual difference is project shape, not model quality. The model was never really the clock you were watching. It just looked like it.
