The Replan Rate

Abstract.

ReAct agents re-send their whole history on every step, so input tokens grow with each tool call. Plan-and-execute agents split the job: one planner call, cheap workers that each read one tool result, and one solver call. We built a small cost model of an 8-step research task and varied one assumption, how often the cheap workers fail and force a replan. At a 10% replan rate the split agent bills about 3.3x fewer tokens and costs about 78% less than ReAct on Sonnet 5.5, and 45% less than ReAct on Sonnet with prompt caching. It stops being cheaper than cached ReAct at roughly a 39% replan rate. The practical takeaway: the saving comes from isolating reads, not from the cheap model alone, and it depends on a number most teams do not measure.

All figures come from our own illustrative model, built on Anthropic list prices retrieved November 2, 2026. They are not measured production traces, and nothing here comes from Nadir customer data. The model prices tokens only. It does not score answer quality.

Research question.

If a frontier model plans once and a small model executes the steps, how much cheaper is that than a ReAct loop, and at what executor failure rate does the saving disappear?

We have covered where ReAct tokens go in The ReAct anatomy post and the quadratic history cost in Your Agent Is O(n²). This post tests one specific fix, and the one assumption that can break it.

Background.

ReAct interleaves reasoning and tool calls. Each turn re-sends the system prompt, the tool schemas, and every prior thought and observation. The ReWOO paper (Xu et al., 2023, arXiv:2305.18323) named this redundancy and proposed decoupling a Planner, Workers, and a Solver. The authors report about 5x token efficiency and a 4% accuracy gain on HotpotQA, and argue that decoupling lets smaller models take over parts of the work. Those are the authors' numbers on one benchmark from 2023, not a promise for your workload.

The pattern is now common in practitioner writing. Public posts describe a capable planner and cheaper executors, and also name the catch: when the executor is too weak, steps fail, the replanner is called more often, and the saving shrinks (see this overview of plan-and-execute vs ReAct and Morph's planner and executor routing write-up, both vendor or practitioner sources, not peer reviewed). We wanted to put a number on that catch.

Method.

We modeled one task in Python, with every assumption explicit. The code is at the end.

Agents compared:

1. ReAct, one model, on Opus 5.5 and on Sonnet 5.5, with and without caching.
2. Plan-and-execute. Opus 5.5 writes a 480-token plan (60 tokens per step). Haiku 5.5 workers each run one step from a 700-token prompt, read one 1,500-token tool result, and return a 150-token evidence note. Sonnet 5.5 solves from the plan and the eight notes.
3. Replanning. With probability p per step, a worker fails. We charge a worker retry plus an Opus replan call that reads the plan and half the evidence collected so far.

Two simplifications favor plan-and-execute, and we say so now: the model assumes workers compress a 1,500-token result into a 150-token note without losing what the solver needs, and it does not cache the split agent. Latency uses assumed prefill and decode speeds per model. Parallel workers are modeled as 50% of steps being independent.

Results.

1. Most of ReAct's bill is re-reading.

ReAct bills about 95,500 tokens for the task. Only about 12,000 are tool output read for the first time. The remaining input is the prefix sent nine times and prior history read again. The split agent bills about 29,000, and tool output is its largest slice because each result is read once, by a model that never sees the others.

That is the mechanism. A ReAct call at step 9 carries about 17,000 input tokens. A worker call carries 2,200 whatever the step number.

2. Cost.

Compared with the one-model baselines, 10% replanning is 89% cheaper than ReAct on Opus and 78% cheaper than ReAct on Sonnet. The honest comparison is the cached one. Caching alone cuts ReAct on Sonnet by about 60%, and plan-and-execute at 10% replan is still 45% below that. Caching and isolation attack the same re-reading, and the gap between them is smaller than the headline.

3. The failure rate decides the winner.

Plan-and-execute rises from $0.034 at no failures to $0.168 if every step needs a replan. It stays below uncached ReAct on Sonnet across the whole range, and crosses cached ReAct on Sonnet at about 39%. Past that point the cheap layer is sending the expensive planner back in too often.

The chart prices tokens, not truth. A worker that fails silently, returning a plausible but wrong note, never triggers a replan, so it looks cheap and corrupts the answer. The replan rate only means something if failures are detected.

4. Latency improves, with a caveat.

The split agent runs fewer slow calls over short contexts, so it finishes sooner even when workers run one after another (48s against 56s on Sonnet, in our assumed speeds). Parallel workers take it to 41s. Parallelism adds nothing to billed tokens in this model, but it only works for steps that do not depend on each other. Research tasks that follow leads, where step 4 depends on what step 3 found, do not parallelize and are also the ones that replan most.

Discussion.

Isolation is the lever, the cheap model is the multiplier. Most of the saving in our model comes from workers reading one result each. The Haiku price multiplies a smaller token count.

Plan-and-execute is a bad fit for exploratory work. If you cannot write the plan before seeing the first result, you replan constantly. ReWOO itself notes that tasks needing stage-wise learning from the environment suit it poorly.

Small models are not always cheaper. A worker that fails 40% of the time costs more than a mid-tier model that fails 5%. See The Retry Tax for the same effect in single-call routing.

There is a cheaper first move. If ReAct is already in production, clearing old tool results and trimming reasoning history captures part of this saving without a rewrite. See Delete What It Already Read.

Caching helps only when the prefix repeats. It did here because the history grows by appending. Anything that edits earlier context breaks it.

Implementation guide.

1. Instrument by stage. Tag every call as plan, work, replan, or solve, and log input and output tokens for each. Without this you cannot compute the replan rate.
2. Separate reasoning from context tokens. Output tokens are the small, expensive part. Input tokens are the large, cheap-per-token part. Optimize them differently.
3. Detect re-reading. For each call, count input tokens that were already in an earlier call. That share is your isolation opportunity.
4. Route simple steps to cheaper models. Lookups, extraction, and formatting steps are worker candidates. Planning and final judgment usually are not.
5. Compress after retrieval. Have the worker extract evidence from a result, instead of compressing the prompt blindly before you know what matters.
6. Add confidence thresholds and fallback. Require workers to return a check (a schema match, a cited span). On failure, retry once, then escalate one tier before triggering a replan.
7. Monitor cost, latency, and quality together. Track replan rate next to cost per resolved task. A falling bill with a rising failure rate is not a saving.

The model, in code.

PRICE = {"opus": (4, 20), "sonnet": (2, 10), "haiku": (0.10, 0.50)}  # $/M in, out
N, S, Q, T, R, F = 8, 3000, 300, 1500, 250, 800
W, E, PLAN = 700, 150, 480

def usd(m, i, o):
    return (i * PRICE[m][0] + o * PRICE[m][1]) / 1e6

def react(m):
    return sum(usd(m, S + Q + k * (R + T), R if k < N else F) for k in range(N + 1))

def plan_exec(p):                      # p = share of steps that force a replan
    c = usd("opus", 1800, PLAN) + N * usd("haiku", W + T, E)
    c += usd("sonnet", 1800 + PLAN + N * E, F)
    c += p * N * (usd("opus", 1800 + PLAN + 600, PLAN // 2) + usd("haiku", W + T, E))
    return c

print(react("opus"), react("sonnet"), plan_exec(0.10))

This uncached version prints about 0.427, 0.213, and 0.047. The full model with caching and latency is in the charts' source and follows the same formulas. Change T, E, and p to your own measured values before drawing any conclusion.

Where Nadir fits.

This is the kind of problem a routing and observability layer is built for. Instead of treating every step as an Opus-level problem, you can classify the complexity of each step and send planning to a strong model and extraction to a cheap one. Nadir's gateway does this per request with model="auto", and its observe mode records what routing would have chosen so you can see your own stage mix, and your own failure rate, before changing anything. Savings depend on your workload, and nothing in this post forecasts yours.

Try Nadir with a free key, or estimate savings from your current spend.

Limitations.

• Synthetic task, fixed token counts, one tool-output size. Real traces vary widely.
• No quality scoring. The model assumes workers preserve what the solver needs.
• The split agent is uncached and ReAct is cached in one bar, which understates the split agent's best case and overstates its worst.
• Latency speeds are assumptions, not measurements.
• Replan cost is a simple expectation, not a simulation of failure cascades.

Conclusion.

The future of LLM cost optimization is not just cheaper models. It is better orchestration, better routing, better retrieval discipline, and better measurement. In our model, splitting planning from reading cut billed tokens by about 3x, and the saving held against a cached baseline until about 39% of steps needed a replan. Measure that one number on your own agent first.

Sources: [Xu et al., "ReWOO: Decoupling Reasoning from Observations for Efficient Augmented Language Models," arXiv:2305.18323](https://arxiv.org/abs/2305.18323). [Plan-and-Execute versus ReAct, jacar.es](https://jacar.es/en/plan-and-execute-versus-react/). [Multi-Agent Model Routing, Morph](https://www.morphllm.com/multi-agent-model-routing). [Anthropic, Pricing](https://claude.com/pricing), retrieved November 2, 2026. Prices per million tokens: Opus 5.5 $4 input and $20 output, Sonnet 5.5 $2 and $10, Haiku 5.5 $0.10 and $0.50. Charts were generated with Python and seaborn from the illustrative model described above.