Inside Codex Alpha 10: Incremental Tool Catalogs and Code Mode MCP

Codex 0.162.0-alpha.10 includes two changes worth examining if you maintain an agent runtime: incremental tool declarations in the feature-gated Responses Lite path, and stable MCP resource helpers in Code Mode. The client can record a catalog in history and send changed declarations later. This is a request-construction change, not a published benchmark or an automatic update to every OpenAI API account.

The useful question is what reaches the model when the available tools change. An agent may inspect repositories, run commands, query a database and use services through the Model Context Protocol (MCP). The runtime must describe each capability, track which declarations remain available, and enforce its real access permissions. Sending a smaller catalog does not settle all three jobs.

The source changes suggest a concrete review for systems engineers: compare an initial request, an unchanged request, a changed declaration and a removed declaration. Then examine what survives compaction and what a helper returns when no server exists. The article below explains the inspected implementation and proposes that review; it does not report a Rise production test.

Key takeaways

• Incremental tool declarations require Responses Lite and the IncrementalTools feature. The standard Responses API behavior remains unchanged.
• Catalog fingerprints detect declaration changes. Removal notices communicate availability, while actual dispatch and permissions need separate checks.
• Code Mode keeps three MCP resource helpers registered even with no server. Their presence does not create a connection or guarantee a successful resource read.

Codex 0.162.0-alpha.10 is a publicly downloadable prerelease built from the open-source Rust repository. OpenAI has not published measured percentage reductions in latency or token consumption for these commits. The explanation separates code behavior, illustrative examples and proposed checks so that a useful implementation detail does not become a wider performance promise.

What changes when a catalog becomes stateful

To understand what changes in Codex Alpha 10, we must first examine how tool delivery operates in standard language model protocols.

Stateless tool delivery is a communication pattern where the client runtime retransmits the full schema of every available tool on every request turn.

Incremental tool catalog diffing is a stateful synchronization protocol where the host runtime transmits an initial baseline of tool schemas and subsequently emits only added, modified, or removed tool deltas.

When a client application interacts with a modern language model API supporting function calling, the request payload typically contains two primary arrays. The first is the conversation history, which holds the sequence of system prompts, user messages, assistant responses, and tool output call receipts. The second array is the tool declaration list, often passed under a parameter named tools.

In a completely stateless protocol, the server assumes zero persistence of function schemas between HTTP requests. Even if turn twelve in a debugging session differs from turn eleven by only a single user confirmation message, the client must package every active tool schema into the tools parameter of turn twelve.

Consider a hypothetical agent configured with three enterprise MCP servers:

1. A database server exposing twenty-four SQL analysis and schema migration tools.
2. A cloud infrastructure server exposing eighteen container management and telemetry tools.
3. A local development environment server exposing fifteen file manipulation, compiler, and testing tools.

The three illustrative servers expose fifty-seven tools. If their combined declarations were twenty kilobytes, sending that same catalog on thirty turns would transfer six hundred kilobytes of catalog data. Those assumed sizes are arithmetic for this example, not measurements of Codex or a production workload.

The consequences of this stateless design extend beyond mere bandwidth waste:

• Payload Bloat: Every HTTP round trip carries redundant schema definitions that must be serialized by the client runtime and deserialized by the model gateway.
• Context Budget Pressure: While server-side prompt caching can mitigate the cost of processing static prefixes, a changed declaration changes part of the request content. The resulting cache behavior depends on the provider and its cache policy; this commit supplies no measured cache-hit improvement.
• Dynamic Tool Fragility: If an MCP server connects or disconnects mid-task, or if an agent dynamically loads a specialized plugin during turn seven, the entire catalog must be reconstructed and resent, making it difficult for the model to track what changed versus what remained constant.

The following comparative table summarizes the structural differences between traditional stateless tool delivery and Responses Lite stateful synchronization:

• **Turn 1 Payload:** Traditional Stateless Tool Calling: Full JSON Schema array sent; Responses Lite Incremental Catalog (Codex Alpha 10): Full JSON Schema array sent (AdditionalTools)
• **Turn 2+ Unchanged Payload:** Traditional Stateless Tool Calling: Full JSON Schema array resent identically; Responses Lite Incremental Catalog (Codex Alpha 10): No additional-tools declarations item; other prefix content can remain
• **Dynamic Tool Addition:** Traditional Stateless Tool Calling: Entire catalog regenerated and resent; Responses Lite Incremental Catalog (Codex Alpha 10): Only delta declarations transmitted in AdditionalTools
• **Tool Deprecation:** Traditional Stateless Tool Calling: Silent omission does not explain why a previously declared tool disappeared; Responses Lite Incremental Catalog (Codex Alpha 10): Explicit tools.removed_definition developer instruction
• **Namespace Guidance Update:** Traditional Stateless Tool Calling: Full namespace resent with all member tools; Responses Lite Incremental Catalog (Codex Alpha 10): Text-only developer instruction; member tools untouched
• **Cache Evidence:** Traditional Stateless Tool Calling: Cache behavior depends on the provider; Responses Lite Incremental Catalog (Codex Alpha 10): Commit demonstrates catalog diffs, not measured cache savings
• **Zero-Server Code Mode:** Traditional Stateless Tool Calling: MCP helpers disappear, causing schema churn; Responses Lite Incremental Catalog (Codex Alpha 10): MCP resource helpers permanently registered

View image detail

Send changes in the selected mode. Responses Lite needs IncrementalTools enabled. Start with a complete tool catalog. Later requests add changed definitions.

Actual size

Choose Actual size to read the graphic closely.

The alternative approach, implemented in Codex's Responses Lite protocol, is stateful synchronization. Instead of treating every API call as an isolated event, Responses Lite treats the conversation as an evolving session governed by an underlying world state. In this paradigm, the client runtime and the model gateway maintain a synchronized ledger of active tool definitions. When a session begins, the client transmits the baseline catalog once. From that point forward, the client sends only the deltas: tools that were freshly registered, tools whose schemas were modified, and explicit instructions identifying tools absent from the current catalog.

How the catalog tracks definitions and fingerprints

The engine driving incremental tool updates in Codex Alpha 10 lives within the Rust core repository under the top-level-tools state module, introduced in Commit 6326163. The implementation is centered around a dedicated world-state section struct called TopLevelToolsState.

In Codex's architecture, the conversation context is divided into distinct, modular sections called world-state sections. Each section tracks a specific slice of the agent runtime environment, such as active file buffers, terminal sessions, or available tools. Each section implements the WorldStateSection trait, which defines how a section captures snapshots and computes transitions between consecutive turns.

The core data structure of TopLevelToolsState is defined as follows:

The inspected state structure has two fields: serialized definitions and an ordered map of tool keys to fingerprints. It keeps the definition payload separate from the values used to detect changes.

Here, definitions stores the raw, serialized JSON values of the tools as emitted by the Responses Lite serializer. The hashes map stores a deterministic SHA-1 fingerprint for every active declaration, keyed by its unique identification string.

View image detail

Track payloads and fingerprints. Definitions retain the serialized declarations. A map tracks tool and namespace keys. Duplicate keys cause a collision error.

Actual size

Choose Actual size to read the graphic closely.

How Codex Parses Declarations

The catalog passed into TopLevelToolsState::new() contains two distinct categories of declarations:

1. Top-Level Built-in Tools: Direct primitives such as terminal execution commands or code analysis cells. These are identified either by an explicit "name" field or by their "type" property.
2. Namespaced Tools: Hierarchical tool bundles where related tools are grouped under a shared namespace header (for example, tools provided by an external MCP server or an internal subsystem). In the Responses Lite wire format, a namespace is represented as a JSON object containing a "name" property and an inner "tools" array holding the member tool declarations.

When TopLevelToolsState constructs its state snapshot, it iterates through every declaration. If a declaration is a namespace containing an inner "tools" array, Codex splits the declaration into two levels of tracking:

• It hashes each member tool individually, storing its hash in the BTreeMap under a compound key: {namespace}.{tool_name}.
• It removes the inner "tools" array from the namespace header and hashes the remaining header metadata (including the namespace description and operational instructions), storing that hash under the bare {namespace} key.

If a declaration is a standalone top-level tool without inner members, Codex simply computes its hash and stores it under its name.

Deterministic fingerprints and duplicate tool keys

The JSON hash constructor sorts object keys before computing a SHA-1 fingerprint. The inspected tests verify stable fingerprints for reordered JSON keys. This is change detection, not a claim that SHA-1 provides modern cryptographic collision resistance.

Specifically, the unit test suite in top_level_tools_tests.rs includes tests specifically verifying stable hashing across variations in JSON object key ordering. If an MCP server serializes a tool definition with properties ordered as a query declaration with its name first on turn one, and later emits the same declaration with its description first on turn two, WorldStateHash treats them as mathematically identical. This prevents spurious delta transmissions that would otherwise defeat the purpose of incremental tracking.

View image detail

Reordered keys keep the fingerprint. Object keys are sorted before hashing. The implementation uses a SHA-1 fingerprint. This detects change, not secure identity.

Actual size

Choose Actual size to read the graphic closely.

Beyond deduplication, TopLevelToolsState enforces strict collision detection. When inserting tool keys into the BTreeMap, the constructor checks whether a key is already present:

The insertion helper computes a fingerprint and inserts it under a tool or namespace key. If that key is already present, it returns a tool-collision error. This detects duplicate keys, rather than proving cryptographic collision resistance.

If an agent attempts to register two tools with identical names, or if two MCP servers export conflicting member names under the same namespace, catalog construction returns an explicit ToolCollision error rather than accepting duplicate keys.

The catalog lifecycle: transmit, compare and omit

When an agent session runs with IncrementalTools active, every request transition follows an exact diffing algorithm inside render_diff().

The function takes the previous turn's snapshot (an ordered fingerprint map) and compares it against the current turn's active catalog. This lifecycle unfolds across three distinct operational phases:

Phase 1: Cold Start and Initial Catalog Transmission

On the very first turn of an agent interaction, no previous snapshot exists (the absent previous-state case). Because the previous hash map is empty, every single tool declaration in TopLevelToolsState evaluates as changed.

Codex packages all active tool definitions into a single protocol response item: the additional-tools item. This item is placed into the request's prefix vector with the "developer" role:

The initial developer-role item carries the available tool declarations. Its identifier is derived from the prefix namespace and payload in the inspected code.

The model receives the complete catalog, establishes its baseline understanding of available actions, and proceeds to execute its first turn. The runtime then persists the resulting hash map as the new baseline snapshot.

View image detail

Begin with the initial catalog. An absent previous state starts the comparison. Current definitions count as changed. The client records fingerprints for later turns.

Actual size

Choose Actual size to read the graphic closely.

Phase 2: Omit unchanged catalog declarations

An agent can take several turns without changing its available tools. The agent might spend fifteen consecutive turns editing files, running test commands, and reading compiler outputs using the same stable tool suite.

In previous versions of Codex, even when using Responses Lite, the runtime repeatedly generated and attached an AdditionalTools prefix item on every single turn. In Codex Alpha 10, the core client module was updated to inspect the generated tool slice:

The client starts an empty prefix and adds the declarations item only when the selected tool list is nonempty. With no changed definitions, it omits this additional-tools item. Other request content can still be present.

When render_diff() runs against an identical catalog, tools evaluates to an empty vector. Because prompt.tools.is_empty() is true, the runtime skips pushing the AdditionalTools object entirely. The request prefix remains completely clean of redundant catalog declarations. The model relies entirely on the tool definitions already recorded in its conversation history.

View image detail

Omit the unchanged declarations item. Compare with the previous catalog state. No changed definitions means no added-tools item. Other request content can remain.

Actual size

Choose Actual size to read the graphic closely.

Phase 3: Dynamic Tool Additions and Modifications

Suppose that midway through a workflow, the user activates a new database analysis capability, or a long-running background process compiles an OpenAPI specification and registers three new endpoints.

When the next turn executes, TopLevelToolsState compares the new active catalog against the stored hashes. It identifies the exact members whose hashes differ from the previous turn:

The comparison asks whether the previous fingerprint for a key differs from the current fingerprint. A missing previous key also counts as changed.

For top-level tools, if changed(name) is true, the tool is appended to the outgoing delta. For namespaced tools, Codex inspects the inner members:

The namespace branch filters its members to changed keys. If any remain, it clones the namespace envelope with only those members for the outgoing declarations item.

Notice the elegance of this design. If a database namespace contains forty unchanged table inspection tools and one newly added query optimization tool, Codex does not resend the forty existing tools. It clones the namespace envelope, populates "tools" with only the single new member, and transmits that focused delta. The request history receives the new declaration. This describes how the client supplies definitions, not a measured guarantee of the model correctly using the new tool.

View image detail

Send only the changed members. Find new or changed namespace members. Send those members in their namespace envelope. Retain earlier declarations in request history.

Actual size

Choose Actual size to read the graphic closely.

How Codex announces removed tools

Adding tools dynamically is only half of the challenge in long-running agent systems. The more hazardous problem is tool removal.

In dynamic development environments, tools are frequently retired or replaced. An MCP server might crash or get disconnected. A temporary sandbox environment might be torn down. A user might revoke access to an external production deployment tool after an incident.

In naive agent implementations, when a tool is removed from the catalog, the client simply stops sending its schema in the next request. This creates an availability ambiguity that the runtime must handle. A model may still refer to an earlier declaration or successful call in its conversation history. When the agent encounters a task requiring that capability, it emits a function call for the missing tool. A runtime must still decide how to reject an unavailable call and explain the error. Silent omission alone does not tell a model why a previously declared capability disappeared.

Codex Alpha 10 addresses this through proactive, explicit deprecation notices.

When the catalog diff method detects that a tool key present in the previous snapshot no longer exists in the current catalog, it collects the missing names:

The removal branch compares previous keys with the current map. It gathers missing names and emits an explicit removed-tools fragment when that list is nonempty.

Instead of silently dropping the definitions, Codex constructs a RemovedTools struct that implements ContextualUserFragment. This fragment is injected directly into the conversation stream under the "developer" role with a dedicated content kind:

The removed-tools fragment uses the developer role and a specific content kind. Its body lists tools that are no longer available and instructs the model not to call them.

If a developer disables a hypothetical production deployment tool, the removal branch can name that tool in a developer-role instruction.

In the hypothetical deployment example, the notice would name the removed production deployment tool. It is an instruction about availability, not proof that a model or downstream integration obeyed it.

The fragment tells the model that the named tool is no longer available. A developer-role notice is an explicit instruction, not an enforcement mechanism or a guarantee that the model obeys it. The runtime still needs to reject unavailable calls and handle their errors; those checks should be evaluated separately.

View image detail

A removal notice is an instruction. Compare prior keys with the current catalog. List removed tools in a developer-role notice. Dispatch must still check availability.

Actual size

Choose Actual size to read the graphic closely.

Namespace Evolution: Updating Guidance Without Repeating Member Schemas

Another sophisticated optimization in Commit 6326163 addresses the evolution of namespace metadata.

In the Model Context Protocol and modern agent frameworks, namespaces frequently carry top-level documentation or system prompts. For instance, a Postgres MCP namespace might include guidance instructing the model to always prefix queries with EXPLAIN ANALYZE or to restrict table updates to specific transactions.

During a complex interaction, a user or system policy might update those namespace instructions. Perhaps a migration is starting, so the instructions are updated to require strict read-only queries.

In traditional architectures, because the namespace description is bundled together with the tools array in the API declaration, updating the description requires resending the entire namespace object along with every single member tool schema.

Codex Alpha 10 decouples namespace metadata from member function definitions.

When render_diff() checks a namespace declaration, it evaluates two conditions:

1. Did any member tools change?
2. Did the namespace header metadata itself change?

If the member tools are completely unchanged, but the namespace header hash changed, Codex avoids sending an empty or redundant tool array. Instead, it extracts the updated description and converts it into a standalone developer instruction fragment:

If no members changed but the namespace header did, the branch emits the new description as developer guidance. An empty description produces a notice that the namespace no longer has additional instructions.

If an operator updates the operational policy of a database namespace containing fifty tools, Codex emits a clean, lightweight text update:

For the hypothetical database policy change, the developer guidance would request read-only queries and prohibit destructive commands. The receiving runtime must still enforce its own actual permissions.

The client sends updated namespace guidance while retaining existing tool definitions in history. A text notice still has a payload, and its presence does not establish that the model follows the changed guidance. The useful distinction is avoiding redundant member declarations for a header-only change.

View image detail

Change guidance without resending members. Compare the header and member fingerprints. A header-only change emits new guidance. Runtime permissions need their own checks.

Actual size

Choose Actual size to read the graphic closely.

Remote Compaction Resilience

One of the greatest hazards of stateful catalog diffing is conversation compaction.

As an agent works across hours or days, the conversation history eventually approaches the context window limit of the model. To prevent overflow, modern runtimes perform context compaction: summarizing older turns, pruning intermediate scratchpads, and discarding transient tool outputs.

If a runtime uses naive catalog diffing and then aggressively compacts earlier turns, it risks discarding the original turn that introduced the tool schemas. If the model loses turn one from its context window, and subsequent turns only contain delta instructions, the model is suddenly left operating in a vacuum without knowing the parameter schemas of its active tools.

Codex Alpha 10 accounts for this in its core client logic. The commit notes for 6326163 explicitly specify:

"Use history-supplied definitions for normal requests and remote compaction, and omit empty additional_tools prefixes."

When Codex prepares a turn for remote compaction, it consults TopLevelToolsState and the preserved conversation history. The inspected change uses history-supplied definitions when preparing normal requests and remote compaction. It does not establish a universal reinjection mechanism after arbitrary truncation or guarantee reliable execution for sessions of any length. For a custom runtime, checking what definitions survive the selected compaction path remains a useful proposed test.

Stabilizing MCP Resource Helpers in Code Mode: The Zero-Server Fix

While Commit 6326163 tackles catalog diffing in Responses Lite, the second major runtime update in Alpha 10, Commit 55b6f2, resolves an equally insidious issue in Code Mode: tool surface schema churn.

Direct Calling vs. Code Mode

Code Mode MCP helpers are synthetic programming interfaces generated by the agent runtime to expose Model Context Protocol resources directly inside the sandboxed execution environment.

In standard Direct Tool Calling, an LLM emits structured JSON tool calls, which the client runtime parses and executes according to its dispatch and concurrency rules.

In Code Mode, the agent's interaction model is different. Rather than emitting isolated JSON blocks, the model writes short executable code snippets (JavaScript in the Codex scenario inspected here) inside an execution cell. The host runtime executes the code block within a controlled environment where client tools are exposed as native libraries or helper functions.

Among these built-in helpers are the core Model Context Protocol resource primitives:

• list_mcp_resources: Inspects available data resources across attached MCP servers.
• list_mcp_resource_templates: Retrieves URI templates for parameterized data queries.
• read_mcp_resource: Fetches the exact content of an MCP resource via its URI.

The Prior Flaw: Dynamic Helper Disappearance

Prior to Codex Alpha 10, the registration of these three helper functions was conditionally bound to whether any MCP servers were actively configured. Inside the core tool-plan module, the registration logic read:

Before the patch, the helper-registration condition checked whether MCP servers were configured.

This conditional check changed the helper definitions visible in Code Mode when the server configuration changed. The commit addresses that specific inconsistency; it does not report measured instability rates.

Imagine an agent session starting in a clean development environment with zero MCP servers attached. When the model inspected its available tool environment, the three MCP resource helpers were absent.

Three turns into the session, the user configured an MCP server to connect a remote documentation hub. Suddenly, context.mcp.has_servers() became true. On turn four, the runtime injected list_mcp_resources, list_mcp_resource_templates, and read_mcp_resource into the model's tool surface.

Later in the session, the user disconnected that server. On turn seven, context.mcp.has_servers() returned false, and the three tools vanished from the schema.

This changing helper surface is the schema churn described by the commit. The source shows definitions changing with server configuration. It does not measure cache invalidation, model hesitation, syntax errors or server-handoff race conditions. Those are separate hypotheses that would need their own observations before being presented as outcomes.

The Solution: Permanent Registration in Code Mode

Commit 55b6f2 eliminates schema churn by fundamentally changing the registration condition:

The patch keeps that condition and also registers the helpers when the effective tool mode is CodeModeOnly. It does not make a missing server available.

In CodeModeOnly, the MCP resource helpers are now permanently registered as intrinsic primitives of the code execution surface, regardless of whether zero, one, or ten servers are connected.

Error Handling Reality

A common misconception when stabilizing tool schemas is assuming that permanent registration magically provides data when servers are offline. It does not, and it should not.

The added helper server-change regression scenario specifies these expected results. We inspected this source; we did not run the scenario:

• When zero servers are attached, list_mcp_resources executes successfully and returns an empty list [].
• When zero servers are attached, list_mcp_resource_templates executes successfully and returns an empty list [].
• If the model attempts to call read_mcp_resource targeting an unknown or disconnected server, the tool executes properly and returns a clear, structured runtime error explaining that the server is not found.

The added regression scenario asserts identical helper definitions across its before, registered and removed phases. It also checks empty lists and an unknown-server error. That is source-level test coverage, not a Rise test run or a guarantee about every disconnected service, completion or provider cache.

View image detail

Stable helpers do not create a server. CodeModeOnly registers the resource helpers. The source scenario checks empty lists. An unknown-server read still returns an error.

Actual size

Choose Actual size to read the graphic closely.

Architectural Lessons for AI Systems Engineers

The implementation details of Codex Alpha 10 provide several practical lessons for developers building autonomous agent loops, custom MCP clients, and multi-agent systems, particularly for teams maintaining unified team workflows in Codex:

1. Separate Tool Declaration from Tool Transmission

Many agent frameworks tightly couple tool definitions with request generation. Every time a message is constructed, a helper function scans the plugin registry, converts Python classes or TypeScript interfaces into JSON schemas, and attaches them to the outgoing HTTP call.

Codex demonstrates that tool management must be an independent world-state domain. By tracking declarations in a stateful ledger with deterministic hashing, runtimes can decouple internal capability management from external network transmission.

2. Make Hash Invalidation Deterministic

JSON serializers can emit the same object with different property orderings. If your agent runtime hashes raw serialized strings, minor whitespace variations or key permutations can produce a different raw-string fingerprint. Following Codex's approach by hashing normalized data structures (WorldStateHash::from_json) avoids treating a reordered object as a new declaration; it does not prove that two differently written descriptions mean the same thing.

3. Retire Tools with Explicit Instructions, Not Silence

When an external integration drops or a user revokes permissions, do not simply delete the function from the API request and hope the model notices. A model can still refer to an earlier tool declaration. An explicit removal notice communicates the changed surface, while server-side dispatch checks must continue to enforce availability and handle errors. The notice and the enforcement boundary have different jobs.

4. Prefer Static Primitives Over Dynamic Churn

If an agent will ever need to read MCP resources, file buffers, or system telemetry, register those helpers as permanent primitives of the tool surface. A stable helper surface avoids this specific registration change. Provider cache effects and model reliability require separate evidence. Let the tool return an empty array or an explicit "server not connected" error rather than making the tool itself disappear.

View image detail

Keep the evidence boundary clear. Catalog state supplies definitions through history. Provider cache effects need separate evidence. A notice does not prove model compliance.

Actual size

Choose Actual size to read the graphic closely.

Practical Boundaries: What Codex Alpha 10 Does Not Do

As with any consequential technical development in AI infrastructure, early reports and social commentary often distort specific code commits into sweeping product claims. To maintain rigorous engineering standards, we must clearly delineate what Codex Alpha 10 does not do:

1. Not a General Public API Release: This update is a prerelease alpha build (rust-v0.162.0-alpha.10) for the Codex Rust client. It does not mean that every developer using the standard OpenAI REST API or third-party SDKs immediately has access to incremental tool diffs.
2. Feature-Gated to Responses Lite: The incremental tool diffing logic is explicitly gated behind the IncrementalTools feature flag and the Responses Lite model client mode. Conventional requests routed through the standard Responses API continue to send the complete tool catalog on every turn, as explicitly preserved in the unit tests.
3. No Published Token or Latency Benchmarks: OpenAI has published no official benchmarks, throughput curves, or latency statistics for Commit 6326163. While delta diffing can omit unchanged tool declarations from later requests, asserting specific percentage improvements in speed or cost without verified empirical data is unfounded.
4. No Third-Party Provider Guarantees: Server-side prefix caching and prompt caching depend entirely on the host provider's infrastructure policies. While omitting redundant prefixes keeps client request bodies lean, it does not guarantee automatic cache hits across every third-party inference provider.
5. No Protocol-Level Changes for MCP Servers: Commit 55b6f2 changes how the Codex client registers built-in helpers in Code Mode. It does not alter the underlying Model Context Protocol specification, nor does it require MCP server authors to modify their servers.

Toward Resilient, Stateful Agent Infrastructure

The journey of autonomous AI agents from simple single-turn prompt wrappers to resilient, production-grade operating systems is built on disciplined plumbing.

The practical next step is a small request-history comparison in a controlled environment. Record an initial turn, an unchanged turn, a changed declaration and a removed declaration. Inspect the actual serialized requests before attributing any observed improvement to this change.

OpenAI Codex 0.162.0-alpha.10 shows where modern agent engineering is headed. Its two source changes provide a specific pattern to examine: record declaration state separately from the selected outgoing payload, and keep the Code Mode resource helpers available when server configuration changes.

For a team maintaining an agent runtime, success should mean the intended declarations reach the right request, unavailable tools remain unavailable, and the useful task still completes. A smaller declaration payload alone does not settle those questions. Test that boundary before using the alpha mechanism to justify a wider rollout.

Related reading

For a practical check on what a tool should be allowed to do, see the Rise guide to deciding what to automate. Stable declarations describe capabilities; they do not by themselves justify granting a new action.