Codex Changed Its Default Model Twice in 15 Days — Can Your Evals Keep Up?

From September 29 to October 14, Codex's default model changed three times, while your repository diff stayed completely blank. If you're used to running agents on the default model, your eval results may already be incomparable.

Three changes, none of them written to your code

According to the release notes and docs in the OpenAI Codex repository, three things happened within 15 days:

• September 29: Codex CLI 0.159.1 made GPT-6.1 Sol the highest-priority entry in the built-in catalog (PR #49318), so it's used directly when no model is specified.
• October 8: 0.162.0 made new TUI threads follow the app server's model default (PR #50013), and also removed the "(default)" marker from the model selector (PR #51235).
• October 14: GPT-5.5 was retired from Codex, affecting only ChatGPT login users (API key sessions are unaffected), with a recommendation to migrate to GPT-6.1 Sol or GPT-6 Luna.

The sneakiest one is the October 8 change: newly opened TUI threads silently inherit the server-side default unless explicitly overridden at launch. You changed nothing, yet the model may have changed.

Who picks the "default"? A catalog file

As PR #49318 shows, the default model isn't chosen by anyone on your team — it's the result of the CLI's built-in catalog file being sorted by priority. Codex is not unique here: Claude Code's opus, sonnet, and haiku aliases also point to recommended versions over time, and pinning a version requires the full name like claude-opus-5-5.

Moving targets are fine for chat — you always want the latest model. But for anything that needs to be measured, compared, or promised to teammates, they're a source of noise.

If an eval measures a model, it must record the model name

Agent evals aren't necessarily formal suites; more often they're a single team message: "Codex is worse than Claude Code at migrations" or "it got better after we changed AGENTS.md." Every such statement is a claim about a specific model. If you used the default model, you don't even know who you tested.

And the model isn't the only hidden variable. Reasoning effort also changes results, and PR #50013 made it follow the server-side default too. Account type affects behavior as well: the GPT-5.5 retirement only hit ChatGPT logins, while API key sessions were untouched — the same gpt-5.5 configuration means different things under the two login methods.

The minimum record for any agent result should include four fields: model, reasoning effort, account type, and the commit that ran. Without them, a before-and-after comparison is just two unexplained numbers.

Reasoning effort is a configuration option in agent products that controls how much internal reasoning the model does before answering, typically with levels like low, medium, and high. Higher levels generate longer chains of thought and often perform better on complex migration, debugging, and refactoring tasks, but latency and token costs rise significantly. Conversely, the output quality gap for the same model between low and high is sometimes larger than switching to a different model. That makes reasoning effort an experimental variable you can't ignore: if two evals use the same model name but different effort levels, the conclusions are still incomparable. This is exactly the added risk from PR #50013 making reasoning effort follow the server-side default as well.

Pin models per task, and write it to the log

For everyday use, Codex profiles are the cleanest way to pin. Create a file under ~/.codex/:

A Codex profile is the CLI's configuration preset mechanism: place a file ending in `.config.toml` in the `~/.codex/` directory, reference it at startup with `--profile <name>`, and its key-value pairs override the global config. It's well suited to binding "model + reasoning effort + sandbox policy" into a reusable set of run parameters, avoiding manual specification every time. Note that a profile only pins the client-side resolution result — it can't stop a vendor from eventually retiring a model; it guarantees that "the current configuration can be reproduced stably," not that "the model will always be available."

`codex exec` is Codex's non-interactive run mode, suited to scripting and CI scenarios. Its key difference from the interactive TUI is that it runs in a read-only sandbox by default, so the agent can't write files; to let it modify code and trigger tests, you must explicitly pass `--sandbox workspace-write`. In addition, `-c key=value` can override any configuration key, and values that aren't valid TOML are treated as strings, so `-c model_reasoning_effort=medium` is valid. The exit code is returned as-is to the script, making it easy to record the success or failure of agent steps separately from subsequent test results.
# ~/.codex/pinned.config.toml
model = "gpt-6.1-sol"
model_reasoning_effort = "medium"

Launch with codex --profile pinned. PR #50013 ensures that an explicit profile launch preserves the resolved configuration, even for new TUI threads, so it won't be overridden by the server-side default.

For experiments that need comparison, put both pinning and logging in the same script. codex exec supports -m to specify the model and -c to set any configuration key (values that aren't valid TOML are treated as strings):

#!/usr/bin/env bash
set -u
task="$1"
model="gpt-6.1-sol"
effort="medium"
account="chatgpt"   # or "apikey"

codex exec -m "$model" \
  --sandbox workspace-write \
  -c model_reasoning_effort="$effort" \
  "$task" > last-run.log
agent=$?
npm test > test.log 2>&1
tests=$?

printf '%s\t%s\t%s\t%s\t%s\t%s\t%s\n' \
  "$(date -u +%FT%TZ)" "$(git rev-parse --short HEAD)" \
  "$model" "$effort" "$account" "$agent" "$tests" >> runs.tsv

codex exec runs in a read-only sandbox by default, so you need --sandbox workspace-write to let the agent modify code and then run tests. The agent column keeps Codex's own exit code, so agent step failures aren't masked by test results. Swap npm test for your own check, and set account according to the machine's login method — that way every row in runs.tsv carries all four fields, giving you a basis for before-and-after comparisons.

The cost of pinning also showed up on October 14: anyone pinned to gpt-5.5 with a ChatGPT login had to change their configuration. OpenAI listed a set of places to update: workspace defaults, saved model settings, managed configuration, custom agents, scheduled tasks, and scripts still selecting gpt-5.5. That's a benign break — change one line in the diff, rerun the task, compare the old and new rows.

What tools can and can't do

The author's Hermes IDE (disclosure: the author is involved) forces you to choose agent, model, reasoning effort, and account when creating a new task with ⌘N, supports saving multiple accounts per agent and reusing them as presets, and shows each session's own cost and model used, with model info in consistent positions when Claude Code and Codex run side by side.

But it doesn't write your runs.tsv, and it can't stop a vendor from retiring your chosen model. It turns selection into an explicit action and keeps it visible; logging is still your responsibility.

So who actually ran your last eval?

Dig up that result you last shared with your team — a benchmark, a conclusion that "this agent is better at X," a before-and-after prompt change. Can you say which model and which reasoning effort produced it?

If you can't, what you tested was a catalog entry. The cost of pinning is one line of configuration; the cost of not pinning is that every conclusion may rest on shifting ground.

One-line Summary

Codex's default model changed three times in half a month — agent eval results that don't record the model and configuration become incomparable.

Paragraph Summary

The article traces three changes to Codex's default model between September 29 and October 14, noting that the sneakiest was new TUI threads silently inheriting the server-side default — users changed nothing, yet the model may have changed. The default model is actually determined by the CLI's built-in catalog sorted by priority, not actively chosen by the team; Claude Code's aliases point the same way. The author stresses that any claim about agent capability implicitly refers to a specific model, and that reasoning effort and account type also change results — so the minimum record should include model, reasoning effort, account type, and commit, with a script that uses profiles and codex exec to pin configuration and write to runs.tsv.