Iterate prev_response.prompt.messages (the computed Message list) to
rebuild prior turn inputs, and funnel each through
_append_message_from_message. Output side still uses the flat text /
tool_calls accumulators (text_or_raise, tool_calls_or_raise) to avoid
calling _build_parts on historical responses whose StreamEvent shape
might have used the same part_index for mixed content types.
prompt.messages is now a computed property that synthesizes Messages
from legacy inputs (system=, parts=, prompt=, attachments=,
tool_results=) when messages= was not explicitly passed. Explicit
messages= passes through verbatim.
OpenAI build_messages() for the current prompt now has a single code
path that iterates prompt.messages — the old if/elif over _parts vs
legacy fields is gone. Conversation history reconstruction still uses
legacy fields (will flip in a later commit).
Accept messages= alongside the existing parts= parameter.
Conversation/AsyncConversation/Model/AsyncModel prompt() forward it to
Prompt, which stores it as prompt.messages.
OpenAI adapter gains _append_message_from_message which translates one
llm.Message into the correct OpenAI message dict(s), including the
parallel-tool-calls case (one assistant message with multiple
ToolCallParts becomes one OpenAI message with a tool_calls array).
Legacy paths untouched: parts=, prompt=, system=, attachments=, and
tool_results= still work when messages= is not set.
Round out the parts API so transcripts survive serialization and so
providers can stash opaque multi-turn state on parts and stream events.
Serialization:
- AttachmentPart.from_dict now supported; inline content bytes round-trip
as base64.
- ToolResultPart.attachments round-trip through to_dict/from_dict.
Stream assembler:
- _build_parts raises ValueError when an incompatible StreamEvent type
appears at the same part_index, instead of silently overwriting the
earlier part. tool_call_name and tool_call_args stay compatible.
OpenAI parts=[] support:
- build_messages emits assistant tool_calls and role:"tool" messages for
ToolCallPart and ToolResultPart passed via parts=.
provider_metadata:
- New optional dict on TextPart, ReasoningPart, ToolCallPart,
ToolResultPart, and StreamEvent for opaque provider data that must be
echoed back on the next request (Anthropic signature/encrypted_content,
Gemini thoughtSignature, OpenAI Responses encrypted_content).
- StreamEvent values merge onto the finalized Part per top-level namespace
key, last non-None wins.
- Persisted via existing content_json column and reloaded by
_load_parts_from_db; no schema change.
- Plugin author guide in docs/plugins/advanced-model-plugins.md.
Types:
- Widen execute() return types to Iterator[str | StreamEvent] /
AsyncGenerator[str | StreamEvent, None] on abstract Model/AsyncModel
bases and OpenAI Chat implementations.
- Initialize _reasoning_token_count on _BaseResponse so mypy stops
flagging the OpenAI plugin.
Chat.execute() and AsyncChat.execute() now yield StreamEvent instead
of bare strings. Text chunks, tool call names/args are all emitted
as typed events. Reasoning token counts from usage data are stored
on the response and _build_parts() prepends a redacted ReasoningPart.
StreamEvent gains server_executed and tool_name fields for use by
plugins with server-side tool execution.
Tested live against gpt-5.4-mini: text streaming, tool calls, and
reasoning tokens (with reasoning_effort='high') all work correctly.
Co-Authored-By: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* Add type annotations for OpenAI Chat/AsyncChat/Completion execute methods
* Add type hint for OpenAI _Shared class
* cast(Response) to make mypy happy
Co-authored-by: Simon Willison <swillison@gmail.com>
* Recorded instance of streaming tool response variant "a".
This is the typical response, where "arguments":"" arrives
first in the stream, followed by "arguments":"{}"
The response data is a real capture from the OpenRouter API,
however some request and header data may be from other test fixtures.
* Recorded instance of streaming tool response variant "b".
This is a streaming response where the first arguments
you get is a fully formed "arguments":"{}"
The response data is a real capture from the OpenRouter API,
however some request and header data may be from other test fixtures.
* Test cases for streaming tool responses.
Note that the replays are marked as "read-only", as they are variants
seen in the wild where the streaming tool call argument fragments
arrive in a specific order.
* Fix streaming tool response variant "b", where "arguments":"{}" is what arrives first.
The previous code erroneously caused the first "arguments" to be duplicated,
by using "+=" even when being initially set.
This went unnoticed as many models stream "arguments":"" first.
When a more fully formed "arguments" fragment arrived first, it was causing
"Error: Extra data: line 1 column 3 (char 2)"
* Recorded instance of streaming tool response variant "c".
This was failing with "Error: unsupported operand type(s) for +=: 'NoneType' and 'str'"
The response data is a real capture from the OpenRouter API,
however some request and header data may be from other test fixtures.
* Test case for streaming tool response variant "c".
* Fix streaming tool response variant "c".
However, I'm not sure why arguments was initially not present or seen as None.
Closes#1014
- llm.ToolOutput(output='...', attachments=[...]) for tools to return attachments
- New table: `tool_results_attachments`
- Table is populated when tools return attachments
- llm --tools-debug shows attachments returned by tools
- llm logs shows attachments returned by tools
* Sync models can now call async tools, refs #987
* Test for async tool functions in sync context, refs #987
* Test for asyncio tools, plus test that they run in parallel
* Docs for async tool usage
* llm/default_plugins: add o3 model
This is the newest model released by OpenAI and is available through
the API.
* Ran cog
---------
Co-authored-by: Simon Willison <swillison@gmail.com>
Recently support for structured output was added. But custom
OpenAI-compatible models didn't support the `supports_schema` property
in the config file `extra-openai-models.yaml`.
* Allow "reasoning" for extra-openai-models.yaml
Currently you get an error when trying to use `-o reasoning_effort high` with a model that has been defined in `extra-openai-models.yaml`.
This allows a `reasoning` field.
* Mention reasoning: true in other OpenAI models docs
---------
Co-authored-by: Simon Willison <swillison@gmail.com>
Refs #776
* Implemented new llm prompt --schema and model.prompt(schema=)
* Log schema to responses.schema_id and schemas table
* Include schema in llm logs Markdown output
* Test for schema=pydantic_model
* Initial --schema CLI documentation
* Python docs for schema=
* Advanced plugin docs on schemas
* New KeyModel and AsyncKeyModel classes for models that taken keys - closes#744
* llm prompt --key now uses new mechanism, including for async
* use new key mechanism in llm chat command
* Python API tests for llm.KeyModel and llm.AsyncKeyModel
* Python API docs for for prompt(... key="")
* Mention await model.prompt() takes other parameters, reorg sections
* Better title for the model tutorial
* Docs on writing model plugins that take a key
Simon Willison