The 272K Cliff and Agentic Workload Planning

Most pricing surprises in API billing come from volume — you simply used more than you thought you would. OpenAI's long-context repricing rule is a different kind of surprise entirely, because it isn't about volume at all. It's a threshold. Cross it by a single token and the price of the entire request changes, not just the part of it that pushed you over. That's worth sitting with for a moment, because it's genuinely unusual as pricing mechanics go, and it has real consequences for anyone running agentic coding sessions that accumulate context as they go.

What the rule actually says

OpenAI states it plainly, once you find the right page: requests whose input exceeds the published threshold are priced at a higher input rate and a higher output rate, for the full request. Not the marginal tokens over the line — the whole thing. A request that would have cost one amount at the standard rate can cost meaningfully more the moment its input crosses that boundary, purely because of where the line sits, not because of how far past it you went.

This is worth contrasting with how a lot of people intuitively expect tiered pricing to work, because most tiered pricing they've encountered elsewhere — income tax brackets are the classic example — applies the higher rate only to the amount above the threshold. OpenAI's long-context rule doesn't do that. It's a cliff, not a ramp, and treating it like a ramp when you're estimating a bill will understate the actual cost of every request that crosses it.

Why this bites agentic workloads specifically

A single chat message rarely gets anywhere near a threshold like this. An agentic coding session reading through a real codebase, accumulating file contents, tool outputs, and prior turns into its own context window over the course of a long session, absolutely can — and the moment it does, every subsequent request in that session (assuming it keeps growing) can be paying the higher rate on its entire input, not just on the portion that grew past the line.

That has a genuinely counterintuitive implication for cost control: the naive instinct is to worry about output tokens, because output is what you're "asking for" and it's priced higher per token than input already. But for a long agentic session, the input side — everything the model has to re-read to understand the accumulated state of the conversation — is often what actually determines whether you're paying the standard rate or the long-context rate, and it grows on every single turn whether or not you asked it to.

Not every model publishes the same rule

Here's the detail that makes this genuinely worth checking model by model rather than assuming it travels with the model family: the rule is published for most of the current model lineup, but it's explicitly not stated on every model's own page. Some smaller models with meaningfully smaller context windows don't publish a long-context repricing rule at all — which makes sense, since their windows don't extend far enough for the threshold to be a realistic concern in the first place. And at least one larger-context model in active use simply doesn't state the rule either way, which this site records honestly as "not published" rather than assuming it inherits the behaviour of its siblings. Assuming a rule that isn't published for a specific model is exactly the kind of mistake that produces confidently wrong cost estimates — the same mistake, structurally, that this site's own first research pass made three separate times before a second, more careful pass caught it.

What this means in practice

If you're running anything agentic and long-lived — a multi-turn coding session, a pipeline that keeps accumulating context across steps — the practical move isn't to avoid long context altogether; a genuinely large context window is often exactly what makes an agentic session useful in the first place, letting it hold an entire codebase's relevant context rather than re-deriving it turn by turn. The practical move is to know where the threshold sits for the specific model you're running, and to treat crossing it as a deliberate decision rather than something that happens to you by accident partway through a long session.

That's a planning problem, and it's the specific problem this site's tools exist to make visible rather than leaving buried in a bill you only see after the fact — a request priced ahead of time will tell you plainly when it's about to cross the line, before you've committed to running it.

The honest caveat

This site states the rule exactly as published, per model, and says explicitly where a model's own page doesn't state it either way. That's a deliberately narrower claim than "here's how long-context pricing works," and it's the right amount of confidence to have about a rule that, on the evidence of at least one un-stated case, genuinely doesn't apply uniformly across every model in the lineup.

Why a cliff is a stranger design than it looks

Sit with the mechanics for a second longer, because it's worth understanding why a vendor would choose a cliff over a ramp in the first place. A ramp — charging the higher rate only on tokens past the threshold — is simpler to explain and gentler to a bill that happens to land just past the line. A cliff is harsher, but it's also a much cheaper thing to compute and reason about on the serving side: a request either needs the long-context serving path or it doesn't, and that's very likely a genuinely different, more resource-intensive code path on OpenAI's infrastructure, not just a different number in a billing table. The pricing, in other words, is probably tracking a real difference in what serving that request costs OpenAI, not an arbitrary line drawn to make more money off long prompts specifically. That doesn't make the cliff pleasant to budget around, but it does make it a more defensible design than "pricing tiers for their own sake" would be.

What this means for how you should actually write agentic loops

If you're building anything that runs Codex in a loop — reviewing a pull request, walking a test suite, iterating on a refactor — the context accumulated across turns is exactly the kind of growth that eventually meets this threshold, and it's worth treating "how big is my context getting" as a value you check between turns, not just something you notice after a session finishes and the bill looks unusual. A loop that periodically summarises or trims what it's carrying forward, rather than accumulating every tool output verbatim forever, isn't just good engineering practice for keeping a model focused — it's also a direct lever on which side of this threshold your later requests land on.

The number that actually matters isn't the threshold itself

It's worth being precise about what you're actually tracking here, because "watch your context size" is easy advice to nod along to and hard to act on without a specific number in front of you. The threshold is measured in input tokens specifically — not total context, not output, input. A session that's sent a moderate amount of input but is generating a very long output is nowhere near this cliff no matter how long its answers get; a session accumulating a large amount of file content and prior turns as input is the one that needs watching, and that's exactly the shape of a typical agentic coding session working across a real codebase.