Capability Name

RetryContext

Description

Add an opt-in capability that bounds the context replayed after an output validation failure.

When an output validator raises ModelRetry, the next model request would retain:

• the system prompt and original task
• the latest invalid output
• the latest validation feedback

Earlier invalid output and retry-feedback pairs would be removed. The capability should apply only to output validation. This includes structured ToolOutput validation retries, whose RetryPromptPart can have a non-null output-tool name. Ordinary function-tool validation retries should keep their current history behavior.

This follows the direction discussed in pydantic-ai#4908, where the core maintainer suggested trying the behavior as a standalone capability before considering a core API.

Use Case

Repeated structured-output validation failures can make each retry request much larger than the previous one. A deterministic FunctionModel reproduction on current harness main (818808d) uses a 4 KB system prompt, a 4 KB task, three 40 KB invalid outputs, and three validation failures. The serialized fourth request is 131,607 bytes.

Keeping only the newest correction pair should reduce that request below 80,000 bytes without changing the retry count or final result. The accompanying evaluator also checks that the system prompt, original task, newest invalid output, and newest validation feedback remain present; earlier failed attempts are absent; and tool-call retry messages are byte-for-byte unchanged.

The exact public name and configuration are open for discussion. The important contract is that the behavior is opt-in and limited to output validation retries.

Hooks / Integration Points

• before_model_request or HistoryProcessor to reshape the request before it reaches the model
• Output-validation retry detection using the latest RetryPromptPart
• No changes to tool-call retry context

Prior Art / References

• pydantic-ai#4908
• The userland HistoryProcessor workaround in that issue