The newest, smartest Anthropic models cannot reliably use Pi, an open-source coding agent that does not match Claude Code’s tool schema. The reason, according to Pi maintainer Armin Ronacher, is that Anthropic’s post-training now optimises for Claude Code’s particular edit tool - and that training leaks into third-party harnesses.
What is happening in Pi
In a July 4, 2026 post titled “Better Models: Worse Tools”, Ronacher documents that Anthropic’s Opus 4.8 and Sonnet 5 invoke Pi’s edit tool with invented fields inside the nested edits[] array - keys like type, id, kind, unique, requireUnique, matchCase, in_file, forceMatchCount, children, notes, cost, oldText2, newText2, oldText_2, and newText2_2 - even though Pi’s schema only accepts oldText and newText. The edits themselves are usually byte-correct; the wrapping JSON is wrong, so Pi rejects the tool call.
“The edit itself is usually correct but the arguments do not match the schema as the model invents made-up keys and Pi thus rejects the tool call and asks to try again,” Ronacher wrote.
The reproduction condition matters. A fresh single-turn prompt like “edit this file” did not reproduce it. It appears only after an agentic history - after the model has read files, diagnosed a problem, and tried to compose a multi-line edit. In a session shared by Petr Baudis, continuing the conversation caused Opus 4.8 to fail about 20 percent of the time. Older Anthropic models do not show the regression. Codex models do not show it either, with one minor exception. The reproducible transcripts and Pi’s GitHub issue #6278 are linked from Ronacher’s post.
Why the smartest models are the worst
Ronacher’s hypothesis is that Anthropic’s newest models have been specifically trained - likely via reinforcement learning - to better use the edit tools baked into Claude Code. Claude Code’s edit tool is not Pi’s nested edits[] shape; it is closer to file_path, old_string, new_string, and an optional replace_all flag. When a model is rewarded for emitting that schema, it builds a strong prior that “this is what an edit tool call looks like.”
“If reinforcement learning happens in a harness like that, or a simulation of one, then slightly malformed tool calls can still complete the task and receive reward. The harness fully absorbs the error,” Ronacher wrote.
He dug into minified Claude Code and found what he calls a “slop harness”: retry paths for malformed tool use, parameter aliases (old_str, old_string, path aliased to file_path), Unicode escape repair, silent filtering of unknown keys, and no use of strict mode. A slightly wrong tool call still completes the task and the RL signal rewards it, because the harness itself repairs the call.
This was not always the case. “When Opus 4.5 launched, it adapted to other edit tools exceptionally well,” Ronacher noted. The contamination shows up in Opus 4.8 and Sonnet 5.
The failure point in token space is informative too. The unexpected keys appear “exactly at the highest-entropy point of that task: after closing a several-hundred-token escaped newText string, where the model must decide } vs , "...".” After writing a long string literal, the model has to remember the schema and decide whether to close the JSON object or open another key - and at that decision point, it samples a plausible Claude-Code-shaped key fresh each time.
Tool schemas are not neutral
Ronacher’s conclusion is uncomfortable: “Tool schemas are not neutral, at least not on Anthropic models.” The fix is constrained decoding. OpenAI’s harmony format uses <|constrain|>json markers so the sampler can switch to JSON-constrained sampling, and OpenAI also offers a LARK grammar option. Anthropic does not document equivalent in-band signaling, though Ronacher suspects “there is probably basic grammar-constrained sampling going on” server-side. When he turned on strict tool invocation in Pi, the malformed calls disappeared. Stripping thinking blocks from history cut the failure rate in half.
Simon Willison linked to Ronacher’s post on July 4 and pointed to OpenAI’s Codex as the counter-example. Codex uses apply_patch rather than search-and-replace, and OpenAI has publicly discussed training models specifically for that tool. The lesson Willison drew: third-party coding harnesses may have to maintain multiple edit tool implementations “just so they can use the one with the best performance for the underlying model the user has selected.”
What This Means
The Anthropic vs. OpenAI parallel is the structural story. OpenAI trained a model to its own apply_patch format and made that format the agentic norm for its tools. Anthropic trained its models to Claude Code’s edit tool format, and that format is now bleeding into every other agentic harness that calls Anthropic models. For anyone building a coding agent on top of Claude, the safest bet is to adopt Claude Code’s tool schema - even if you have a better one - because the model’s priors are biased toward it.
The practical signal for users: if you rely on any third-party agent that wires Claude models to non-Claude-Code tools, expect the newest models to behave worse than older ones on the same harness. Check whether the harness supports strict tool invocation. If it does not, the regression is in the model, not in your prompt.
For anyone running production agentic workflows on Anthropic, this is also a reminder that model upgrades are not drop-in. A version bump from Sonnet 4 to Sonnet 5 can quietly break a third-party tool stack, and the failure mode (malformed arguments, repeated retries, the model thinking it succeeded) is exactly the kind of bug that looks like flaky infrastructure.
The Bottom Line
Anthropic’s flagship models are getting worse at tool schemas that do not match Claude Code’s. The cause is post-training contamination - the same RL that made models better at Claude Code made them worse at everything else. Anthropic lacks the public grammar-constrained tool mode OpenAI ships, so third-party harnesses should turn on strict tool invocation if they have it and plan for the regression to deepen with each new flagship.