--- title: Why it cost that much description: What a run's total is actually made of, why long work gets expensive faster than you expect, and real measured runs that finished several times over their limit. --- If a run cost more than you expected, the answer is almost never one expensive thing. It is the same charge repeated more times than you pictured, plus one charge you had no way to predict. Here is the breakdown, including numbers from our own runs that do not flatter us. ## What a total is made of Five kinds of thing can be metered, and every line on a bill is one of them: **thinking and writing** (tokens in and out), **reading a web page** (per page), **running code in the secure workspace** (per unit of run time), **generating an image** (per image, by size) and **transcribing audio you sent** (per minute). Per-unit rates are on [Model prices](/docs/model-prices); this page is about *how many units a run turns out to need* — and since the first line dominates almost every bill, why a run produces so many more tokens than the request seemed to contain. ## Why long work gets expensive faster than you expect **A run is many model calls, not one.** Each step — deciding what to do, reading a page, writing a chunk, checking its own work — is its own billed call. Twenty steps is charged roughly twenty times. **Every step carries the whole chat back with it.** The model has no memory between calls, so everything so far is sent again each time. The *input* side of the bill grows with every exchange whether or not you typed anything long — ten short turns late in a long chat cost more than the same ten at the start. This is the single biggest reason a long chat's later replies cost several times what its first one did, and attachments and fetched pages ride along the same way: one big attachment is not a one-time charge. **Failed attempts are still billed.** A malformed call that gets retried was real work at a real price, so a run ending in *Couldn't finish* can carry a full bill ([When a run fails](/docs/when-a-run-fails)). **And one charge you cannot predict.** Once a chat's accumulated history gets long enough, Else summarises the earlier part so the work can continue — and that summarising is itself a model call, metered like one. The trigger is worth knowing precisely, because it isn't what you would guess. It fires at about **18,000 tokens of accumulated context** (roughly 70,000 characters of history, including everything you attached and every page it read); **between turns**, so an ordinary short message can set it off; and at **the same threshold whichever engine you are on** — it is sized to the narrowest model Else can run, not the one you chose, so it can fire long before your model was anywhere near full. There is no setting, no warning and no way to turn it off. It is the one item here genuinely out of your hands. We measured this on 30 July 2026. A chat on Fast was given 80,000 characters, then two short messages. It summarised twice without saying so — the history sent with each reply fell from 46,206 tokens to 25,805 to 8,132, *while turns were being added* — and **nothing announced it: no message, no banner, no line on the receipt.** The receipt's detail lists only the model that answered you. On the question that matters — is the charge hidden? — here is exactly what we can and cannot say. Across that chat the money leaving the balance matched the three visible receipts to the cent, with no extra entry: **no material charge went unreceipted.** But a summarising call this size costs roughly a third of a cent, and balances are shown only to the cent, so we **cannot rule out a sub-cent charge folded in invisibly.** Certain either way: the receipt never tells you *how much* of a bill was summarising. We would rather bound that honestly than round it up into a promise. ## Your limit is probably not what stopped it The reason a bill can be several times the number you typed deserves saying here, because it is the most common way a total surprises someone: **on a single message, the number you set is never read.** It is sent to our servers and nothing there acts on it — this is not a limit that fires late, it is a limit that is never consulted. What stops the run is a different ceiling you cannot see or change, and it lands well above anything you would have chosen. Measured runs bear that out, and none of it is your fault or fixable by setting a lower number. That mechanism, the measurements behind it, and what the limit *does* still do on work you hand off are all set out on [Spending limits](/docs/spending-limits). It is the canonical page and it does not soften any of it, so this page sends you there rather than keeping a second copy that could drift out of step with it. The practical consequence for reading a bill: **treat the limit as a budgeting intention, not a cap**, and judge what happened from the receipt. ## What actually reduces a bill - **Start a new chat for a new job.** The highest-leverage habit here: a fresh chat carries no history, so its first replies are cheap again, and it starts over well below the summarising threshold. Continuing an old chat out of convenience is what turns cheap turns expensive. - **Say what done looks like**, so it knows when to stop — see [Writing a good request](/docs/writing-a-good-request) — and **narrow what it may use** when you already know the answer is in the file you attached. A run allowed to browse may browse ([Add-ons](/docs/add-ons)). - **Pick the tier deliberately** for the jobs where it matters, instead of leaving everything on the most expensive one ([Choosing a tier](/docs/tiers-explained)). - **For work you hand off, set the limit low while you are still exploring.** It won't hold precisely, but it does reliably bring long work back to you early — the cheapest place to change your mind. On a single message it buys you nothing, so don't rely on it there. Read the receipt rather than the limit ([Reading a receipt](/docs/reading-a-receipt)).