Cost per coding agent session: where the bill blows up

A coding agent session costs 155.6x more on one model than on another in the same duration band: $3.734 against $0.024 between 10 and 49 turns. On Opus 5.5, the long session costs 4.6x the short one. The bill is planned per session, not per million-token price.

The window closes on October 18, 2026, with 30 days of real sessions from eight models. What the table measures is the cost of a session that ends, and that is the number that lands on the following month's invoice.

Key findings

1. The median cost of a session of 10 to 49 turns varies 155.6x between the most expensive and the cheapest model in the set, from $3.734 to $0.024.
2. In the 2 to 9 turn band the relative spread is wider, 209.8x, because the short session on the cheapest model costs $0.005, half a cent.
3. On Opus 5.5 the 10 to 49 turn session costs 4.6x the 2 to 9 turn session and 10.2x the single-turn one; on Sonnet 5.5, 3.8x and 8.4x.
4. The first request of a session in an empty folder cached 17,047 tokens at $5 per million, $0.085, for a four-token response; reading the same block costs $0.20 per million, 25x less.
5. With 22 working days, 5 short sessions a day add up to $34 a month on Opus 5.5 and $17 on Sonnet 5.5; 10 long sessions a day add up to $306 and $131.
6. The agent's native CLI reported $0.16 to $0.31 for Haiku sessions that cost half a cent, between 32 and 62 times the real value, and overestimated Opus 5.5 sessions by around 50%.
7. The same monthly load from three work routines costs $1.79 on Haiku 5.5 and $172.62 on Fable 5.1, a 96.4x gap for the same service delivered.

Each line stands on its own, with the number, the duration band and the window that produced it. Anyone who cites one of them cites the whole statistic, not a slice of it.

How was the data collected?

Base: median cost per coding agent session published by an inference aggregator, in dollars, over a 30-day window ending October 18, 2026. Eight models, three duration bands, one median per band. This piece calculated the spreads, the multiples and the monthly envelopes; the per-session measurement is third-party.

Median is the value that cuts the sample in half: half the sessions cost less, half cost more. It is not the mean. The distinction matters in a distribution with a tail, because a session that reads an entire monorepo pulls the mean up and describes badly the session the team repeats every day.

The median answers what most sessions cost. The mean answers what the whole month cost.

The sample covers eight models across three bands: one request, 2 to 9 turns and 10 to 49 turns. The value is the total cost of the session, not the price of a turn and not the price of a million tokens. The aggregator publishes one central point per cell, which means this piece does not see the individual sessions, only the median of each model and duration combination.

What the piece calculated on its own: the spreads between models (155.6x and 209.8x), the multiples by duration in each model, the monthly envelopes at 22 working days and the task-layer table. Every calculation shows up in the section where the number is used, with the factors in view, so the reader can redo the multiplication and disagree with the rounding if they want to.

What cannot be concluded. Attribution between harness and model is another problem, already measured in Prompt cache and routing measured together: where agent cost actually takes shape. The cost of a session depends on the size of the repository and on how much of it the session reads, a variable the median does not control. A controlled bug-fix test ran on a small project, with a warm cache, and came in below the medians: it serves to compare configurations, not to budget. Measurement on the application side, rather than the session side, has its own treatment in How to measure the real cost of an AI application beyond price per token.

And the window is 30 days. Model price and cache policy move, so a multiple from October is not a promise for January.

What does a coding agent session cost by model and by duration?

A session of 10 to 49 turns costs between $0.024 and $3.734, median per model: 155.6x of spread. In the 2 to 9 turn band the range runs from $0.005 to $1.049, 209.8x. Eight models, three bands, the same 30-day window ending October 18, 2026.

Values in dollars, median per session:

The ladder has eight rungs and three columns, and the first thing that jumps out is the distance between the top and the bottom in the long band: $3.734 against $0.024. In absolute terms, the choice of layer is worth $3.710 per session, practically the entire price of the most expensive session. In relative terms, it is worth 155 times the cost of the cheapest one.

In the short band the relative spread is wider, 209.8x, because the denominator shrinks faster than the numerator. The 2 to 9 turn session on GPT-6 Luna costs half a cent, and any number divided by half a cent gets big. Relative spread and absolute distance point in different directions here, and both readings are correct: whoever sets policy looks at the relative one, whoever signs the invoice looks at the absolute one.

What this table does not do is explain the distance between the rows. Attributing the difference to the harness or to the model is another question, answered in the article cited in the methodology. The use here is different: the measured distance becomes a budgeting instrument, because the question it answers is what a session that ends costs.

A scope caveat, to avoid extrapolation. The numbers hold for the three measured bands. A 200-turn session is not in the table, and nothing here authorizes estimating it by linear interpolation.

Why does the first request cost more than the ones after it?

The first request writes the context block to cache and pays for the write: 17,047 tokens at $5 per million, $0.085, even when the response has four tokens. Every turn after that reads the same block at $0.20 per million, 25x cheaper. Session cost is a fixed floor plus a tail per turn.

The test that separates the two layers is simple and slightly humiliating: an Opus 5.5 session opened in an empty folder, with a trivial question. The response had four tokens. The session cached 17,047 tokens, billed at $5 per million on the write, and the bill closed at $0.085 before any useful work. Four response tokens, $0.085 of input.

The next turn does not pay that again. It reads the same block at $0.20 per million, and the marginal cost of a turn becomes the cheap reread of the block plus what that turn adds, not the block at write price. Reading the whole block costs $0.0034, one twenty-fifth of the write.

That is why the single-turn median is 0.136 and not 0.085. A real project does not open in an empty folder: it adds instructions, files read and tool output. The 0.085 figure is a cache floor, not a session budget.

Current practice treats session cost as price per token times volume, and that multiplication errs at both ends. It underestimates the short session, which pays a floor out of proportion to the work delivered, and overestimates the tail, which reads at read price. The session has two prices, and the first one is the expensive one.

What does a month of use add up to in each work routine?

With 22 working days, five short sessions a day add up to $34 a month on Opus 5.5 and $17 on Sonnet 5.5. Twenty short sessions add up to $134 and $68; ten long ones, $306 and $131. Between the two models, the routine weighs 9x and the model layer, 2.3x.

The one-line arithmetic, for checking: 5 sessions at $0.305 give $1.525 a day, times 22 working days, $33.55, rounded to 34. Twenty sessions at $0.305 give $6.10 a day and $134.20 a month. Ten long sessions at $1.390 give $13.90 a day and $305.80 a month, against $5.96 and $131.12 on Sonnet 5.5.

The number that changes behavior is the difference between the columns, not the total. In light use, switching Opus 5.5 for Sonnet 5.5 saves $17 a month, an amount that does not pay for the meeting needed to decide the switch. In heavy use of long sessions, the same switch saves $175, and there the decision pays for itself.

The 22 working days are an assumption of the envelope, not a measurement. Teams that work in shifts or cover weekends swap 22 for the real number of days, and the multiplication still holds. What does not get swapped is the duration band, because that is what defines which median enters the calculation.

The monthly envelope is also where cost per session meets cost per person. Ten long sessions a day describe someone on an investigation day; five short ones a day describe someone on maintenance. The distance between $34 and $306 does not come from the model. It comes from the routine.

Why does a long session blow the budget even with cheap tokens?

A long session blows the budget because each turn rereads a large context and writes what it adds; each new session pays the floor again. On Opus 5.5, the 10 to 49 turn band costs 4.6x the 2 to 9 band and 10.2x the single turn. The multiple does not disappear when the token gets cheaper.

The order flips when the axis is relative. GLM-5.3 expands 8.3x from the short band to the long one; Opus 5.5 expands 4.6x. The cheap layer has a proportionally steeper tail, and the reason is arithmetic: its floor is almost nothing, so the growth shows up whole in the multiple.

The floor is paid once per session, while the cached block stays valid; when it expires or changes, the write returns to write price. The tail is paid on every turn.

That dismantles a common policy, the one that treats the cheap model as a fixed-cost layer. $0.044 in a short GLM-5.3 session and $0.363 in a long one are the same model, and the 8.3x distance is the size of the error made by whoever budgeted on the wrong band.

The correct reading has two columns and neither one resolves alone. In absolute terms, the frontier layer costs more in any band, and that is where the spend cap needs attention. In relative terms, the cheap layer is the one that surprises most when the session stretches, and that is where task classification needs discipline.

In the long band, Opus 5.5 costs 2.3x Sonnet 5.5 and 26x Haiku 5.5. Whoever moves from Sonnet to Opus pays 2.3x; whoever moves from Haiku to Opus pays 26x. The difference between those two numbers is the difference between a layer policy and a shock.

How do you budget by task instead of by price per million tokens?

Budgeting by task means classifying the session by the turn band it uses, multiplying the median of that band by the number of sessions in the month and adding up the tasks that share the same key. Forty short sessions cost $12.20 on Opus 5.5 and $0.28 on Haiku 5.5. The envelope comes out of that sum.

The per-task arithmetic has three steps and none of them is the price of a million. First, classify the session by the turn band it usually uses. Second, multiply the median of that band by the number of sessions in the month. Third, add up the tasks that share the same key. The total on the last row is exactly that: 40 short sessions plus 24 investigation sessions plus 120 background sessions, each at its own median.

The distance between the first and the last column is 96.4x for the same workload: $1.79 on Haiku 5.5 against $172.62 on Fable 5.1. Neither end is absurd in the abstract. The question that decides is which task requires which layer, and the answer costs a fraction of what it costs to find that out on the invoice.

Route selection by quality and cost per task already has its own article, Multi-model orchestration in practice: 2 index points less for half the cost per task. Here the variable is another one: session duration and the fixed cost of opening. The two decisions add up without replacing each other.

And the envelope only holds if the meter sees the invoice. The agent's native CLI calculates cost from the model vendor's price table and errs when the model name is not recognized. In the measured set, it reported $0.16 to $0.31 for Haiku sessions that cost around half a cent, between 32 and 62 times the real value, and overestimated Opus 5.5 sessions by around 50%.

A cap calculated on a meter that errs by 50% is a cap with 50% of invisible slack.

The measurement that reconciles with the invoice comes from the gateway side, where the spend is formed.

What these numbers change in practice

Three decisions come straight out of the table: which model layer serves each type of session, which spend cap each key and each project gets, and when to open a new session instead of continuing the current one. All three are team policy, not vendor configuration.

Model policy by session type

Short routine goes to the cheap layer. The 2 to 9 turn median on Haiku 5.5 is $0.007, and no maintenance task justifies paying $0.305 for the same session on Opus 5.5, 43x more.

Long investigation goes to the frontier layer. The 10 to 49 turn band is where the work stops being mechanical, and moving from Sonnet 5.5 to Opus 5.5 costs 2.3x per session. That is the bill a long investigation has to justify, not the difference in price per token.

Background work goes to the minimum layer. Single-turn sessions cost $0.002 on Haiku 5.5 and $0.136 on Opus 5.5, and 120 of them a month add up to $0.24 against $16.32. Background work on the frontier layer is the most expensive way of not saving.

Spend cap by key and by project

The cap for a key is the sum of the envelopes of the tasks that key serves, and the cap for a project is the sum of the keys. That calculation replaces the estimate by order of magnitude, which is how most teams set limits today.

The article LLM cost accounting by team, user and model: what the spreadsheet does not show handled allocation by team and by user. The cap per key is the step before that allocation, because the key is the unit where spend is formed and the place where it can be stopped.

A new session when the task changes

The context block is paid once per session, while the cache stays valid. Continuing the session into a different task carries context the new task does not need, and each following turn pays to reread that borrowed block. The new session pays a floor and reads less; the continuation does not rewrite the block while it holds, and reads what it should not.

The rule of thumb fits in one sentence: if the next request does not need what the session has already read, open a new session. The cost of ignoring this shows up in the multiple: a session that should have closed in the short band and runs into the long one costs 4.6x on Opus 5.5, and not all of that multiple is new work.

The three decisions above only hold if there is somewhere to apply them. Nexforce Router exposes exactly the three things that policy needs: real-time consumption per session and per agent, spend caps per API key, per agent or per project, and route rules per key. None of the three changed the vendor's cache price, and none of them took part in the measurement. The measurement is third-party; the policy belongs to the team.

Frequently asked questions

Does the median per session serve to budget a large repository?

It serves as a starting point, not as an answer. Cost depends on how much of the repository the session reads, and the median aggregates projects of different sizes. The practice that works is measuring the first week of the real repository and comparing it with the median of the corresponding duration band.

Does the number include prompt cache cost?

It does. The value is the total cost of the session, and the empty-folder test isolates the cache share: 17,047 tokens written at $5 per million, $0.085, against $0.0034 to reread the same block. The difference between the two is what separates floor from tail.

Why does the analysis use the median and not the mean?

Because the cost distribution per session has a long tail: a session that sweeps an entire monorepo pulls the mean up and describes badly the typical session. The median answers the question the budget asks, which is what the session the team repeats costs.

Can the controlled bug-fix test become a budgeting base?

It cannot. It ran on a small project, with a warm cache, and came in below the medians in the table. It serves to compare configurations against each other, with the same repository and the same task, and not to size a team's spend across repositories of different sizes.

References and how to cite this analysis

To cite the set: NEXFORCE. Cost per coding agent session: where the bill blows up. Nexforce Blog, November 6, 2026. When citing an isolated number, cite the duration band with it, because the 1-turn median and the 10 to 49 turn median are not the same statistic, and swapping one for the other changes the argument of whoever cites it.

The table is collected again every quarter, with the same 30-day window and the same three bands. The next revision closes in January 2027, and the multiples will be recalculated on the new points, because model price and cache policy move faster than any budget spreadsheet.

The number changes every quarter. The question it answers, what a session that ends costs, does not change.

Next step: measure your own session

The next step is to measure the session your team repeats, with cost per session visible in Nexforce Router, and compare it against the matching duration band in this analysis.