Yesterday, I was coding with GPT-5.6 Sol as the parent model and several Luna sub-agents. I had explicitly specified both the model and reasoning effort for each sub-agent in agent.toml.

However, my quota was drained almost instantly. At the time, I suspected that something might be wrong with the model routing. After searching online, I found that this was indeed the case: the sub-agents were not using the models specified in agent.toml, but were inheriting the parent model instead.

Please conduct a strict, read-only investigation of the Codex sub-agent model routing on this machine.

My check prompt for codex:

Background

• The parent agent is intended to use GPT-5.6 Sol with Medium reasoning effort.

• Tasks such as exploration, editing, and review are delegated to sub-agents such as explorer, editor, and reviewer.

• Some of these sub-agents are expected to always use GPT-5.6 Luna with High reasoning effort.

• The goal is to verify whether they actually use Luna at runtime, rather than inheriting Sol from the parent agent, being automatically routed to another model, or silently falling back because their configuration is invalid or ignored.

Mandatory Requirements

1. The entire investigation must be strictly read-only. Do not modify, create, move, overwrite, truncate, or delete any file.

2. Do not modify the Codex configuration or start any task that could change repository contents.

3. All repository and filesystem exploration must be delegated to an exploration sub-agent. Final conclusions must be independently checked by a review sub-agent.

4. Do not treat a sub-agent’s natural-language claim about its own model identity as evidence.

5. Only trust configuration parsing results, runtime logs, session metadata, event records, or actual request parameters.

6. Do not expose API keys, cookies, authorization headers, access tokens, or any other secrets. Redact them if encountered.

7. Do not install dependencies, upgrade or downgrade Codex, or run cleanup commands.

8. If some runtime information is inaccessible, state this explicitly. Do not guess.

Investigation Scope

A. Confirm the Current Environment

• Identify the Codex installation source, version number, build version, and executable path.

• Identify the current user directory, project directory, and the configuration root actually used by Codex.

• Be aware that Windows, WSL, and container environments may each have separate ~/.codex directories.

• Determine whether the filesystem visible to Cursor is the same environment in which Codex is actually running.

B. Inspect Sub-Agent Configuration

Inspect the following locations, as well as any other configuration locations that Codex actually loads:

• ~/.codex/config.toml

• ~/.codex/agents/

• .codex/ in the project root

• .codex/agents/ in the project root

• AGENTS.md, including its scope and override behavior

List the configuration of each relevant sub-agent, including explorer, editor, reviewer, and luna_worker, and verify:

• Agent name

• Configuration file path

• model

• model_reasoning_effort

• sandbox_mode

• developer_instructions

• Whether another configuration with the same agent name overrides it

• Whether there are TOML syntax errors, unknown fields, or configurations that are not being loaded

• The inheritance or default behavior when the model field is missing

• Whether an invalid model name produces an error, triggers automatic routing, or silently falls back

C. Inspect the Actual Capabilities of spawn_agent

• Locate the actual schema or implementation of the spawn_agent tool in the installed Codex version.

• Confirm whether its exposed parameters are limited to task_name, message, and fork_turns.

• Check whether internal support exists for unexposed fields such as model or reasoning_effort.

• Clearly distinguish between:

  1. Officially supported and stable configuration mechanisms

  2. Internal or hidden fields

  3. Fields hallucinated or invented by the model based on prompt wording

• Do not rely solely on online posts or prompt-based assumptions.

D. Inspect Real Runtime Records

Search Codex logs, session files, history records, or event databases for the most recent real task in which:

For the parent session and every child session, extract and compare:

• Session ID, partially redacted if necessary

• Parent-child relationship

• Agent name

• Actual model ID

• Reasoning effort

• Creation time

• fork_turns value or context inheritance method

• The final resolved source of the agent configuration

• Any records related to fallback, unsupported model, invalid config, route, inherit, or similar behavior

Do not use a sub-agent answering “What model are you?” as evidence.

E. Minimal Verification, Only If Necessary

Only propose a minimal verification procedure if the existing logs and metadata are insufficient to reach a conclusion. Do not execute it without authorization.

The proposed verification must:

• Not edit repository files

• Not create or delete files

• Use a task limited to reading a non-sensitive text file or returning a fixed string

• Separately test:

  1. A sub-agent explicitly configured to use Luna

  2. A sub-agent with no model configured

• Confirm the actual model through session metadata or logs

• List the exact commands, expected log output, and possible side effects before execution, then wait for user authorization

Required Final Output

1. Conclusion

Select one of the following and explain the supporting evidence:

• Confirmed that the sub-agent uses Luna

• Confirmed that the sub-agent inherits Sol

• Confirmed that automatic routing or fallback occurred

• Insufficient evidence to determine the actual routing

2. Actual Routing Table

3. Configuration Loading Chain

List the override order and effective precedence of:

4. Key Evidence

Provide file paths, log paths, relevant fields, and short redacted excerpts.

Every conclusion must be tied to specific evidence.

5. Risk Assessment

Evaluate the following separately:

6. Recommended Fixes

Only recommend fixes. Do not make any changes.

Prioritize official, stable, and verifiable configuration mechanisms.

Do not recommend relying on prompt injection or hidden parameters unless support for those fields has been directly verified in the currently installed version. Any such approach must be clearly labeled as undocumented and potentially unstable.

Before Starting

First output:

1. The paths you plan to inspect

2. The read-only commands you plan to run

3. Which steps will be handled by the exploration sub-agent and which will be handled by the review sub-agent

Then immediately begin the read-only investigation.

Note: This report was translated from Chinese, so some wording may be imperfect or ambiguous. I will include the original Chinese version below for reference.

result

1. Conclusion

The currently available evidence is insufficient to confirm that the sub-agents actually used Luna.

The global agent configuration explicitly declares that explorer, reviewer, and worker should use gpt-5.6-luna. However, the currently accessible child-session metadata does not record the effective model or model_reasoning_effort, and no events related to fallback, invalid config, route, or inherit were found.

Therefore, the available evidence cannot confirm that the sub-agents used Luna, inherited Sol from the parent, or were routed through a fallback mechanism.

2. Actual Routing Table

3. Configuration Loading Chain

The following candidate loading chain can be supported by the available evidence. However, the runtime logs do not fully record the effective precedence order or the final resolved configuration, so the exact override behavior cannot be conclusively established:

1. Windows host configuration root:
   C:\Users\<USER>\.codex

2. Global config.toml:
   Declares the default parent model as gpt-5.6-terra with low reasoning effort.

3. Global agents\*.toml:
   Declares the model and sandbox settings for named agents.

4. Project-level .codex\ and .codex\agents\:
   No such directories were found in the current project.

5. Ancestor-directory instructions:
   C:\Users\<USER>\Documents\Codex\AGENTS.md

6. User-level instructions:
   C:\Users\<USER>\.codex\AGENTS.md

7. Current thread or UI-level thread_settings_applied:
   Confirmed to be capable of overriding the global parent default. One recorded thread used gpt-5.6-sol with medium reasoning effort.

8. Runtime parameters supplied to spawn_agent:
   The currently exposed schema contains only task_name, message, and fork_turns.

The Luna-related conventions in AGENTS.md are developer instructions. They are not runtime evidence of model routing.

4. Key Evidence

Codex Executable

C:\Program Files\WindowsApps\OpenAI.Codex_<PACKAGE_VERSION>_x64__<PACKAGE_ID>\app\resources\codex.exe

The installation was confirmed to be a Windows MSIX-packaged application.

The package version was recorded as:

26.707.3748.0

The CLI version recorded in session metadata was:

0.144.0-alpha.4

An attempt to invoke the executable directly with a version argument was denied by the operating system, so that attempt was not treated as version evidence.

Configuration Root

The controlled-environment configuration in:

C:\Users\<USER>\.codex\config.toml

points to:

CODEX_HOME=C:\Users\<USER>\.codex

Sub-Agent Declarations

# ~/.codex/agents/explorer.toml
model = "gpt-5.6-luna"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"

The other relevant declarations were:

• reviewer.toml: Luna, max, read-only

• worker.toml: Luna, high, workspace-write

Parent-Child Session Relationship

The parent session was stored under a path similar to:

C:\Users\<USER>\.codex\sessions\2026\07\11\rollout-...<PARENT_SESSION_ID>....jsonl

The two child-session metadata records contained redacted values similar to:

parent_thread_id: <PARENT_THREAD_ID>
forked_from_id: <PARENT_THREAD_ID>
agent_path: /root/exploration

A corresponding child session was also found for:

/root/review

This confirms that child sessions were created and linked to the parent context. It does not prove which model the child sessions actually used.

Known Sol Thread Event Format

Events from a known Sol parent thread demonstrate that the event format is capable of recording the resolved model:

turn_context.payload.model: gpt-5.6-sol
thread_settings_applied.thread_settings:
  model: gpt-5.6-sol
  reasoning_effort: medium

However, no corresponding fields were found in the two child sessions examined during this investigation.

Exposed spawn_agent Schema

The currently visible schema contains:

task_name
message
fork_turns

It does not expose:

model
reasoning_effort
agent_name

No readable local implementation was found that could demonstrate support for hidden model-routing fields.

Therefore, hidden parameters must be classified as unverified and unsuitable for recommendation. They cannot be treated as an officially supported or stable capability.

Environment Boundary

The active process and session paths both used Windows paths, and the user directory was:

C:\Users\<USER>

wsl.exe was present, but no installed WSL distributions were listed. No evidence of an active container environment was observed.

The filesystem visible during this investigation therefore appears consistent with the Windows host environment.

This does not rule out separate ~/.codex directories being used by WSL, containers, remote environments, or other machines in different sessions. No such runtime records were identified in this investigation.

Unverified Behaviors

No TOML parser was executed, and Codex was not launched for an active validation test. Therefore, the investigation could not confirm:

• Whether the TOML files were parsed successfully

• Whether unknown fields are ignored or rejected

• The effective override rules for duplicate agent names

• The inheritance behavior when model is omitted

• Whether an invalid model produces an error, triggers automatic routing, or silently falls back

5. Risk Assessment

6. Recommended Fixes

1. Codex should expose auditable child-session metadata containing:

   • The final resolved model

   • The final resolved reasoning_effort

   • The source of the effective configuration

   • The applied override chain

   • Any fallback or routing reason

2. Publicly documented named-agent configuration should be used as the sole model-configuration mechanism.

3. Text such as model=... should not be inserted into the spawn_agent message in an attempt to simulate an unsupported runtime parameter.

4. The precedence among the following should be covered by explicit compatibility tests:

5. Actual session events should be rechecked before and after Codex upgrades. The continued presence of the TOML files alone does not prove that they remain loaded or effective.

6. Hidden-parameter solutions are not recommended. Their existence or effectiveness has not been demonstrated in the currently installed version.

Proposed Minimal Verification

If authorization is granted, the next step would be to perform two minimal tool calls that create child sessions and associated event logs:

spawn_agent(
  task_name="explorer",
  message="Reply with exactly: LUNA-CHECK",
  fork_turns="none"
)

spawn_agent(
  task_name="unconfigured_probe",
  message="Reply with exactly: DEFAULT-CHECK",
  fork_turns="none"
)

The expected side effects would be limited to the creation of two new child sessions and their corresponding event-log entries. No repository files would be read, modified, created, or deleted.

Afterward, only the following fields should be inspected:

• thread_settings_applied

• Final resolved model

• Final resolved reasoning_effort

• Effective configuration source

• Any fallback, unsupported, invalid config, route, or inheritance-related events

If those fields are still absent from the child-session logs, the conclusion must remain:

Insufficient evidence to determine the actual sub-agent model routing.

Later, I had the investigation model, GPT-5.6 Terra Low, invoke the sub-agents and retrieve their runtime metadata. The results were as follows:

1. Conclusion

Confirmed: in this test, the named explorer sub-agent did not use Luna. It actually used gpt-5.6-terra with low reasoning effort.

This was not a case of inheriting Sol. The parent session in this test was also running gpt-5.6-terra with low reasoning effort, despite the original plan to use Sol.

The available records are most consistent with the child agent inheriting the current parent-thread settings, while the Luna configuration declared in explorer.toml was not applied.

The underlying cause is still not confirmed. Possible explanations include:

• The agent configuration was not loaded

• task_name does not select a named agent configuration

• An undocumented internal routing mechanism was used

Neither of the two newly created child sessions contained events describing a fallback, unsupported model, or resolved configuration source.

2. Actual Routing Table

3. Configuration Loading Chain

The following sequence can currently be supported by evidence:

1. C:\Users\<USER>\.codex\config.toml
   Global default: gpt-5.6-terra with low reasoning effort.

2. C:\Users\<USER>\.codex\agents\explorer.toml
   Declares gpt-5.6-luna with medium reasoning effort.

3. Current thread-level thread_settings_applied
   Actually applies gpt-5.6-terra with low reasoning effort.

4. spawn_agent
   Its publicly exposed parameters are limited to:

   • task_name

   • message

   • fork_turns

5. Child-session turn_context
   Records the effective runtime model as gpt-5.6-terra with low reasoning effort.

No project-level .codex\ or .codex\agents\ override was found.

The Luna-related role conventions in the ancestor AGENTS.md file are instructions, not runtime evidence of model selection.

4. Key Evidence

Minimal explorer Verification Session

C:\Users\<USER>\.codex\sessions\2026\07\11\
rollout-2026-07-11T19-12-04-<REDACTED_SESSION_ID>.jsonl

Relevant redacted fields:

session id: <CHILD_SESSION_ID>
parent: <PARENT_SESSION_ID>
agent_path: /root/explorer
turn_context.payload.model: gpt-5.6-terra
collaboration_mode settings:
  model: gpt-5.6-terra
  reasoning_effort: low

Unconfigured Probe Session

C:\Users\<USER>\.codex\sessions\2026\07\11\
rollout-2026-07-11T19-12-20-<REDACTED_SESSION_ID>.jsonl

Its effective model and reasoning effort were also:

model: gpt-5.6-terra
reasoning_effort: low

Declared explorer.toml Configuration

The explorer.toml declaration remained:

model = "gpt-5.6-luna"
model_reasoning_effort = "medium"
sandbox_mode = "read-only"

Therefore, the configuration file existed, but the following invocation did not produce runtime routing consistent with that configuration:

spawn_agent(task_name="explorer", ...)

No records were found containing:

fallback
unsupported model
invalid config
resolved agent configuration
final configuration source

5. Risk Assessment

• Quota and cost impact: High.
  The actual model may differ completely from the expected Luna configuration, causing usage and quota consumption to deviate substantially from expectations.

• Execution speed impact: High.
  Terra Low has different latency and execution characteristics from Luna High.

• Task quality impact: High.
  Role-based capability separation cannot be assumed to work merely because the relevant TOML files or AGENTS.md instructions exist.

• Configuration stability across upgrades: High risk.
  The current CLI reports an alpha version, and both logging behavior and agent-configuration resolution may change between releases.

• Hidden parameters: High risk.
  The current schema does not expose model or reasoning_effort, and no implementation-level evidence supports the existence of usable hidden fields.

6. Recommended Fixes

1. Do not treat task_name="explorer" as proof that explorer.toml has been selected or applied.

2. Confirm the officially supported mechanism for selecting a named Codex agent, including whether it requires a routing mechanism other than task_name.

3. After every Codex upgrade, repeat the same fixed-string validation and use the child session’s turn_context.payload.model as the acceptance criterion.

4. Codex should expose runtime audit fields recording:

   • The final resolved agent configuration source

   • The effective model

   • The effective reasoning effort

   • Any override chain

   • Any fallback or routing reason

5. Until such evidence is available, do not rely on prompt wording, AGENTS.md, or guessed hidden parameters to force the use of Luna.

Report on Codex Sub-Agent Model Assignment Writen By GPT 5.6 Luna Medium

Executive Summary

AGENTS.md is not itself a model-routing configuration file, nor can it directly modify the underlying API request.

Its role is to:

1. Inject contextual rules into the parent agent and its sub-agents

2. Tell the parent agent how it is expected to invoke sub-agents

3. Influence values such as task_name, fork_turns, prompt content, and post-run verification behavior

4. Provide intended routing instructions without guaranteeing that hidden parameters such as model or reasoning_effort are actually accepted by the tool

The actual model assignment must be verified through the child session’s runtime metadata, especially the following fields in turn_context:

model
collaboration_mode.settings.model
collaboration_mode.settings.reasoning_effort

1. Invocation Chain

The approximate flow is:

AGENTS.md
    ↓
Injected into the parent agent’s context
    ↓
Parent agent reads the rules and constructs a spawn_agent call
    ↓
spawn_agent creates a child session
    ↓
Codex runtime determines the child session’s model
    ↓
The child session is written to a session JSONL file
    ↓
The effective model and reasoning effort are read from turn_context

The key distinction is that AGENTS.md operates at the instruction layer, not the routing execution layer.

It can tell the agent that:

explorer should use Luna / medium
worker should use Terra / medium
reviewer should use Terra / medium

However, whether this routing actually occurs depends on whether the Codex runtime supports and applies the corresponding fields.

2. What AGENTS.md Can Influence

AGENTS.md can influence:

• Whether sub-agents must be created

• How responsibilities are divided among sub-agents

• Which task_name is used

• Whether fork_turns="none" is used

• Whether the parent agent attempts to pass hidden model parameters

• Whether session metadata is inspected after a task completes

• Whether the parent agent is prohibited from directly modifying the repository

• Whether a Goal must be created before work begins

For example, rules in the current global file may encourage the parent agent to construct an invocation resembling:

task_name = "worker"
fork_turns = "none"
model = "gpt-5.6-terra"
reasoning_effort = "medium"

However, this represents only the invocation that the model intends to generate.

It does not prove that the tool accepts or applies every field.

3. What AGENTS.md Cannot Guarantee

AGENTS.md cannot directly guarantee that:

• Codex accepts the model field

• The sub-agent uses the requested model

• reasoning_effort is applied

• The sandbox is configured according to the value written in the instructions

• Internal inheritance or automatic routing does not occur

• A silent fallback does not occur

The previously observed public spawn_agent schema exposed only:

task_name
message
fork_turns

It did not publicly expose:

model
reasoning_effort
sandbox_mode

Therefore, writing these fields into AGENTS.md does not mean that the underlying tool API supports them.

4. Why Both Terra and Luna Results Were Observed

Two different categories of runtime records were observed.

Earlier Minimal Verification

Some child sessions recorded the following in turn_context:

model = gpt-5.6-terra
reasoning_effort = low

This indicates that those child sessions used the parent thread’s settings or the applicable default thread settings.

Later Minimal Verification

A later child session was stored at a path resembling:

C:\Users\<USER>\.codex\sessions\2026\07\11\
rollout-2026-07-11T19-47-15-<REDACTED_SESSION_ID>.jsonl

Its turn_context recorded:

model = gpt-5.6-luna
reasoning_effort = medium
sandbox_policy.type = workspace-write

This proves two things:

1. The effective runtime model can be determined from session metadata

2. Child-agent routing may vary depending on the parent thread, current thread settings, or runtime environment

However, the metadata did not record fields such as:

config_source
fallback_reason
resolved_agent_config

Therefore, it cannot be proven that Luna was selected specifically because of AGENTS.md.

5. Practical Meaning of the Current Role Configuration

The current intended configuration is:

This table represents the intended routing policy, not a verified runtime fact.

After every invocation, the following fields should be inspected:

turn_context.payload.model
turn_context.payload.collaboration_mode.settings.model
turn_context.payload.collaboration_mode.settings.reasoning_effort

Only when these fields match the intended configuration can it be stated that the sub-agent actually used the requested model and reasoning effort for that invocation.

6. Why Runtime Metadata Is Required

A sub-agent may state in its response:

I am Luna.

This is merely natural-language output. It does not prove which model handled the underlying request.

The evidence should be ranked approximately as follows:

1. Final model recorded in the session’s turn_context

2. thread_settings_applied

3. Actual request parameters or routing events

4. Configuration-source metadata recorded in the session

5. Declarations in AGENTS.md

6. The sub-agent’s natural-language claim about its own identity

The current investigation relies primarily on the first category of evidence.

7. Final Model

The mechanism can be summarized as follows:

AGENTS.md tells the agent how it should construct the request. The Codex runtime decides which model is ultimately used. Session metadata provides evidence of which model was actually used.

Adding routing rules to AGENTS.md is still useful, but it should be treated as an invocation policy and verification protocol rather than as an authoritative low-level model configuration.

The most reliable current workflow is:

1. Declare the intended role-to-model mapping in AGENTS.md

2. Attempt to pass the intended routing parameters during the sub-agent invocation

3. Use fork_turns="none" to reduce interference from inherited parent context

4. Inspect the child session’s turn_context after completion

5. If the effective model does not match the intended model, report that the configuration was not applied instead of inferring or guessing the cause

OpenAI must pay attention with this problem because it will instantly reach user’s 5h limit.