Long-Running Agents in Production Just Got Cheaper

For about two years, the standard advice for running an agent on a long task was to keep its session short. Summarize, compact, hand off, start fresh. Carrying a large context across many turns was the expensive part, so everyone learned to avoid it.

On September 1, Anthropic shipped Claude Fable 5.1, and one line on the pricing page changed that calculation. Here is what actually got cheaper, what it unlocks, and the three failure modes a longer session makes worse rather than better.

What actually changed

Three things, all verifiable on the published pricing docs.

Cache reads dropped to 0.025x base input. On Fable 5.1 a cache hit costs $0.25 per million tokens against a $10 per million base input price. That is 2.5% of a fresh read. Every other model uses the standard 0.1x multiplier. On Fable 5, the same cache read was $1 per million, so this is a 75% cut on that line specifically.

A 1M token context window is the default, with up to 128k output tokens. And per the same docs, Claude 4.6 and later include the full 1M window at standard pricing, so a 900k-token request bills at the same per-token rate as a 9k-token request. There is no long-context surcharge to plan around.

Idle time is not metered on managed agent sessions. Claude Managed Agents bills session runtime at $0.08 per session-hour, and that clock accrues only while the session status is running. Time spent idle, waiting for your next message or a tool confirmation, does not count.

Do the arithmetic on a plain case so you can check it. Say your agent carries a 200k-token working context that gets re-read on every turn. At $0.25 per million, that read costs 5 cents. At the old $1 rate it was 20 cents, and reading it fresh with no cache at all is $2.00. Over a 200-turn run, that is $10 against $40 against $400.

Now say plainly what did not change. Base input is still $10 per million and output is still $50 per million. Cache writes are untouched, at 1.25x base input for the 5-minute TTL and 2x for the 1-hour TTL, so writing that same 200k context to cache costs $2.50 or $4.00 depending on the TTL you pick. And a cache miss still costs full freight. The economics improve when your prefix is stable and you actually get hits. They do not improve at all if something in your system prompt invalidates the cache on every request.

One note for accuracy, since the pricing table lists two models at these rates: Claude Mythos 5.1 carries the same numbers but is limited availability, restricted to participants in Anthropic's trusted access programs. Fable 5.1 is the one generally available.

We should also be plain about a bias here. We build on Anthropic Claude, Google Vertex AI Gemini, and OpenAI GPT depending on the problem, and Smile PreVue runs on Vertex AI Gemini under a BAA precisely because the decisive constraint there was HIPAA-grade handling, not model benchmarks. A price change at one lab is a reason to re-run your own numbers, not a reason to standardize on that lab.

Why teams chopped agents into short sessions in the first place

The compaction reflex is so widespread it stopped looking like a decision. Summarize the conversation, hand the summary to a fresh session, continue. Most agent frameworks bake this in as a default, and for good reason: it was the only way to keep a long task affordable.

But it was a cost decision wearing an architecture decision's clothes, and the distinction matters now that the cost half has moved.

Here is what compaction actually charges you, in the currency nobody prices. Every summary is a lossy write. And the thing a summary tends to drop is exactly the thing you need most: the specifics of what already failed. A summary keeps the conclusion, "refactored the auth module," and discards the two approaches that broke and why. Then the fresh session tries one of them again.

We have watched agents rediscover a dead end three times across three compaction boundaries. Each individual session behaved reasonably. The system as a whole was going in circles, because the record of failure was the least summary-shaped thing in the context and it evaporated first.

That is the honest tradeoff, and it does not resolve cleanly in one direction. Compaction buys you a smaller, cleaner window at the cost of losing the texture of what went wrong. Sometimes that is a good trade. It just should not be automatic, and until this month, cost made it automatic.

What a cheap warm context genuinely unlocks

Three shapes of work get meaningfully more practical.

Long unattended runs where memory of attempts matters. A large migration or a multi-file refactor is the clearest case. The agent needs to remember not just the plan but the fourteen things it already tried, which files it touched, and which of those edits it had to revert. That state is expensive to summarize and cheap to keep.

Review loops where a human returns hours later. This is where the idle-time detail earns its place. A session that sits waiting for someone to approve a step is not burning runtime, and its context is still warm when that person comes back after lunch. Approval gates used to carry an implicit cost pressure to hurry. That pressure drops.

Work that was split purely to manage the bill. Some pipelines are three sessions for no reason except budget. If that is the only reason, it is worth re-opening. The handoffs were never free.

We build these in the pattern described in our agent orchestration methodology: deterministic control flow where the work is predictable, model-driven decisions only where genuine judgment is needed. A cheaper warm context does not change that shape. It just widens the middle section where an agent can hold real state without you engineering around the window.

The three things a longer session makes worse

This is the part that matters, because a price drop is not an architecture.

Context rot. More tokens in the window is not more attention on the right ones. A 900k-token session can be less reliable than a 90k one, because the signal you need is competing with hundreds of thousands of tokens of tool output, stale file contents, and paths not taken. Cheap context makes it tempting to keep everything. Keeping everything is not a strategy for getting the model to notice the right thing.

Error compounding. In a short session, a wrong assumption made at minute five dies at the next handoff. That handoff was doing real work as an error boundary, and nobody wrote it down as a feature. Remove it and the same wrong assumption rides along for six hours, and every subsequent decision inherits it. Long sessions do not just extend the good state. They extend the bad state with equal fidelity.

Blast radius. An agent that stays alive longer touches more things. It writes more files, calls more tools, and makes more externally visible changes before any human looks at it. Approval gates and escalation design matter more in this world, not less. The cheapest moment to catch a bad run is still early, and a longer leash moves "early" further from where you are standing.

None of these are arguments against long sessions. They are arguments that the session length was carrying safety properties you did not explicitly design, and if you extend it you have to design them back in on purpose.

How we would decide

A short frame you can reuse. Three questions, in order.

Does the task have state worth carrying? If each step is independent, a long session is just an expensive way to hold tokens you never read. Batch work usually says no here.

Is there a human in the loop who returns late? If yes, the idle-time economics and the warm context are both working for you, and this is the strongest case for a long session.

Can you tell when the agent has gone wrong? This is the one that decides it. If you have evals, tracing, and a clear signal that a run has gone sideways, a longer session is a reasonable bet. If you cannot answer this, a longer session is a worse idea at any price, because you have extended the interval between a mistake and its discovery without extending your ability to see it.

Answer three honestly before you touch one and two. Most teams we talk to have a defensible answer for state and for the human in the loop, and a much vaguer one for detection. That ordering is the actual finding here.

The price change is real and worth acting on. It removes the cheapest excuse for chopping agents into pieces, which means the remaining reasons have to stand on their own merits. For a lot of systems, they still will.

If you are working out whether a long-running agent is the right shape for something you are building, tell us what you are trying to ship. If you would rather learn to drive these tools yourself, that is what /learn is for.