On this page
where do coding agents spend their time
Where Coding Agents Spend Their Time: 228k Tool Calls From Claude Code and Codex Logs
I timed every tool call in my Claude Code and Codex session logs to find where provider work costs time: deploys, CI, env vars, migrations, RLS, webhooks and auth callbacks. It was 6.5% of Codex time and 12.6% of Claude Code time. The model thinking between commands took about 85% of the clock.
What was measured
All of it comes from one developer: me. These numbers describe my sessions and my machine. They are not a benchmark of the tools.
| Source | Range | Size |
|---|---|---|
| Claude Code session logs | 2026-07-07 to 2026-11-08 | 206 projects, about 228k tool calls, 912 hours of tool plus model time |
| Codex session logs | 2026-10-14 to 2026-11-08 | 312 sessions, 265.5 hours of wall clock |
| Controlled agent runs | October to November 2026 | 24 runs with build logs, plus one 6-run A/B |
Provider work is a small share
Provider work here means deploys, CI, env vars, migrations, RLS, webhooks, auth callbacks and local stacks. Deploys, env var edits and webhook setup each took under an hour in the Codex logs. In Claude Code the biggest provider buckets were local stacks (dev servers, Docker, ports) at 43 hours and browser verification at 21 hours.
| Agent | Provider time | Share of time | Share of new tokens |
|---|---|---|---|
| Codex | 17.2 h of 265.5 h | 6.5% | 6.4% |
| Claude Code | 114.6 h of 912 h | 12.6% | 8.5% |
The model is most of the clock
In the Codex logs, commands ran for 34.8 hours, explicit waits took 4.1 hours, and the gaps between a command's output and the next call took 226.6 hours. That gap is the model reading and deciding, about 85% of the measured time. Making every command 10x faster would save at most about 12% of the task.
The verify loop is the largest provider sink
About 45 of the 115 provider hours in Claude Code went to checking results: browser verification, deploy waits, CI waits, auth callbacks, migrations and webhooks. A browser verification episode averaged 6.7 iterations, the highest of any category: a screenshot or page read, a fix and a reload, again and again.
Repeated reads are rare
Exact repeated reads, the same file or the same output read twice, were 0.6% of 274M characters of tool output. Caching what the agent already read would save very little.
Half the builds failed, mostly on missing env vars
In 24 controlled runs, agents ran a build or typecheck 78 times. 39 failed, and 29 of those failures came from a missing env var such as NEXT_PUBLIC_SUPABASE_URL, in 16 of the 24 runs. 29 is a lower bound: 12 other failures were not inspected. A faster build would not have helped. Knowing which env vars the build needs before the first run would have.
A strong agent verified migrations on its own
I expected agents to skip migration checks, so I built an instant in-process Postgres check and ran an A/B on an app with three planted data traps: three runs with plain Codex and three with the tool. The task prompt did not ask for verification. The plain agent started its own Postgres in Docker, loaded the seed and 40k extra rows, and ran RLS tests and the production build anyway. The tool saved 8% of tokens and 30% of wall time; with nothing shipped broken in either arm, there was no headroom to win. Agents in web sandboxes without Docker were not tested.
| Arm | Shipped broken | Tokens | Wall time |
|---|---|---|---|
| Plain Codex | 0 of 3 | 193,953 | 1,429 s |
| With the in-process check | 0 of 3 | 177,743 | 1,005 s |
Why no outside tool makes a whole task 10x faster
If about 85% of a task is model time, a tool that only speeds up commands cannot make the task 10x faster: that needs at least 90% of the task removed. On these logs, removing all local stack time would make the whole corpus 1.05x faster.
The only 10x gap measured was resetting a Supabase test database between eval variants: 412 seconds with the Supabase CLI against 1.87 seconds with in-process Postgres (PGlite), 220x. No agent run waited on it; only the eval harness did.
Limits
These are the limits of this data.
- One developer's logs: about four months of Claude Code and about four weeks of Codex. Many Codex sessions were research and evals, not app shipping.
- Categories come from command and tool patterns, with spot checks. Recall is not measured.
- Think time is the gap between a command's output and the next call, capped at 10 minutes (Codex) or 15 minutes (Claude Code).
- The controlled runs are small: 24 runs with build logs and 6 in the A/B, with no variance estimates. No run used a real Supabase project, Vercel deploy or Stripe account.
Check your own logs
Claude Code stores sessions in ~/.claude/projects and Codex stores them in ~/.codex/sessions. Before choosing a tool that promises a faster agent, measure the share of think time against command time in your own sessions.
For the env var failures above, npx -y viberaven check reads a Vercel + Supabase repo and lists env vars the code uses that are missing from the env template. It is a repository check, not a live database test, and advice, not a gate.
FAQ
How much of a coding agent's time goes to provider work?
In one developer's logs, 12.6% of Claude Code time (114.6 of 912 hours) and 6.5% of Codex time (17.2 of 265.5 hours) went to deploys, CI, env vars, migrations, RLS, webhooks, auth callbacks and local stacks.
Why can't a faster tool make an agent 10x faster?
In the Codex logs the model's time between commands was about 85% of the clock. A tool that speeds up only the commands can save at most the remaining share, so the whole task cannot get 10x faster.