What a week of agentic coding actually costs. Claude Code API vs Pro

Claude Code API and Pro are easy to compare by price, but the calculation changes once the tool becomes part of regular development work. API costs grow with usage, while a subscription stays fixed until its limits start affecting the workflow. We tested both access models on the same real project to see how that trade-off looks in practice.

Teams adopting AI coding tools eventually face a practical question: do we buy seats, or do we use API access?

It is easy to reduce that decision to a simple price comparison: a fixed monthly fee on one side and usage-based API costs on the other. In practice, the two access models behave differently as usage grows. A team can pay for more subscription capacity than it actually uses, but it can also underestimate its needs and start running into plan limits during regular development work.

With API access, the bill grows with every task and stops when usage stops. A subscription works differently: the cost stays fixed while usage remains within the available allowance. Once that allowance starts affecting the workflow, however, waiting time becomes part of the decision as well.

That is what we wanted to measure. We ran the same real development project through Claude Code in two setups: one authenticated through the Claude API and the other through a Claude Pro subscription. Both used the same nominal model, the same tool and the same prompts in isolated environments. The aim was to see how the economics of both access models look in actual development work, rather than compare them only on a pricing page.

The subscription fee sets a spending break-even point. Usage limits determine how much work the plan can support beyond it. There are three regions to consider.

Daily spend is a useful starting point because you can check it against your own records. Using the monthly fees in our comparison:

If your metered spend runs below $0.67 a day, no subscription tier pays for itself. Above it, the decision stops being arithmetic and becomes preference: whether session limits would interrupt your flow, whether you would rather have a predictable invoice than a variable one, and whether you are willing to monitor usage to avoid a surprise bill.

The arithmetic uses the fees shown here. Check current plan prices and allowances before making a purchasing decision.

The experiment covered five workdays in July 2026. The project was a real full-stack Next.js and Prisma application, architected through Domain-Driven Design from event-storming artifacts. Pro refined implementation plans covered bounded contexts, API design, the data model, UI specification and product requirements document. There were 15 vertical slices, each with its own acceptance criteria and definition of done.

Both setups started from the same commit: a bare scaffold with dependencies, infrastructure and the full slice specification in place. Each ran in its own virtual machine against its own clone, with no shared state. Claude Code CLI executed identical prompts under each setup’s credentials, using --dangerously-skip-permissions to run autonomously in those isolated environments. Both used Sonnet 4.6, with LiteLLM as the gateway and Langfuse for observability.

A session is one prompt-plan run to completion: a prompt naming one or more slices, run start to finish without steering. Everything below uses that unit.

Each prompt had two parts. First, implement the named slices against their plans. Second, run typecheck, lint and the test suite, and fix what comes back. Implementation and this self-check are inside the session and inside the cost figures. An external model then audited each slice against its specification and definition of done. That audit ran separately, and its cost is not included here.

Early slices ran one per session. Once it was clear how much context a slice consumed, they were batched: three, then five per session. There were 19 sessions in total on the API setup, four of which were also run on Pro.

Those first five slices calibrated how much work fitted into a session and helped us check the measurement pipeline. The cost figures cover all 19 API sessions. The detailed implementation comparison later in this article covers a batch for which we verified an identical starting repository.

One boundary worth stating now: Sonnet 4.6 is now a legacy model, superseded by Sonnet 5 at $2/$10 per million tokens against 4.6's $3/$15. Every dollar figure below would be roughly a third lower on current models. The structure holds; the absolute numbers are a July 2026 snapshot.

Three systems reported session costs, and they disagreed. The Claude platform console (platform.claude.com) and Langfuse agreed to within 2%. Claude Code's own /cost readout did not agree with either on the API setup.

The gap was consistent across sessions:

Across those sessions, the CLI overstated API spend by roughly 65%. A team scale projection based on those readouts would therefore have overstated the measured costs substantially. On the subscription setup, CLI figures came in at 1.04 to 1.09 times the Langfuse value calculated at API rates. That is about a 7% difference. This reference value represents what the recorded usage would cost at API rates; it is not a charge on top of the subscription.

We have no explanation for the discrepancy. In this experiment, it appeared on the API setup and was much smaller on Pro. That observation does not establish that credentials caused it or that other versions of the tool will behave the same way.

Six sessions have platform or Langfuse figures. The other thirteen have CLI figures divided by 1.65. The ratio is stable enough across session sizes that we are comfortable with it, but two thirds of the total below is a derived number and should be read with a wider error bar than a measured one.

Nineteen API-arm sessions across five workdays came to $60.96. That is $12.20 per developer per workday. Extrapolated to four working weeks, that comes to 76 sessions and $243.84 a month.

That total is a first-pass cost. It does not include the work needed to fix what those sessions left behind. Every slice was audited against its specification afterwards, and the corrections ran as their own sessions. Section 8 prices them. Against that, every subscription tier is cheaper:

All three sit below the observed workload, which puts this developer firmly in region 2 for every tier on offer.

Every tier is cheaper than metering at this intensity, but the mean hides how much individual sessions vary:

The spread is 56×, with the mean 63% above the median. A handful of large batch sessions pull the average up while most sessions cost about two dollars. If you are budgeting from a mean, you will systematically overestimate a light week and underestimate a heavy one. Anyone repeating this exercise should capture the spread of per-session costs alongside their average. The distribution shows how much those costs vary over a real month.

The invoice gives you a total. To understand what you paid for in agentic coding, you need the token breakdown, and the answer is not what most people assume.

The figures below cover the nineteen API-arm sessions. We took the token counts our observability logged for each bucket, applied Anthropic's published Sonnet 4.6 rates, and checked the result against the billed total: the reconstruction lands within 1.2% of the invoice, so the split is sound.

The breakdown shows where that money went. Cache reads are 95% of the tokens and half the money. Agentic coding is a loop that re-sends the accumulated conversation on every turn. You are paying, mostly, to re-read your own context. Hit rates ran 94–99% across every session on both arms, with no tuning.

Cache writes cost more than output. In our workload they were 4% of the tokens and 27% of the bill, because writing is the expensive operation: $3.75 per million to write a token into the cache against $0.30 to read it back, a factor of twelve. Every piece of new material entering the context gets written once at the high rate, then re-read cheaply for the rest of the session. Your bill therefore tracks how much new content each turn introduces, not how much context you are carrying. That 27% is specific to this workload and will shift with the shape of yours, but it appears on no dashboard, so most teams have never seen their own figure.

Output is 23% of the bill, making the bucket everyone tries to optimize the third-largest line.

A cache read costs 90% less than fresh input, but that does not mean caching cuts your bill by 90%. Caching only touches the input side; output and the write premium are unaffected, and they are half your bill.

Here is the whole counterfactual. Turn caching off and those 99.9M cached tokens bill at the full $3.00 rate instead of $0.30. The 4.4M cache-write tokens become ordinary input at $3.00. Output and fresh input do not move.

One line in that table moves the wrong way, and it is worth understanding why. Cache-write tokens are the first send of new material; cache-read tokens are every re-send of it. Remove caching and that first send gets cheaper, from $3.75 to $3.00, but every re-send jumps from $0.30 to $3.00. The write line falls by $3, and the read line rises by $270.

That is about 5.4×, or roughly $1,320 a month instead of $244.

The 5.4× multiple still clears every subscription tier by a wide margin. Applying the per-token discount to the whole bill would give 10× and overstate the saving.

The cost lever here is how much context each turn carries and how often you force the cache to rebuild. In practice:

These changes do not require choosing a cheaper model.

Splitting the nineteen API-arm sessions by the kind of work they did shows how development and stabilisation contribute to the total.

The total spend was nearly identical, although the session profiles differed considerably.

Feature development ran as a few large batch sessions, each producing thousands of lines. Stabilisation, which involved aligning the implementation against UI mockups, chasing bugs, fixing what UAT surfaced, ran as many small sessions that read a lot, changed a little, and cost twice as much per line.

That reflects the work involved. Stabilisation is analysis-heavy: load context, locate the problem, make a small targeted edit. The ratio of reading to writing is inverted, and the bill follows.

If you estimate a project by pricing feature slices, the work that has a plan, an estimate and a ticket, you will capture roughly half the real spend. The other half arrives during the phase nobody puts on the roadmap.

One session ran on both arms with the same prompt, the same specifications, and a starting repository we verified was identical down to the filenames of all thirteen existing test files. A note on what can be compared here. The API arm has a real dollar figure: $7.97, metered and invoiced. The subscription arm does not. Its marginal cost was zero, because the fee was already paid. What we can compare is token consumption, and to make that legible we priced the subscription arm's tokens at API list rates. That gives $10.15. Nobody paid $10.15. It means the subscription run consumed 27% more billable-equivalent work than the API run, and it is the only honest cross-arm comparison available, because dollars-per-task simply does not exist on a flat fee.

With the same inputs, one arm did 27% more.

Then we audited both outputs against the same specification with the same external model. The API run shipped 3,114 lines and five test files. The subscription run shipped 6,027 lines and seventeen. The five were a strict subset of the seventeen: where they overlapped they wrote the same files, and the API arm simply stopped earlier. It wrote domain aggregate tests and repository seam tests, and zero application-layer use-case tests.

Two commits later, an external audit found real defects in the API implementation. Its own gates had passed cleanly: typecheck green, 186 of 186 tests passing. Every one of those tests ran against a mocked Prisma client, so nothing exercised real SQL, transactions, or the over-allocation logic end to end. Green tests against mocks are not a completion signal.

Bringing the API implementation to a state that passed audit took five further sessions the following morning. We went back and priced them:

Those correction sessions have exactly the stabilisation profile from section 7: small and cheap, averaging $1.27, 13M input tokens against 91k of output. Almost all of that work was reading, with very little writing.

We could not capture the same figure for the subscription arm. Its transcripts did not survive and its observability records for that window are gone. It made four correction commits against the API arm's five and needed none at all for S09, so its remediation was plausibly smaller, but we are not going to estimate a number we did not measure, and we make no claim about which arm cost more to reach.

We are also not claiming the credential path caused the divergence. We do not know what did, and one paired session cannot tell us. What the measurement does establish is that cost per session and cost per completed feature can rank the same two options in opposite directions.

Three practical ways to measure cost beyond the initial session:

That independent verification is the cheapest governance you can add, and it made this comparison possible.

Everything above came from one developer, one project and one week, which limits what can be claimed. The numbers are point estimates. Nineteen sessions will not carry a confidence interval, and four paired sessions are too few to test token parity between arms rigorously.

These figures represent an expert floor rather than an average: a single experienced operator working from pre-refined specifications. A loosely-steering developer can burn several times the tokens on the same task, so real per-developer cost will spread upward.

The experiment covered a substantial full-stack, DDD-architected workload driven by audited implementation plans. Data engineering, mobile and ops work will not automatically fit the same envelope.

Two thirds of the total is derived. Six sessions carry measured figures; thirteen are CLI values divided by 1.65.

The rate-limit ceiling was estimated, not found. We projected roughly 120 sessions a month on Pro from observed consumption and never came close to it. Locating the real wall needs an experiment designed to hit it.

July 2026 prices, on a model now marked legacy. Sonnet 4.6 has been superseded by Sonnet 5 at $2/$10 against 4.6's $3/$15. Re-run the arithmetic before quoting any figure here as current.

The dollar amounts will age, but four aspects of the comparison remain useful for your own decision. Below break-even, metering wins outright. Above it, the subscription wins until you meet the rate limit and have to wait. Those three regions matter: a single break-even number leaves the effect of rate limits out of a two-dimensional decision.

Sixty-seven cents a day covers an entry subscription. Most teams debating this are far above that line and do not know it, because they have never looked at a daily figure. You can check yours this afternoon.

Half the spend was re-reading accumulated conversation and another quarter was the premium for caching it. Output, the thing everyone tries to trim, was under a quarter. That puts session hygiene and plan quality ahead of model choice or terse prompts on the optimisation list.

Building a feature and stabilising it cost near-identical amounts, with stabilisation costing twice as much per line. Only feature development appears on a roadmap. Estimate from feature slices alone and you will budget for about half of what you spend.

We checked the tool's own cost readout against another source, which is what makes these figures usable. It turned out to be wrong by 65% on one arm and right on the other. Whatever you measure, reconcile it against a second source before you build a decision on it.

This experiment showed how much follow-up work can sit behind a seemingly inexpensive coding session. If you’re considering AI-assisted development for your product, talk to Kellton Europe. We can help you work out where to start and how to assess the costs alongside the quality of the software delivered.