- tools.md: drop the stray article in "every tool is a defined as" and the doubled word in "Toolbox classes can be be configured".
- contributing.md: fix the doubled "an an" in the example prompt (both the streaming and --no-stream snippets).
The description of the `register_fragment_loaders` hook incorrectly
referred to `register_template_loaders` as the hook to use. These are
two distinct hooks; fragment loader plugins must use
`register_fragment_loaders`.
Also fixed a typo: "de-duplicatino" → "de-duplication".
AI-assisted contribution.
The async execute_tool_calls() silently dropped calls to tools that
were not in tools= (or had no implementation): output and exception
were assigned but no ToolResult was ever appended, so the next
provider call carried an assistant tool_call with no matching result
- which OpenAI and Anthropic reject. The sync executor already
returned an 'Error: tool ... does not exist' result.
The async path now mirrors the sync one: before_call fires (and can
CancelToolCall) even though the tool is unavailable, and an error
ToolResult is appended in call order. Also removes the now-unreachable
tool-is-None branch from the inline sync-implementation path.
This matters more since chain resume landed: a pending call whose
tool is no longer registered would otherwise never resolve.
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
* PauseChain primitive + chain resume from pending tool calls
Two features that together give chains a first-class suspend/resume
story for human-in-the-loop tools:
llm.PauseChain: raise inside a tool implementation to stop the chain
cleanly. Unlike other exceptions it is not converted into an error
ToolResult - it propagates to the caller with .tool_call (the paused
call) and .tool_results (completed sibling results) attached, and no
provider call is made with a placeholder result. Failure semantics
for concurrent tool execution are now defined: async sibling tasks
always run to completion before a pause or hook exception propagates
(gather with return_exceptions, raised after collection), so nothing
is orphaned mid-flight; sync execution stops at the paused call,
leaving later calls unstarted so they can safely run on resume.
Chain resume: chain(messages=history, tools=...) now detects a
history ending in an assistant message with unresolved tool calls -
e.g. one persisted when a previous run paused or crashed - executes
those calls through the normal before_call/after_call machinery
(skipping any that already have results), then sends the results to
the model as a standard tool-result turn. A resumed call may pause
again, enabling multi-question flows. Histories where a user or
assistant message follows the calls are left alone. Also adds
execute_tool_calls(tool_calls_list=) for executing an explicit list.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Guarantee every tool call has a unique tool_call_id
add_tool_call() now synthesizes a unique tc_-prefixed id (monotonic
ULID) whenever the provider did not supply one. Previously consumers
correlating tool calls with results - or keying external state on a
specific invocation - had to invent fallback matching schemes for
id-less providers, and test models like llm-echo exercised different
code paths than production providers.
Provider-supplied ids are preserved untouched, and responses
rehydrated from the logs database keep their stored ids (synthesis
only happens at add_tool_call time). Existing tests that asserted
tool_call_id None now normalize or mask the synthesized ids.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Tool implementations can receive the ToolCall via llm_tool_call parameter
Tool functions (sync or async, including Toolbox methods) that declare
a parameter named llm_tool_call are now passed the llm.ToolCall object
for the current invocation. The parameter is reserved: it is excluded
from the input schema exposed to the model and is only injected when
declared explicitly - a **kwargs catch-all does not receive it.
This lets tool implementations key external state against the unique
tool_call_id, e.g. for human-in-the-loop approval flows that need to
resume a specific tool call after the answer arrives.
Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
* Ran Black
---------
Co-authored-by: Claude Fable 5 <noreply@anthropic.com>
When building the `input` list for the OpenAI Responses API from prior
conversation turns, an assistant text-only turn was being serialized as:
{"role": "assistant",
"content": [{"type": "output_text", "text": "..."}]}
The openai-python SDK's EasyInputMessage shape uses a plain string for
this case, matching what a direct OpenAI Responses call would send. Use
the same shape so our history matches the SDK exactly, and add tests
covering both _build_responses_input and a two-turn response.reply()
flow.
Response keeps two parallel stores: _stream_events (read by to_dict /
response.messages) and _tool_calls (read by execute_tool_calls). Only
the messages were correctly serialized, leaving _tool_calls unrecorded.
Part assembly now also walks _tool_calls and appends a ToolCallPart
for any tool_call_id not already represented by a StreamEvent-derived
Part.
Closes#1433
The previous commit wired up encrypted_content round-trip but only
tested that the data flows through correctly on a single tool round-
trip. This adds a multi-turn cassette test that proves the full
interleaved-reasoning capability:
- Each turn produces fresh reasoning_tokens (not just the first)
- Every prior reasoning block is round-tripped on every subsequent
turn (the Nth turn echoes >= N-1 reasoning items)
- ReasoningParts persisted on the assistant messages carry the same
encrypted_content + id that gets sent back on the wire
The puzzle is shaped so the model can't parallelize tool calls -
each db_lookup result tells it the next key to use, forcing the
model to think between calls. The recorded 4-turn chain shows
reasoning_tokens of 45/98/196/17 across turns with reasoning items
accumulating in every outgoing input.
This is the GPT-5-class capability that Chat Completions can't
deliver because it discards reasoning between turns.
When the Responses API returns a reasoning item alongside function
calls, capture its opaque id + encrypted_content as provider_metadata
on the resulting ReasoningPart. _build_responses_input already echoed
that metadata back as a reasoning input item on the next turn - now
the output side actually populates it.
This preserves the model's hidden chain of thought across the tool
round-trip. Without it, GPT-5-class models silently lose ~3% on
SWE-bench (per OpenAI) when used with tools.
Adds a dedicated VCR test that asserts the encrypted_content captured
on the first turn appears verbatim in the second turn's outgoing
request body.
Adds Responses and AsyncResponses classes that drive the OpenAI
/v1/responses endpoint. The existing Chat / AsyncChat classes are
unchanged because other plugins import them.
gpt-5.5 (and gpt-5.5-2026-04-23) is now registered against Responses
by default. Pass `-o chat_completions 1` to fall back to the older
/v1/chat/completions code path.
This is feature parity with the Chat path (text, tools, streaming,
schema, reasoning_effort, verbosity, attachments, system prompts).
Interleaved reasoning across tool round-trips is not exercised yet -
encrypted reasoning items are accepted on the input side, but the
plugin doesn't yet stash them on outgoing ReasoningParts.
Accepts model options as an explicit dict alongside the existing
**kwargs form. The kwargs form continues to work unchanged for
backwards compatibility but is no longer documented. Mixing the two
forms with overlapping keys raises TypeError.
Applies to Model.prompt, Conversation.prompt, Response.reply and
their async equivalents. .chain() already used this pattern.
Co-authored-by: Claude <noreply@anthropic.com>
Each row stores only its current-turn inputs, so a loaded tool-result
response began with an orphan tool_result. `llm -c` then sent a request
with an unexpected tool_use_id. Stitch each response's messages onto the
previous response's chain plus its assistant output during load.
Closes#1426
Refs https://github.com/simonw/llm-anthropic/issues/68
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Simon Willison