Codex Memory Uses Models You Did Not Choose? Pin the Models

If Codex uses a custom non-OpenAI model provider but the provider log shows gpt-5.6-luna or gpt-5.6-terra requests you did not select, pin both memory models in your user-level ~/.codex/config.toml:

[memories]
extract_model = "<model-id-your-provider-serves>"
consolidation_model = "<model-id-your-provider-serves>"

Use the exact model identifier accepted by your configured provider. Restart Codex, let a memory startup pass run, and confirm that the provider activity log contains only the model IDs you intended. The upstream bug remains open, so this is a configuration workaround, not a permanent product fix.

Check Whether This Is Your Bug

This specific failure has four conditions:

• Codex runs through a custom non-OpenAI model_provider.

• Local memories are enabled.

• memories.extract_model and memories.consolidation_model are unset.

• The provider activity log shows background requests for models you did not select.

The August 5 report reproduced the behavior on Codex CLI 0.145.0 with an OpenAI-compatible gateway. The reporter selected a non-OpenAI model, but the same provider received requests for gpt-5.6-luna and gpt-5.6-terra. Those requests did not fail because the gateway could serve the model names, so the only visible signal was the provider log and its billing record.

First, record the version and active provider without printing secrets:

codex --version
grep -E '^(model|model_provider)[[:space:]]*=' ~/.codex/config.toml

Expected result: the version is visible, and the second command prints only your configured model and provider names. It should not print API keys.

Next, inspect the memory settings:

sed -n '/^\[memories\]/,/^\[/p' ~/.codex/config.toml

If both overrides are absent, compare the model selected for your interactive session with the provider activity created after Codex starts. Look for request time, model ID, and provider profile. Do not export full request bodies because memory generation can include content from prior thread rollouts.

This is not the same as a local RAM leak. Here, "memory" means Codex's background memory-generation feature, not process memory. If the symptom is high local RAM, use a process diagnostic instead.

Back Up the User Configuration

Codex documents ~/.codex/config.toml as the user-level configuration file. Back it up before editing:

cp ~/.codex/config.toml ~/.codex/config.toml.before-memory-routing

Expected result: the backup exists and differs from the active file only after you make the change.

If your file already contains a [memories] table, add the two keys to that table. Do not create a second [memories] table because duplicate TOML tables are invalid.

Pin Both Memory Stages

Memory generation has two stages with separate overrides:

1. extract_model selects the model for per-thread memory extraction.

2. consolidation_model selects the model for global memory consolidation.

Pin both to explicit model IDs your provider supports:

[memories]
extract_model = "your-provider/model-name"
consolidation_model = "your-provider/model-name"

The two values may differ if you deliberately want a smaller extraction model and a different consolidation model. Start with one known-good model for both stages when the goal is to stop unintended routing. That produces the clearest verification.

Do not copy the placeholder literally. A model ID valid for one gateway can be invalid for another. Use the same spelling that succeeds in a normal Codex request through your provider.

After saving the file:

1. Finish or save any active work.

2. Fully exit Codex.

3. Start Codex with the same custom provider and model.

4. Complete a small non-sensitive task, exit, and start Codex again so the memory startup path can run.

5. Recheck the provider activity log.

Expected result: background extraction and consolidation requests use the explicit IDs from [memories]. No new request should use an unselected model ID.

Disable New Memory Generation Instead

If you cannot verify a safe model for both stages, disable new memory generation while the upstream issue is open:

[memories]
generate_memories = false

OpenAI's configuration reference says this prevents newly created threads from being stored as memory-generation inputs. It does not mean existing memory is deleted. The separate use_memories setting controls whether Codex injects existing memories into future sessions.

For the smallest change, set generate_memories = false, restart Codex, and monitor the provider log. If you also want Codex to stop using existing memories, make that a separate decision:

[memories]
generate_memories = false
use_memories = false

Keeping these controls separate makes the outcome reversible and avoids deleting local data.

Why the Pin Works

The issue report traced both call sites in the open-source Codex code. When the overrides are unset, the memory writer asks the provider for preferred extraction and consolidation models. For most providers, the reported defaults were OpenAI model IDs:

memory extraction -> gpt-5.6-luna
memory consolidation -> gpt-5.6-terra

The custom provider still receives those names. If it rejects them, the user sees an error. If it serves them, the background work succeeds silently through models that were not selected for the interactive session.

Explicit extract_model and consolidation_model values already take precedence in the reported code path. Pinning both therefore removes the provider-blind fallback from this path without changing the provider itself.

The same class of provider-routing error appeared in July reports about Codex auto-review. In those cases, custom providers rejected the internal codex-auto-review identifier with 400 or 404 errors. The memory variant is harder to notice because a broad gateway may accept the unintended model names.

Common Failure Modes

You pinned only extract_model

Consolidation can still use its default. Set and verify both keys.

Codex reports an unknown model

The override must match a model ID your custom provider serves. Test the exact ID through the same provider profile, then update the TOML value.

The old model names still appear

Confirm you edited the user-level file used by that Codex process. Fully restart Codex, then separate new activity from older log entries by timestamp. Also check whether a profile file is selected and supplies another configuration layer.

You use a first-party OpenAI provider

The August 5 report concerns a custom non-OpenAI provider. Do not assume that every gpt-5.6-luna or gpt-5.6-terra request is unintended on an OpenAI-hosted path. Compare the request against your configuration and the feature's documented behavior.

Usage is high but provider routing is correct

A separate August 3 report found large background memory inputs, retries after context-window failures, and a default threshold that lets generation run while at least 25% of rate limits remains. Pinning models controls routing, not transcript size or retry behavior. See how to diagnose Codex usage spikes before attributing every usage change to this bug.

Keep Model and Action Routes Explicit

The lesson is broader than one memory setting: background work needs an explicit destination and a verifiable cost boundary. Aident Loadout applies that pattern to external Actions. An agent can inspect an Action contract and preflight its Aident credit estimate before execution instead of hiding provider details inside an unreviewed script.

From a terminal with the public aident CLI installed:

aident account auth status
aident vault vault --action status

aident capabilities search \
  --targetEnv staging \
  --types '["action"]' \
  --queries '["one read-only Action for my current task"]'

Use the exact Action name returned by search with aident capabilities get, then call aident capabilities preflight before execution. Expected result: you can review authentication state, the Action schema, and the cost boundary before the external call.

Follow https://aident.ai/SETUP.md to set up Aident Loadout, then preflight one explicit read-only Action.

For more on keeping provider credentials outside agent prompts, read Give AI Agents API Access Without Exposing Keys.

Sources

• OpenAI: Codex configuration reference

• OpenAI: Codex memories

• OpenAI Codex issue 37009: memory writer sends unselected model requests

• OpenAI Codex issue 36806: memory generation can consume quota and exceed context

• OpenAI Codex issue 31255: auto-review model unsupported by a custom provider

• OpenAI Codex issue 31732: provider-blind auto-review model routing

Review this article when issue 37009 closes, the Codex memory defaults change, or the configuration reference changes the meaning of either model override.