Responses Lite is an OpenAI Codex Responses transport variant used by some newer Codex models. Right now it’s undocumented to the best of my knowledge, but it’s used within the official codex harness for a subset of GPT models. It moves instructions and tool definitions from top-level request fields into ordered input items and changes several other parts of the request contract which make it feel generally much more natural to changes later.

Responses Lite support is from what I can tell not necessary to improve dynamic tool loading today or to inject additional system level messages. On the other hand it would also introduce a disproportionate amount of model-specific transport complexity.

Why Ordered Context Items are Attractive

Responses Lite decomposes the messages into a more natural way where changes can be made to the system level context and tools regardless of where it is. That said, it also is additive only, thus it does not resolve the issue of not being able to unload tools.

A direct representation would look like this:

additional_tools(initial tools)
developer(base instructions)
user message
assistant tool call
tool result that enabled more tools
additional_tools(newly enabled tools)
developer(new application instruction)
user message

This has several advantages:

• It directly represents the tool state transition pi already records in addedToolNames.
• It gives pi the same mechanism for instruction state transitions without rewriting Context.systemPrompt.
• It removes synthetic search calls for changes that are not searches.
• It preserves the relative ordering of tool availability, application policy, and user input.
• It makes request payloads easier to inspect and explain.
• It should preserve the cache-friendly property of anchoring new definitions and instructions after the stable prompt prefix.
• It provides a natural foundation for eventual Lite support.

Current Pi Behavior

Pi represents the tools active for the current request in Context.tools. When an extension tool adds active tools during execution, the resulting ToolResultMessage records their names in addedToolNames.

For providers with native deferred loading, pi reconstructs the point at which those tools became available:

• Anthropic uses deferred tool definitions and tool_reference blocks.
• OpenAI Responses currently uses synthetic client-executed tool_search_call and tool_search_output items.
• Providers without native support receive the complete current tool list normally.

The OpenAI representation works, but it is indirect. Pi is not actually performing a search: it already knows exactly which definitions were enabled and where they became available. The synthetic search pair exists only to express a tool-definition change inside the transcript.

Pi’s current message model does not have a provider-neutral instruction message inside history. Context.systemPrompt is emitted at the beginning of each request, so changing it rewrites the stable prompt prefix and cannot accurately represent when an instruction became active.

The main gap we thus have is being able to not just add messages, but also to append to the system prompt. Additionally an argument can be made that tool_search_call is unnecessary for OpenAI as we can directly use additional_tools.

Developer Messages

The actual shortcoming compared to what you can express with Responses Lite is just the ability to emit intermittent developer messages. We have a prototype branch that adds a new developer message to express the desire to append to the system prompt mid conversation. This functionality does not map cleanly across models and as such will most likely diverge significantly.

This is the current branches’ divergence:

• Adds a text-only DeveloperMessage to the shared Message union.
• Allows agent and coding-agent message pipelines to retain it.
• Persists and restores it in sessions.
• Maps natively to developer for OpenAI Responses and supported Chat Completions models.
• Uses native mid-conversation system messages for selected newer Anthropic models when placement is valid.
• Degrades it to a clearly marked synthetic user message for providers without native positioned instructions.

Responses Lite Contract

The Codex implementation currently applies the following behavior to Lite models:

• Sends X-OpenAI-Internal-Codex-Responses-Lite: true.
• Omits top-level instructions and tools.
• Prepends an additional_tools developer input item containing tool definitions.
• Adds base instructions as an initial developer message input item.
• Allows subsequent developer messages to remain positioned in ordinary input history.
• Sets reasoning.context to all_turns.
• Disables parallel tool calls.
• Applies the Lite contract to compaction requests as well.
• Treats the Lite marker as connection-scoped for WebSockets.
• Performs additional image normalization and avoids unsupported hosted-tool forms.

Full Lite transport on older models:

Proposed Plan

Instead of supporting Responses Lite, instead do the following:

1. Move dynamic tool loading to additional_tools
2. Introduce a text-only provider-neutral DeveloperMessage as prototyped