Tools

Newer Claude models send malformed edit-tool calls to Pi, causing compatibility issues

Armin Ronacher discovered that recent Anthropic Claude models (including Opus 4.8 and Sonnet 5) sometimes call Pi’s edit tool with invented extra fields in the edits[] array, so Pi rejects the tool invocation.

Newer Claude models send malformed edit-tool calls to Pi, causing compatibility issues

Armin Ronacher reported a compatibility problem he encountered while hacking on Pi: recent Anthropic Claude models, notably Opus 4.8 and Sonnet 5, sometimes call Pi’s edit tool with invented extra fields in the nested edits[] array. The actual edit instructions are usually correct, but the arguments do not match Pi’s schema, so Pi rejects the tool call and asks the model to try again.

What exactly is happening

  • Newer Claude-family models occasionally include undocumented or made‑up keys inside the edits[] array when invoking Pi’s edit tool.
  • Although the content of the edits (for example, what to replace and with what) is typically right, the structural mismatch causes Pi to refuse the call.
  • This behavior appears specific to the newer models: Armin observed it in Opus 4.8 and Sonnet 5, but not in older Claude versions.

Why this is surprising and a likely cause

It is expected that models sometimes produce malformed tool calls, especially smaller models. What surprised Armin is that the latest, state‑of‑the‑art Claude models show the problem more often than their predecessors. He hypothesizes that more recent Anthropic models have been specifically trained (likely via Reinforcement Learning) to use the edit tools built into Claude Code more effectively. That focused training can produce models that favor the Claude Code edit schema, and therefore misuse other services’ custom edit tool schemas such as Pi’s.

Tool schema differences

  • Claude’s edit tool follows a search‑and‑replace approach.
  • OpenAI’s Codex family has used an apply_patch mechanism instead, and OpenAI has discussed training their models to use that tool effectively.

These differences suggest model behavior around tool use can be influenced heavily by the particular edit interface used during training.

Implications and possible responses

The immediate practical consequence is compatibility friction for third‑party coding harnesses and integrations that implement their own edit APIs. Possible responses include:

  • Implementing multiple edit tools in third‑party systems so the harness can select the edit interface best suited to the chosen model.
  • Adding stronger validation and normalization layers that automatically correct or reject malformed tool calls and either transform them into the expected schema or request a corrected invocation.
  • Engaging with model developers to pursue better standardization of edit tool schemas or to reduce overfitting of models to a single built‑in schema.

Conclusion

Armin’s report highlights that newer Claude models (Opus 4.8, Sonnet 5) are more prone to emitting edits[] arrays with extra, invented fields when calling Pi’s edit tool, causing Pi to reject those calls. The phenomenon likely stems from training that optimizes models for Claude Code’s built‑in edit schema, creating interoperability issues for external tools. This raises practical questions about whether third‑party coding platforms should support multiple edit schemas or otherwise adapt to model‑specific tool‑use behaviors.