Sixty-Four Calls and Seventeen Cents

On 16 August 2026 we measured a complete generation run of Quillsmith, our long-form writing system, end to end. A premise goes in; a world, a structure and ten chapters come out. The run dispatched 40 directives, made 64 model calls, and cost seventeen cents.

Four days later a different investigation put a number next to that one. Sending a typical 240,000-token manuscript into a single call, at the same rates, costs about eighteen cents. One call with the whole book in it costs more than the entire run that produced the book.

Most of what follows is about why that is true, and about the other things you only learn by paying the bills instead of reading the pricing page. One phase accounts for roughly 45% of every run’s cost no matter how the run is configured, so the obvious knobs cannot reach most of the spend. Failed attempts bill the same as successful ones, and we have the incidents to prove it. The prompt envelope is deliberately a small fixed fraction of the model’s window, because the failure mode inverts as the window grows, from truncation, which is loud, to dilution, which is silent. And there is a mistake in here worth more than the rest: the per-token rates tripled under us and every estimate we had written into prose was wrong, while not one ledger row ever was.

The run, and the call that costs more than the run

The measured figure comes from a gate run recorded on 2026-08-16: a QuickStart, the flow that takes a premise to an established world and a set of chapters, configured with the cheapest world tier and a ten-paragraph chapter cap. Forty directives, 64 model calls, $0.17, against openai/gpt-5.4-mini at 0.75 / 4.50 / 0.075 USD per million tokens for fresh input, output and cached input.

The interesting part of that measurement is not the total. It is that the total barely moved when the plan shape changed underneath it. The same flow had previously been 12 steps and 11 calls. It became 40 directives and around 60 calls, and the cost held roughly flat, because the calls got smaller as they got more numerous. Anything that budgets by cost survived the change. Anything that asserted a call count broke.

Now the comparison. A default chapter of 40 paragraphs is about 8,000 tokens at four characters per token. A 30-chapter novel of roughly 180,000 words is about 240,000 tokens, which fits inside the pinned model’s 400,000-token window with 40% headroom to spare. Sending that manuscript fresh, once, costs $0.18. Sending it on each of the roughly eleven calls that a single chapter’s extraction makes, without caching, costs about $2. Blanket whole-manuscript context therefore costs about twelve times the whole run for every chapter it touches, which is the kind of number that settles an architecture argument without a meeting.

Where the calls actually go

A cost model that stops at a total is not a model. The useful question is which phase you would have to change to move the number. Our answer was unwelcome.

Extraction is the call floor. Two confirmation runs on 2026-08-08, at the rates then in force, measured a Preview run at $0.140 of which extraction was $0.064, and a Rich run at $0.308 of which extraction was $0.139. Forty-six per cent and forty-five per cent. The call count for that phase, around 23 to 24, barely moves between world tiers at all. World scope and chapter caps are real levers, well-measured ones, and they act on the other half.

This is what makes agentic cost modelling different. The knobs a product exposes, and the knobs an engineer reaches for first, govern the variable part. The fixed part is the pipeline’s own structure: how many distinct questions it asks the model in order to do one unit of work. You cannot configure that down. You have to redesign it, and that is where the one-concern-per-call discipline starts fighting the budget.

A census of one complete run’s audit trail, sampled 21–22 August, put numbers on the inside of that floor. The extraction complex came to roughly 109,000 input tokens and 20,000 output tokens, about $0.155. Three findings from it have outlived the sample.

The first is about output. Input was 5.5× output by volume, and output was 6× the price per token, so the single largest cost line in the whole complex was the output of one step. Reference extraction made nine calls, 26,400 input and 9,300 output tokens, for $0.060, 39% of the complex. Decompressing a response showed why: every emitted reference carried a full-sentence source quote copied verbatim out of the entity content it came from, plus long repeated JSON keys. Roughly two thirds of that output was the pipeline paying premium rates to echo its own input back at itself. The attribution code that consumes those quotes does a substring match, so a quote prefix attributes just as well as a whole sentence; an 80-character bound roughly halves the line.

The second finding is the one that has changed how we measure everything since. The fixed floor has two different token terms, and they dominate at different scales. On our development fixture, with ten-paragraph chapters of about a thousand tokens, most of each call’s input is the assembled instruction stack, five to nine thousand characters of sections. At production chapter sizes the chapter-repetition term takes over instead, because five separate calls each embed the full chapter text, so a 5,000-token chapter is re-sent five times before the entity funnel even starts. A fix tuned on the small fixture optimises the wrong term. We now refuse to license a token optimisation on fixture-scale evidence, and say so in the plan that proposes it.

The third is large in count and small in money. About forty calls per run are verdict micro-calls, name-resolution confirmations and duplicate checks and adjudications, each paying a full prompt to emit a yes or a no. Thirty of them cost a tenth of a cent between them. Batching those is not a cost lever at all. It is a latency, retry-surface and audit-noise lever that looks like a cost lever, and calling it what it is stopped us from scheduling it as one.

One genuine defect surfaced in the same census, and it is the sort you only find by counting. A post-write drain looped over definitions calling a single-entity reference extraction, one model call per entity, while the batch method sat on the same service with a batch size of fifteen and was already used by another caller. Twenty definitions meant twenty prompt overheads where two would do. It was fixed on 2026-09-12, and the test that guards it counts calls rather than results.

Failure bills

A model call that fails still bills. A plan that dies on its fourth step has paid for three. A run killed by a defect in the code under test has paid for everything it did before the defect. Our own records, kept because we were paying for them out of a metered account:

Two failed planning cycles burned 55 model calls before anything succeeded. A gauntlet run against a fail-fast setting took six QuickStart attempts to go green. Four consecutive battery runs died on a single defect before it was characterised well enough to fix. A provider content filter ate three runs outright, which taught us not to seed fixtures with famous verbatim passages. On a different occasion, a chapter that had been hand-edited into a Draft state was already full, so the write path skipped it and the run spent its planning passes to produce no prose at all, for ten cents.

The most instructive one is not a failure but a misprediction. A rename of a chapter, asked for conversationally on an established project, was budgeted at about two tenths of a cent on the assumption it would decompose into a single update step. It decomposed into an entity-cascade plan of thirteen members, twelve of them model-calling updates on definitions, arcs and timeline items that merely mentioned the renamed chapter, and it measured $0.1257. Sixty times the estimate. The same edit through the REST field endpoint costs nothing, because it is deterministic.

In an agentic system the price of an operation is not a property of the operation. It is a property of the plan the planner happens to produce for it. A small semantic difference in how a request arrives can change that plan’s shape completely, and the bill with it.

Two failure modes are not about model calls at all and cost more time than money. An out-of-credit response from the provider ended two of three sessions in one batch, so we check the balance before starting anything long. And a per-user daily token limit presents as a hang rather than as an error: a chat that appeared to go idle turned out to have spent 543,000 tokens against a 250,000-token daily cap. Neither of those is visible in a cost model that only counts tokens.

The control we eventually built for this is a per-plan spending ceiling, enforced at the runner. Pin it and a plan walk pauses when it reaches the ceiling, marking the remaining steps as skipped for budget, with the plan still retryable afterwards. It went in with a write-through cache so it takes effect on the next model call rather than on the next restart. It was proven live on 2026-08-16, and on that same day the run overran anyway, because the knob was set for one leg and handed back before a retry that then ran unbounded. A budget brake works only while it is applied.

The estimates went stale; the ledger did not

On 2026-08-16 the per-token rates for our pinned model tripled. Input went to 0.75, output to 4.50, cached input to 0.075 USD per million tokens.

Everything we had ever computed at runtime was still correct. Cost booking reads live rates at call time by design, so no ledger row was ever wrong, not one, going back through every run we had ever made. What was wrong was every number that had been written down in prose. A living guidelines document carried a table of what things cost; an offline configuration file carried a mirror of the rates so that development runs could be costed without a network call. Both were stale the moment the provider changed its price list. Neither had any way to notice.

We rebased the document by multiplying the historical measurements by three and labelling them as planning estimates rather than receipts, then re-measured the important ones. The rebase is the honest part. Multiplying a measurement by three does not produce a measurement, and saying so in the table is the difference between a document you can plan against and one you will quietly stop trusting.

None of this is specific to model pricing. A number you compute from a live source and a number you cached in prose look identical on the page and have completely different half-lives. Any figure that appears in documentation should carry the date it was measured and what was measured, and any figure that appears in configuration should be understood as a copy with an owner, not as a source of truth. We now write both into the table.

A smaller version of the same lesson pointed the other way. We estimated that capturing a reusable project fixture would cost about $0.17; it cost $0.1330 across 54 model calls, and every gate that imports the fixture afterwards costs nothing. High rather than low, which is the pleasant failure. It was still a guess dressed as a figure until somebody ran it.

A window is headroom, not a target

The budget machinery we inherited from our own earlier work was sized against a model generation that no longer existed. The total prompt envelope was 2,500 tokens. Against the pinned model’s 400,000-token window that is 0.63%. The timeline group inside it got 700 tokens, 0.18%, and a feature team had treated that 700 as a physical constraint to design around.

It was worse than merely small. The constant was a silent code default bound to a configuration section that existed in no settings file anywhere, duplicated in a second subsystem in different units as a 10,000-character limit carrying the comment “~2500 tokens”. Fixing one left the other stale.

The fix was not to raise the numbers. It was to make the envelope derived rather than constant:

envelope        = clamp(model.contextWindow × ContextUtilisation, 2_000, 100_000)
sectionBudget_i = envelope × share_i

with the model’s real window fetched from the provider catalogue and stamped onto every model resolution, so the code assembling a prompt knows what it is assembling for. Utilisation starts at 0.05. On the pinned 400,000-token model that is a 20,000-token envelope: eight times the constant it replaced, and still a twentieth of what is available. A hard ceiling of 100,000 tokens sits above the formula so that a million-token model does not produce a million-token prompt budget.

The reasoning is written into the options class itself, next to the default, because this is the decision most likely to be quietly undone by a well-meaning change:

A large window is headroom, not a target: attention degrades over long spans of marginally relevant material and input cost scales linearly, so the envelope is deliberate policy well below the ceiling. Starting conservative at 0.05. Raise on measurement, not on optimism.

The cost argument for keeping it there is the easy half. Input cost scales linearly with every token sent, so a four times larger envelope on a pipeline that then made thirty-plus calls per chapter multiplied waste thirty times over. That is an argument for sequencing an envelope raise after a call-count reduction, and we sequenced it that way.

The half that transfers is about what breaks. Under a small envelope the failure mode is truncation. Truncation is loud. A prompt gets cut, the model answers a question it could not see all of, a response comes back malformed or missing its tail, and somebody opens a bug. We have had those bugs; one of them was an output cap of 4,000 tokens against a completion limit of 128,000, and it cost a debugging cycle before anyone thought to check the cap.

Raise the ceiling and that failure mode is replaced by dilution: a large prompt of weakly relevant material producing worse output than a small sharp one. Nothing fails. No exception is thrown, no field is missing, nothing is malformed. The chapter is simply a bit flatter, the entity a bit more generic, the plan a bit less specific — and there is no signal anywhere in the system that this has happened. You can run a diluted pipeline for months and see only that quality is not what you hoped.

That asymmetry is why the envelope is policy rather than a ceiling, and why we pair every proposed raise with a gate that can detect the silent failure. The dilution gate for the chapter writer, as designed, runs a fixed fixture twice, once with today’s context and once with the full manuscript, and asserts that the focused outputs do not degrade while the continuity references improve. Dilution is silent, so the assertions have to be targeted. Reading two outputs and forming an impression is not a gate.

We owe the argument one nuance, because it cuts against the doctrine’s broadest reading. Relevance is not uniform across context types. A roster of forty marginally related entities is dilution risk. The manuscript itself, on a call about that manuscript, is ground truth that the call is currently forced to approximate through rosters and 200-token summaries. The chapter writer today sees roughly 0.5% of a thirty-chapter book, three summaries and a handful of paragraphs, and voice drift and forgotten minor characters are the direct signature of that window rather than a prompting problem. Dilution is a strong objection to entity soup and a much weaker one to source text. It is also a claim we hold as testable rather than settled, which is the only honest status for it.

What a bigger window does not change

Two facts bound every idea that starts with “the model can see the whole book now”, and both are easy to miss because they are not window facts.

Output caps did not move. Completion is still capped at 128,000 tokens whatever the window is, so every flow that exists because of output size is untouched — the chapter continuation ladder, batch generation sizing, the 16,000-token cap on entity batches that exists because a truncated batch loses all of it. None of those get simpler on a million-token model. A larger window tempts larger outputs, and the truncation class on the output side is unchanged.

Input cost is linear and there is no volume discount to hide behind. The only genuine discount is on cached input, at a tenth of the fresh rate, and that discount is what decides whether manuscript-scale context is affordable at all. With it, a chapter’s eleven extraction calls carrying a shared 240,000-token manuscript prefix cost $0.18 for the first and about $0.018 for each of the rest. Without it they cost $0.18 each.

The discount we were already getting, and the one we were not

This is where the opening comparison comes back. A whole book in one call is expensive once; the same book in every call is expensive eleven times, unless the cache carries it. So we went looking for whether caching was already happening on our stack, and the audit trail answered before any experiment did. It was happening, incidentally, and the ledger was already discounting it: one coherence-scan turn showed 8,704 of 9,636 input tokens cached, several decompose turns showed two to four thousand, one beat-sheet call showed 2,816 of 6,818. Those are all hits within a single multi-turn runner, where the same system prompt recurs across turns. The cost column already reflected the tenth-rate discount because the pricing service applies the cached rate when the audit artifact carries cached tokens.

And across the single-shot calls, the ones that matter, there was no prefix sharing whatsoever. Every chapter-reading handler assembles a per-purpose instruction stack as the system message and puts the chapter text last, in the user message. Prefix caching matches from byte zero. Five calls that all carry the same chapter share nothing, because the one thing they have in common sits at the end.

That is a layout bug wearing the costume of an architecture problem. The fix is to invert it: assemble one byte-stable head, the chapter text and eventually the entity roster, owned by one component, followed by a per-call tail carrying the instructions. Every call still asks exactly one question. It just stops re-buying the evidence. At production scale, five chapter-carrying calls on a 5,000-token chapter drop from about 25,000 fresh input tokens to about 5,000 fresh and 20,000 cached, roughly 72% off that term.

Three constraints come attached. The head must not interpolate anything per-step, so no step name, no timestamp, no per-handler framing above the text block; today each handler writes its own heading above the chapter, and they differ from byte zero even where the chapter is identical. Moving instructions to the tail also changes every extraction prompt’s head/tail weighting at once, which is a global prompt-behaviour change riding a cost optimisation. That is a dangerous combination and we recorded it as one. If the precision gate degrades, the layout inversion is the first suspect, and the change does not land without a before-and-after fixture run.

The third is the one we would have missed. A cold shared prefix fanned out to N concurrent calls misses N times, because the cache entry only serves calls that begin after the writing call has finished. Caching wants a primer: run the first head-carrying call alone, then fan out. Our pipeline is strictly sequential today, so it gets this for free. That is what makes the constraint dangerous. It stays invisible until somebody adds parallelism and quietly loses the discount they were parallelising to afford.

Where this stops applying

The model above is a model of one shape of system, and the shape matters more than any of the numbers.

Our unit of work is large, infrequent, and user-initiated. A run takes minutes and makes dozens of calls. That is what makes per-run accounting the right granularity, what makes a per-plan spending ceiling a coherent control, and what makes a fixed call floor the dominant term. Invert any of those and the advice changes.

If the unit of work is small and frequent, the fixed per-call overhead stops being a floor worth attacking and starts being the whole bill. The instruction stack that is noise at manuscript scale is the entire input at message scale, and our own measurements show both regimes inside one product: the same pipeline is instruction-stack-dominated on a thousand-token fixture and chapter-repetition-dominated on a five-thousand-token chapter. Measure at the scale you actually run at. A number measured on a small fixture will send you off to optimise a term that dominates nothing in production.

If the work is continuous rather than plan-shaped, a per-plan ceiling has nothing to attach to, and the control has to move to a rate or a reservation instead.

If a single call already dominates the run, none of the floor arithmetic matters. The multi-call structure is what makes the accounting necessary as well as interesting.

And if you are not paying per token, none of this is a cost model at all; it is a latency model wearing a cost model’s clothes. Several of the levers described here, batching the verdict micro-calls in particular, are worth almost nothing in money and quite a lot in wall-clock and retry surface. Knowing which of the two you are buying is the difference between scheduling the work and deferring it.

What we do with this

Three habits carry over to anything we build or review on the same shape.

Book from live rates, and treat every figure in a document as a dated measurement of a specific thing. A cost table without dates will be wrong without telling anyone.

Instrument every run as though it were the measurement run. The per-step cost walk, the call census, the input-versus-output split and the cached-token column all come off an audit trail that exists anyway. Several of the findings above came from a single sampled run nobody had planned to analyse.

Size budgets against the model in use rather than against a constant, and write the reasoning next to the default. Our envelope is a fraction of a real window with a hard ceiling above it and a paragraph explaining why it is not larger. That paragraph is the artefact. The number is easy to change; knowing whether you should is the part that took the measurements.

We build and maintain software systems, and develop the Quillsmith applications. The figures in this paper are measurements from the shipping system, taken between 8 and 22 August 2026 and dated individually where the date changes what they mean. Per-token rates move; the run costs here were computed at the rates in force on the day each run was measured, and they are a record of what we paid rather than a current price list.