← Back to Blog

Better Models, Worse Tools: The Hidden Retry Cost of Agent Tool Schema Failures

By Eric Bush · July 6, 2026 · 8 min read

Engineering team collaborating around a laptop while debugging agent tool behavior

The Expensive Part of Tool Failure Is the Retry Loop

Armin Ronacher recently observed that newer Claude models can emit extra tool schema fields under some schemas. The practical lesson is not that a model is universally broken, or that every schema will fail. The lesson is narrower and more useful: tool schema mismatches create hidden retry costs. Every rejected tool call can trigger another model turn, another validation message, another repair attempt, and sometimes a confused agent state.

For AI coding agents, that matters because tool calls are the work loop. Reading files, editing files, running tests, creating commits, searching logs, and calling internal APIs all pass through schemas. A small schema ambiguity can become dozens of wasted requests across a long session.

How Schema Failures Become Token Spend

Tool validation failures rarely appear on a finance dashboard as their own line item. They show up as higher average session cost, more input tokens from repeated error messages, more output tokens from repair attempts, and longer time-to-completion. If the agent retries automatically, the developer may not even see the failure until the task feels slow and expensive.

Failure mode Token impact Engineering impact
Extra fields rejected Validation error plus repair turn Agent may repeat the same malformed call.
Ambiguous optional fields Extra reasoning and retries Tool output becomes harder to predict.
Overly broad enums Correction prompts after wrong mode Agent chooses plausible but unsupported actions.
Nested schema complexity Longer tool definitions every turn Higher chance of partial invalid JSON.
Weak error messages Multiple repair attempts Model lacks a precise fix target.

Better Models Can Expose Worse Tool Contracts

It is tempting to interpret schema failures as model regressions. Sometimes they are. But many failures reveal that the tool contract was under-specified, too permissive, or optimized for a previous model's habits. A stronger model may infer fields that seem semantically useful but are not allowed by the schema. A stricter validator then rejects the call, even though the model was trying to be helpful.

The cost-control response is not to panic-switch models after one anecdote. It is to test tools against the models you actually route to, measure retry rates, and fix schema design. The model is only one side of the contract. The schema, examples, validation error, and retry policy are the other side.

A Retry Cost Example

Imagine an agent run with 60 tool calls. If 10% fail validation and each failure triggers one repair turn, that is six extra model turns. If each repair turn carries 40,000 input tokens of context and 1,500 output tokens, the session adds 240,000 input tokens and 9,000 output tokens without making product progress. At Claude Sonnet 4.6 prices listed in this site's calculator, that retry overhead is roughly $0.72 in input and $0.135 in output, or about $0.86 for that one session. Multiply that by hundreds of daily sessions and schema quality becomes a real budget line.

The exact dollars vary by model, cache behavior, and context size. The pattern does not. Retry cost scales with context length, not just with the failed tool call. That is why tool bugs feel disproportionately expensive in long coding sessions.

Schema Design Rules That Reduce Retries

  • Set additionalProperties deliberately. If extra fields must be rejected, make the accepted fields obvious and provide strong examples.
  • Prefer small tools over universal tools. A focused edit tool is easier to call correctly than a giant operation tool with many modes.
  • Use clear enum names. Avoid near-synonyms that invite plausible but wrong choices.
  • Make optional fields truly optional. If a field is required for most calls, mark it required and explain it.
  • Return repairable validation errors. Tell the model exactly which field failed and what valid input looks like.

What to Measure Before Blaming the Model

Teams should log tool validation errors by model, tool name, schema version, failure reason, retry count, and final task outcome. The key metric is cost per successful tool action, not raw model accuracy. A model with slightly more first-call errors may still be cheaper if it repairs quickly and completes tasks with fewer total steps. A model with fewer schema errors may be more expensive if it takes longer paths through the same task.

Also separate schema failures from downstream execution failures. Invalid JSON, rejected extra fields, permission errors, flaky tests, and missing files are different problems. Combining them into a single "agent failed" bucket makes cost optimization impossible.

The Budget Policy

A good default policy is simple: if a tool's validation retry rate exceeds 3% across production agent sessions, treat it as an engineering bug. If it exceeds 10%, pause broad rollout or route that tool only through models with proven behavior. If a tool failure causes more than two automatic retries, stop the loop and ask for human confirmation. Infinite repair loops are one of the fastest ways to turn a cheap coding task into an expensive session.

Use the AI Cost Estimator to model retry overhead by adding expected failed turns to your input and output token budget. The hidden cost is usually not the schema text itself; it is the long-context repair loop after validation fails.

Want to calculate exact costs for your project?

Frequently Asked Questions

Did Armin Ronacher say newer Claude models always fail tool schemas?

No. The relevant observation is narrower: newer Claude models can emit extra tool schema fields under some schemas. The cost lesson is to measure retries and fix schema contracts, not to claim universal model failure.

Why do tool schema failures increase AI coding cost?

Each failed tool call can add validation errors, repair prompts, repeated context, extra output, and additional agent turns. In long-context sessions, those retries can be more expensive than the original tool call.

What metric should teams track for tool schema quality?

Track validation retry rate by model, tool, schema version, failure reason, and cost per successful tool action. Raw failure count alone is not enough.

How can teams reduce schema retry cost?

Use focused tools, clear required fields, deliberate additionalProperties settings, unambiguous enums, stable examples, and repairable validation errors that tell the model exactly what to fix.

When should an agent stop retrying a failed tool call?

A practical policy is to stop after two automatic repair attempts and ask for human confirmation. Repeated automatic retries can silently burn tokens without making progress.