How I Use Codex After GPT-5.6: Sol, Terra, Luna, Local MCP, and a Safe Claude Code Migration

I downgraded my Claude Code subscription after thirteen months. That is not a verdict that Claude became weak. It is a workflow decision: GPT-5.6 made Codex useful enough for the work I actually do, and the ChatGPT/Codex experience removed a boundary that had been costing me attention every day.

The old boundary was simple. I would think in ChatGPT, then re-explain the task in Codex before it could touch my repository. My local MCP tools and memory were useful on the coding side, but the planning conversation lived elsewhere. I was paying the tax of handoff: repeated context, a second briefing, and the quiet anxiety that the implementation agent was acting on a simplified version of the original intent.

That is the thing I changed. Not my entire toolkit. Not my standards. Not my willingness to use Claude as an independent reviewer. I changed my default operating loop.

Watch the workflow test: Embed the published YouTube Short here: https://youtube.com/shorts/xK2CoOiON7E

OpenAI announced GPT-5.6 across ChatGPT, Codex, and the API on July 9, 2026. Its product positioning is clear: Sol is the flagship tier for difficult work, Terra is the balanced tier, and Luna is the cost-efficient/high-volume tier. Eligible Codex users can choose the tiers and an effort setting, subject to account availability. OpenAI’s launch post is the source for those product statements.

Source: OpenAI model guide, captured July 18, 2026. This is API product documentation, not a claim about every ChatGPT or Codex plan.

This article is not an instruction to cancel Claude Code. It is a practical system for people who want to test Codex honestly: choose the right tier, carry local tools safely, treat context as a budget, and migrate workflow behavior instead of blindly copying configuration.

The model is not the whole product

The wrong question is, “Which model wins?” It produces a clean argument and a bad operating system.

The better question is: which system gets my verified result with the least re-briefing, least unsafe access, and fewest human corrections?

That system has at least five parts:

1. The model’s reasoning and coding ability.
2. The client where I plan, inspect, execute, and review.
3. The tools it can use, including local MCP servers.
4. The permission boundary around those tools.
5. The evidence it leaves behind: a diff, tests, source links, and a checkpoint another person can inspect.

Benchmarks can contribute to the first part. They cannot settle the other four.

Artificial Analysis reported GPT-5.6 Sol (max) at 59 and Claude Fable 5 (max) at 60 on its Intelligence Index. In the same company’s coding-agent reporting, it listed GPT-5.6 Sol (max) in Codex at 80, while GPT-5.6 Terra (max) and Claude Fable 5 (max) in Claude Code both scored 77 on its Coding Agent Index. Those are useful measurements, not a licence to say that any one model is universally superior. Artificial Analysis also says it supported OpenAI with pre-release evaluation; that relationship belongs beside the numbers, not in the small print. See its GPT-5.6 analysis and July 17 comparison.

Source: Artificial Analysis, “GPT-5.6 benchmarks across Intelligence, Speed and Cost”, captured July 18, 2026. The values remain third-party measurements using its stated harnesses—not Qualixar-run tests.

Evidence boundary: The figures above are third-party measurements, not Qualixar-run tests. Any future chart must preserve the original harness, settings, date, source link, and Artificial Analysis disclosure.

The decision I made is narrower. For my current combination of technical research, local tools, repositories, visual production, and independent verification, Chat plus Codex now makes it easier to preserve the intent of the work. Claude remains useful where its style, context, or independent perspective earns the seat.

That is a more defensible claim than “Model X destroys Model Y,” and it is much more useful to a working engineer.

The three-tier operating model

Sol, Terra, and Luna are not three identities. They are three economic and operational choices. The mistake is using the largest tier for every request because it feels safer, then blaming the product when you burn agentic allowance on formatting, file discovery, or a task that should have been two commands.

I separate model tier from task risk.

Tier	My default use	What I require before I use it	What it is not for
Luna	Mechanical discovery, classification, formatting, extracting a file inventory, and repetitive bounded work.	Narrow scope, explicit file boundary, and an easy way to check the result.	Ambiguous architecture, broad research synthesis, or a task where a subtle error is expensive.
Terra	Normal implementation, a focused refactor, adapting one MCP surface, or producing a tested first draft.	Acceptance criteria, named test command, and a clean rollback point.	A task with unresolved product ambiguity or a security boundary it cannot independently prove.
Sol	Architecture, difficult debugging, migration review, source-sensitive research, and a final independent critique.	A good brief and evidence. Sol is not a substitute for either.	Making a vague task precise for you, or checking its own work without tests and inspection.

This is an operational recommendation, not a benchmark conclusion. The expensive failure is what determines the tier. If the output is a table that a human will check in thirty seconds, Luna may be enough. If the output changes a permission boundary, affects a production system, or sets a published technical claim, use a stronger tier and a separate verification step.

The same logic applies to effort. More effort is not free reliability. It is only justified when thinking time will reduce rework or prevent a material error.

Context is a budget, not a trophy

The most emotionally satisfying number in AI is the context window. It sounds like the end of forgetting. It is not.

OpenAI’s API page documents GPT-5.6 Sol with a 1.05 million-token context window and a 128K maximum output. That is an API model specification. It should not be turned into a promise that every ChatGPT or Codex desktop session on every plan will accept, retain, and reason over that amount of material in the same way. The Sol model page is precise about the API capability; my desktop workflow is a separate observation.

Even when a large window is available, dumping an entire repository, every Slack thread, and months of notes into one task is usually a bad design. You get retrieval noise, uncertain priorities, weaker review, and no clean way to know what evidence actually changed the outcome.

I use five rules instead:

1. Put the acceptance test before the context. Start with the exact observable outcome: files allowed to change, interfaces that must not change, test command, and prohibited actions. The agent should know what success means before it sees the repository’s history.
2. Scope files intentionally. Give it the entry point, adjacent module, relevant tests, and source-of-truth documentation. Let it expand only when it can explain why.
3. Separate sources from speculation. For research work, provide the source URL or the locally saved source excerpt. Do not ask the agent to remember what a screenshot vaguely implied.
4. Checkpoint the state. Before a long handoff or a compacted session, retain a small structured note: objective, decisions, changed files, commands run, tests, unresolved risks, and next action.
5. Make re-reading useful. If the agent must reopen a lot of material, ask it to report the specific file or source that changed the decision. This exposes context theatre.

The pattern is bounded context plus durable memory. Context is the working set. Memory is the small set of facts worth retrieving in future tasks. They are not substitutes.

Local MCP is where the workflow becomes real

For my work, the important change was not just a stronger model. It was being able to keep planning and action closer to the same local tool environment.

OpenAI lists MCP as a supported tool for GPT-5.6 Sol in the Responses API. Anthropic also documents MCP in its own ecosystem. That makes the protocol relevant to a migration, but it does not mean every server, authentication flow, approval model, or client configuration imports unchanged. Read OpenAI’s model documentation and Anthropic’s MCP documentation as protocol/product references—not as a one-click migration manual.

The safe local pattern is boring on purpose:

Task brief
  ↓
Agent selects only the needed tool
  ↓
Read-only operation first
  ↓
Result is checked against source/repository
  ↓
Write action only with narrow permission and rollback
  ↓
Checkpoint records what happened

Start with the most harmless useful path. A repository search server, a local memory lookup, or a read-only analytics query is a better first test than a tool that publishes, sends messages, edits a production database, or scans your whole home directory.

Do not call an MCP server “migrated” because it appears in the tool menu. Test three things:

• the normal read path produces the expected result;
• a bad request fails clearly without leaking a secret or silently guessing;
• any write path is disabled until it is explicitly needed, bounded, and reversible.

That is AI Reliability Engineering in practice. The agent is not reliable because it can call more tools. It is reliable because every important action has a small permission boundary and evidence that it worked.

Migrate Claude Code by surface, not by copying files

This is the part that causes bad migrations.

Claude Code and Codex can both be configured with project instructions, MCP servers, lifecycle behavior, permissions, and memory systems. That does not make their files interchangeable. In my local environment, the server names overlap substantially, but the observed lifecycle event sets differ. Claude has pre-tool and pre-compaction behavior available in the current setup; Codex exposes a different set of lifecycle hooks. The correct response is not to force a file copy. It is to rebuild the behavior you actually care about.

Surface	Migration decision	The safe move
Project instructions	Adapt	Move durable repository rules into Codex-oriented instructions. Remove client-specific commands and rewrite responsibilities in terms of outcomes and verification.
MCP servers	Port selectively	Bring over one server at a time, beginning with a read-only operation. Review command, authentication, working directory, consent, and write scope.
Session-start automation	Rebuild by outcome	Restore a minimal task context, not an unbounded conversation dump. Verify that it contains useful facts but no private spillover.
Pre-tool guardrails	Redesign	If the target does not have the same event surface, put the constraint in its own policy/instructions and test an out-of-scope action in a disposable repository.
Compaction behavior	Adapt	Create compact checkpoints before the context is lost: objective, evidence, files, commands, risks.
Permissions	Re-authorize	Start read-only. Add filesystem, network, or destructive rights only when a bounded task proves the need.
Persistent memory	Evaluate	Retain stable facts and corrections, then test retrieval and false recall. A larger context window is not a memory architecture.

The migration rule is: inventory → port one bounded surface → run a real task → compare outputs → keep or roll back.

The companion local migration map turns that rule into a 30-minute checklist with a tested local surface inventory. Before publishing it externally, remove local server names. The portable lesson is the method, not the contents of one workstation.

The operating loop I trust

My workflow is now deliberately asymmetric:

Plan → Execute → Verify → Retain
Chat     Codex      Tests + review    Small, source-linked memory

Planning asks whether the task should exist, what the success condition is, and what could make the conclusion wrong. Execution changes the files or consults the tools. Verification checks tests, sources, diffs, and scope. Retention keeps only the decision and evidence that a future task needs.

The loop matters because it separates the four ways an agent can fail:

• It can misunderstand the goal.
• It can use a tool incorrectly.
• It can make a change that looks plausible but breaks behavior.
• It can preserve a bad conclusion and make future tasks confidently wrong.

No single benchmark measures all four. A production workflow has to.

For critical work, I keep Claude Code as an independent reviewer or use it where its approach is a stronger fit. The point is not model loyalty. The point is adversarial diversity: do not let the same system frame the task, make the changes, and approve the result without an external check.

The brief that prevents expensive agentic work

Most waste happens before the first tool call. A vague instruction such as “clean up the auth system” forces the agent to choose the definition of clean, invent the scope, and decide when it is finished. A stronger model can make that ambiguity harder to notice, not less dangerous.

Before I create a Codex task, I write a small task card. It takes two minutes and routinely saves far more than two minutes of agentic execution:

Objective: Add a retry-safe token refresh path for the existing client.

Allowed scope: src/auth/* and the corresponding unit tests only.
Must not change: public method signatures, token storage format, or network client.

Evidence: link to the failing test and the API contract.

Acceptance: the named tests pass; a second refresh does not duplicate a request;
the diff contains no unrelated formatting changes.

Verification: run <exact test command>; report files changed, commands run,
and any assumption that could not be proven.

The card gives Luna a safe boundary, gives Terra something it can implement and test, and gives Sol a concrete artifact to challenge. It also makes review fair: if the agent stepped outside scope, we know it; if the requirement was incomplete, we know that too.

This is the same pattern I use for research. Replace the test command with a source standard: official primary source first, independent corroboration for load-bearing claims, explicit uncertainty where the evidence does not entail the conclusion. The artifact is then not “a convincing answer.” It is a source-linked answer that another person can audit.

A 30-minute starting checklist

If you are migrating today, this is the smallest useful start:

1. Record the current repository commit and the enabled behavior of your existing setup. Do not put credentials in the record.
2. Make a clean Codex project and add only the instructions needed for one small acceptance task.
3. Add one read-only MCP server, if you use MCP at all. Confirm a successful read and a clear failure path.
4. Run the same bounded task against a fixed repository snapshot. Define allowed files, a test command, and a rollback point before the agent acts.
5. Compare the resulting diff, tests, tool use, time, unexpected changes, and human corrections.
6. Add session context and checkpointing. Only then add broader permissions or automation.
7. Keep a one-page evidence log. It is worth more than a week of model arguments.

If you cannot name the acceptance test, you are not ready to blame the model. If you cannot roll back the tool action, you are not ready to grant the permission. If you cannot explain which source changed the recommendation, you are not ready to publish the claim.

Final position

GPT-5.6 did not make every other model irrelevant. It made my Codex workflow coherent enough to become the default for a larger share of my work.

Sol, Terra, and Luna matter because they let me choose the right level of reasoning and spend for the task. Local MCP matters because planning can connect to real, constrained tools. Context discipline matters because more tokens do not solve poor task design. And a careful Claude Code migration matters because a setup is a system of instructions, permissions, lifecycle behavior, and memory—not a folder to copy.

That is the real lesson of this switch: do not pick an AI tool like a sports team. Build a loop that can prove whether it helps.

---

Sources

1. OpenAI, GPT-5.6: Frontier intelligence that scales with your ambition, July 9, 2026.
2. OpenAI, GPT-5.6 Sol model documentation, accessed July 18, 2026.
3. Artificial Analysis, GPT-5.6 benchmarks across Intelligence, Speed and Cost, July 9, 2026.
4. Artificial Analysis, Four frontier launches in eight days, July 17, 2026.
5. Anthropic, Model Context Protocol documentation, accessed July 18, 2026.