GPT-5.5’s October 14 Codex Retirement: Audit Every Execution Path

OpenAI will remove GPT-5.5 from ChatGPT, ChatGPT Work, and Codex on every plan on October 14, 2026. The September 14 retirement notice gives Codex users who sign in with ChatGPT a specific replacement: change gpt-5.5 to gpt-5.6-sol. It also draws a precise boundary around the announcement: the OpenAI API is not affected.

The obvious reading is that this is a model-picker cleanup. That misses the operational risk. An agent workflow can inherit its model from a workspace default, a local or project config, a selected profile, a custom worker, a scheduled task, a launch script, or saved thread state. It can cross a different access boundary depending on whether Codex is using ChatGPT sign-in or an API key. Changing the visible default may leave the real execution path untouched.

Treat this retirement as a controlled infrastructure migration. Inventory the complete route that performs the work—product surface, authentication class, effective configuration, client version, delegated workers, and persisted state—then accept Sol against business completion, not merely a successful response. The routes easiest to overlook are not the ones in the model picker. They are the quiet automations that wake up after the deadline.

In an agent system, a model is an expiring runtime dependency distributed across configuration and state.

Draw the boundary OpenAI actually announced

The scope matters more than the headline. OpenAI’s dedicated model-retirement guidance says GPT-5.5 is leaving ChatGPT, Work, and Codex across consumer, Business, Enterprise, and Edu plans. It explicitly excludes the API. For Codex users authenticated through ChatGPT, OpenAI says to move explicit selections to gpt-5.6-sol.

Two unknowns should stay unknown. OpenAI has not published a cutoff time or timezone, and the inspected notice does not promise an automatic remap, fallback, or particular error mode. Plan to be off the retiring route before October 14 rather than designing around an imagined midnight or rescue behavior.

The API exclusion is equally precise. It means this retirement does not remove GPT-5.5 from the API on October 14; it does not promise that GPT-5.5 will remain there indefinitely. OpenAI’s API deprecation policy describes a different notice regime for API models. Product continuity and API continuity run on different clocks.

Migrate execution paths, not model strings

A fleet scan that asks only whether gpt-5.5 still exists can produce both kinds of wrong answer. It may mark an API call as endangered even though this deadline excludes it. Or it may mark a Codex automation as safe because the API catalog still lists the model, even though that automation reuses ChatGPT authentication and loses product access on October 14.

An inventory record—not an actual Codex configuration schema—could look like this:

model: gpt-5.5
surface: codex-local
auth_class: chatgpt
config_source: named-profile
profile_name: release-audit
worker: release-reviewer
state: resumed-thread
next_run: 2026-10-20

That record contains no credential. It does contain enough operational context to answer the useful question: will this route still be valid at its next run? Model availability belongs in scheduler metadata.

Authentication is especially easy to misclassify. OpenAI’s Codex authentication documentation says local Codex can use ChatGPT or API-key authentication, while Codex cloud requires ChatGPT sign-in. A script invoking codex exec is not automatically an API workload; the non-interactive guide says it reuses saved CLI authentication by default.

Switching an affected local workflow to an API key may preserve access to GPT-5.5 for now, but it is not a transparent rollback. Billing moves to the API organization, data-sharing and retention controls follow that organization, and product capabilities can differ. Treat it as a second deployment with its own administrative review and acceptance test—not as an escape hatch to flip after failure.

This is the operational follow-up to our earlier analysis of model-access risk: catalog access does not prove workflow continuity. Here, the response is concrete—inventory saved, delegated, and infrequently executed routes before the product boundary moves.

Configuration debt hides below the workspace default

OpenAI tells customers to inspect workspace defaults, saved settings, managed configurations, custom agents, scheduled tasks, and scripts with explicit model selections. That list is a clue: this is a graph migration. A root session can run Sol while a named worker still pins GPT-5.5. A clean user config can coexist with a higher-priority project override. A monthly task may not execute once during the preparation window.

Current Codex configuration precedence runs from CLI overrides down through trusted project configuration, a selected profile, user configuration, cloud-managed defaults, system configuration, and built-in defaults. The closest trusted project configuration wins within the project layer. Editing a central default therefore cannot prove that the effective value changed everywhere.

1. Search active user, project, profile, system, and managed configuration sources. Record why each model reference exists before editing it.

2. Inspect custom-agent files and the default subagent model. A worker’s file can override the value resolved from its parent or an explicit spawn request.

3. Inspect scheduled task definitions, including reasoning level and whether the task starts a fresh chat or retains an existing chat’s context.

4. Inspect launch scripts and CI definitions for --model or -m flags, then determine which saved authentication class the process actually uses.

5. Exercise fresh and resumed routes separately. In existing App Server integrations, a model or effort choice can persist in thread state after on-disk configuration looks clean.

Version details matter during the inventory. The advanced configuration guide says Codex 0.134.0 and later stores profiles as separate ~/.codex/<profile-name>.config.toml files rather than nested profile tables in the main config. Do not apply a current migration snippet blindly to an older client—or search only the legacy location on a new one.

TOML configuration:

# For the affected ChatGPT-authenticated path
model = "gpt-5.6-sol"

Shell examples:

codex --model gpt-5.6-sol
codex exec -m gpt-5.6-sol "Review the current changes"

Those examples change a model selection; they do not replace the rest of a configuration file. Preserve sandboxing, approval policy, tool access, and managed requirements. OpenAI’s workspace availability guide separates model entitlement from execution permissions. A permissive sandbox cannot grant Sol access, and a model migration should not quietly weaken a restrictive sandbox.

Sol is the prescribed target, not a promise of equivalence

OpenAI recommends gpt-5.6-sol for this Codex migration even though GPT-6 Astra is newer. That is useful product guidance: the supported retirement path and the model with the largest version number answer different questions. Our earlier Astra analysis argued for treating Astra as an escalation model. Start with Sol, then earn any routing change with workload evidence.

On the API specification pages, GPT-5.5 and GPT-5.6 Sol both list 1,050,000 context tokens and 128,000 maximum output tokens. Those matching limits say nothing about whether a research agent searches when it should, a refactor stays within scope, or a resumed task preserves the right intent. Specification compatibility is not behavioral compatibility.

Even the family name is not a complete checkpoint identifier. OpenAI’s August GPT-5.6 system card distinguished updated ChatGPT revisions from the July versions then used in Codex and Work. That historical fact does not establish what each surface serves today. It does show why a successful test in ordinary ChatGPT cannot certify a Codex scheduler just because both interfaces display GPT-5.6.

Test the model inside the product, identity, tool harness, configuration, and state that will perform the real work.

A clean exit code is not a migration test

Model migrations can fail politely. The request returns valid prose. The process exits zero. Yet the agent skipped a required search, omitted an artifact, edited beyond scope, or stopped before verification. If the acceptance check asks only whether the call completed, the most expensive regressions pass.

A July Codex issue offers a narrow example. Its author reported three completed GPT-5.5 research runs and no completed runs in three trials each for Sol and Terra under an allegedly unchanged setup. This was a small user-run experiment, not an OpenAI finding, and it may reflect older model or harness behavior. The durable lesson is the test shape: required search and artifact production were observable outcomes, so a superficially normal response could still fail the job.

Build the suite from real work, especially the ugly middle: multi-file changes, tool-heavy research, structured deliverables, interrupted tasks, named workers, and approval boundaries. Capture correctness, scope control, actual tool use, artifact completeness, wall time, retries, and human rework. The useful migration metric is accepted tasks per unit of cost and review—not benchmark rank alone.

case_id: monthly-release-audit
route: scheduled-codex
auth_class: chatgpt
expected_model: gpt-5.6-sol
required_evidence:
  - official_source_retrieved
  - output_schema_valid
  - artifact_saved
  - no_external_publish
pass: all_required_evidence_present

Do not wait for a monthly job’s next natural run if it falls after the cutoff. Trigger a safe canary now. OpenAI’s automation guidance recommends manually testing tasks and reviewing early scheduled outputs. A task definition existing is not evidence that the future route works.

Make retirement and optimization two deployments

For the first comparison, keep the prompt, tools, agent topology, approval policy, and—where both models support it—the named effort setting fixed. That is a comparison control, not a claim of equal compute or behavior. OpenAI says there is no exact GPT-5.5-to-GPT-5.6 effort mapping; the same effort label does not make the runs equivalent. After continuity passes, OpenAI’s latest-model migration guide recommends comparing the current setting with one level lower as a separate optimization experiment.

1. Inventory: assign an owner and record surface, authentication class, client version, effective model and effort, config source, workers, schedule, next run, permissions, billing boundary, and fallback plan.

2. Baseline: replay representative work on GPT-5.5 while it is still available. Preserve outputs, traces, review notes, and measurable acceptance criteria.

3. Canary: move a small affected slice to explicit gpt-5.6-sol. Cover root and delegated work, fresh and resumed state, interactive and scheduled execution.

4. Cut over: update reviewed references and verify the effective route after restart. Preserve intentional API baselines and historical records instead of doing a blind global replacement.

5. Optimize: only after continuity passes, experiment with effort, prompt simplification, cheaper routing, cache strategy, or a higher-capability escalation model.

6. Recover: test a post-cutoff path that does not depend on reselecting GPT-5.5 in the retiring product. Keep artifacts and resumable business state outside the model selection itself.

That recovery step extends a point from our earlier piece on the OpenAI Agents API: keep an application-owned ledger even when renting the harness. The retirement adds model availability and migration status to that ledger. If the only copy of task state lives inside a model-bound thread, recovery is coupled to the surface that is changing.

The cheaper rate card still needs a workload denominator

The current API pricing page lists standard short-context rates per million tokens of $5 input, $0.50 cached input, and $30 output for GPT-5.5, versus $4, $0.40, and $20 for Sol. At identical billable volumes, Sol is cheaper. But identical volumes and behavior are assumptions, not migration results.

Those figures are API dollars, while the affected route in this announcement is subscription-backed. They do not promise lower included-usage consumption or product-credit costs. OpenAI’s ChatGPT Work and Codex pricing guide says the products share usage and describes task-dependent estimates; the account dashboard and applicable contract remain the useful product-side measures.

For a simple illustration, 100,000 uncached input tokens and 10,000 output tokens cost $0.80 on GPT-5.5 and $0.60 on Sol at those rates. That is a 25% reduction for the constructed request, not evidence of a 25% cheaper production task. Tools, service tier, cache writes, long-context premiums, agent fan-out, extra reasoning, and retries can all change the result.

The prompt-caching guide lists Sol cache writes at 1.25 times uncached input and reads at 0.1 times. At the current base rate, a cold cache write is $5 per million tokens—the same as GPT-5.5’s ordinary uncached input rate—while repeated reads are cheap. One-off work and high-reuse work can therefore have very different economics.

Sol’s model page says its promotional API price is available at least through November 21, 2026. That does not predict an increase on November 22. It does create a second calendar item: re-check the rate and cost per accepted task after the retirement migration settles. Economics measured only during a dated promotion are not a durable budget.

Three original reads beyond this deadline

Interpretation 1 — Agent platforms need a model bill of materials

Package managers expose dependency versions, lockfiles, and advisories. Agent platforms need the equivalent for models: effective model, product surface, authentication class, configuration source, worker inheritance, last verified date, retirement date, and next scheduled run. A model string buried in a profile is configuration debt; a visible dependency record is operable infrastructure.

Interpretation 2 — Continuity policy belongs in procurement

Teams evaluate model quality and price while often ignoring the lifecycle inherited from the access surface. This retirement shows why that is incomplete. A subscription-backed agent product and an API model from the same company can have different notice windows and migration paths. Procurement should record which continuity policy each workflow rents, not simply which lab provides the inference.

Prediction — The hardest failures will come from cold paths

The model picker will be the easiest place to fix. The likely stragglers are a quarterly audit, a custom worker used only during incidents, a managed default restored on restart, or a thread resumed after weeks. This is a prediction, not a reported outage pattern, but it follows from the persistence surfaces OpenAI asks customers to audit. Organize coverage by execution path and next-run date, not by how many files were edited.

Questions builders are likely to ask

Is OpenAI shutting down the GPT-5.5 API on October 14?

No. The retirement announcement explicitly excludes the OpenAI API. That exclusion applies to this notice; it is not an indefinite availability guarantee. Track future API deprecation notices separately.

Will Codex automatically fall back to Sol?

The inspected guidance does not establish an automatic fallback, remap, or specific error behavior. Update explicit selections and test the effective route instead of relying on an undocumented outcome.

Does changing the workspace starting model fix every workflow?

No. A starting model does not grant access, and higher-priority project or CLI settings, custom-agent files, saved task selections, and persisted thread state can resolve differently. Confirm the effective model on each execution path.

Why does OpenAI point Codex users to Sol instead of Astra?

The retirement-specific guidance names Sol. OpenAI does not say in that notice that Sol is identical to GPT-5.5 or universally superior. Treat it as the supported starting target, validate your workload, and make later routing decisions from measured results.

Treat October 14 as a rehearsal for durable agent operations

GPT-5.5’s October retirement is narrow: three product surfaces change, the API does not. But that boundary exposes a broad engineering problem. Agent systems accumulate model choices in the same way applications accumulate library versions—across defaults, overrides, workers, state, automation, and access contracts.

Builders who treat the notice as a dropdown update may discover the hidden dependency only when an unattended task wakes up. Builders who inventory the full execution route, test business completion, separate retirement from optimization, and preserve state outside the model route will get something more valuable than a clean Sol cutover: a repeatable migration discipline for every retirement that follows.