DEV Community: Owen

Claude Code fallbackModel: 3-Tier Failover Setup (2026)

Owen — Wed, 15 Jul 2026 08:28:04 +0000

Claude Code fallbackModel retries up to 3 models on a 529 overload, not on 429. Set it up in 4 steps (settings.json + CLI) and know when a gateway wins.

Set Up 3-Tier Failover in 4 Steps

When Anthropic returns a 529 overloaded_error, an unconfigured Claude Code session retries the same model, then hands you the error. A fallback chain turns that dead end into a downshift: overloaded on Opus, retry on Sonnet, and if that is also unavailable, Haiku.

What you can do

Keep a turn alive through a 529 overload by having Claude Code try up to three backup models in order

Time required

About 5 minutes

What you need

Claude Code v2.1.197+ (for the Sonnet 5 alias), account access to the models you list, and edit access to a settings.json

The whole configuration is one array:

{
  "model": "opus",
  "fallbackModel": ["sonnet", "haiku"]
}

That is a three-tier chain: opus is the primary, sonnet and haiku are the fallbacks. The rest of this guide is about the parts that are not obvious from the array: which errors actually trigger it, why a 429 does not, how the chain behaves across a team, and where a single-account chain stops helping.

What You Can Do After This Setup (And What You Can't)

A fallback chain is a narrow tool. It is worth being precise about its edges before you build one, because the failure it fixes looks a lot like two failures it does not.

Here is what a fallback chain does for you:

Survives a transient Anthropic overload (529 overloaded_error) without losing the turn.
Keeps working when a specific model is unavailable, for example a model pinned in settings that has since been retired.
Downshifts capability deliberately, so a hard task that starts on Opus finishes on Sonnet rather than not at all.

Here is what it will not do:

Get you past a 429 rate limit or a usage cap. Those are quota problems, and every model in the chain draws from the same account quota.
Fail over to a different provider. Chain elements resolve to Claude models on one account, so a total Anthropic outage takes the chain down with it.
Change your primary model permanently. A switch is per-turn, and the next message starts on your primary again.

If your recurring pain is "usage limit reached" rather than "overloaded," a fallback chain is the wrong fix. See the separate guide on rate limit reached in Claude Code, and for the API-level version of the overload itself, Claude API error 529.

Decision Frame: When to Use This Setup (and When NOT)

When to use it

You run Claude Code in an unattended or scripted context (CI, a long agent run, an overnight task) where a mid-turn 529 would otherwise abort the whole job.
You are on a paid API or high tier where overloads, not quota, are your usual interruption.
You can tolerate a quality downshift for the rest of a turn in exchange for that turn completing.

When NOT to use it

Your interruptions are 429s or "usage limit reached." A chain does nothing here; fix quota or caching instead (token optimization is the lever).
You need every turn on a specific model for reproducibility. A silent downshift to Haiku mid-run can change output quality in ways a later step depends on.
You need provider-level resilience. One account cannot fail over to itself; that needs a gateway (covered below).

Stop rule

If all you want is a single automatic backup on overload, add one entry and stop: "fallbackModel": ["sonnet"]. The three-tier chain matters only when you expect Sonnet to be under load at the same time as Opus, which mostly happens during a broad platform incident.

System Requirements

Requirement	Detail
Claude Code version	v2.1.197+ so the `sonnet` alias resolves to Sonnet 5; v2.1.154+ for Opus 4.8. Run `claude update` if unsure.
Model access	Every model you list must be reachable on your account. An element you cannot reach is skipped, not fatal, but a chain of unreachable models fails like no chain at all.
Settings location	A `settings.json` you can edit: `~/.claude/settings.json` (user) or `.claude/settings.json` (project).
Provider	The examples assume the Anthropic API. On Bedrock, Google Cloud, or Foundry, aliases resolve to different versions and you may need full deployment IDs.

The three aliases and what they resolve to on the Anthropic API today:

Alias	Model	API ID	Input / Output (per MTok)	Context	Effort default
`opus`	Opus 4.8	`claude-opus-4-8`	$5 / $25	1M	high
`sonnet`	Sonnet 5	`claude-sonnet-5`	$3 / $15	1M	high
`haiku`	Haiku 4.5	`claude-haiku-4-5-20251001`	$1 / $5	200K	(no effort control)

Two details from that table shape a sensible chain. Sonnet 5 carries introductory pricing of $2 / $10 per MTok through August 31, 2026, so the middle tier is cheaper than list right now. And Haiku 4.5 has a 200K context window, not the 1M that Opus and Sonnet carry, so a long session that overflows 200K will not fit on the Haiku tier. Order your chain with that in mind: Haiku is a last resort for capacity reasons, not just quality.

Step-by-Step Setup

Step 1: Confirm your primary model and version

claude --version
claude   # then run /status inside the session

/status shows the active model. If opus is not resolving to Opus 4.8, or sonnet is not Sonnet 5, run claude update first. Expected result: a version at or above 2.1.197 and a recognizable primary model.

Step 2: Test a chain for one session with the flag

Before you persist anything, try the chain with the CLI flag. It accepts a comma-separated list and overrides any saved setting, which makes it the safest way to experiment.

claude --model opus --fallback-model sonnet,haiku

Expected result: the session starts on Opus. You will not see the fallbacks unless an overload actually occurs, at which point Claude Code prints a notice naming the model it switched to.

Step 3: Persist the chain in settings.json

Once the flag behaves, move it into settings so every session inherits it. Use either aliases or full model IDs; full IDs pin a version and survive alias changes.

{
  "model": "opus",
  "fallbackModel": ["claude-sonnet-5", "claude-haiku-4-5"]
}

Expected result: new sessions start on Opus with a two-model fallback chain, no flag needed. The --fallback-model flag still wins for any session you launch with it.

Step 4: Verify the trigger conditions, not the happy path

You cannot manufacture a real 529 on demand, so verify the parts you can reason about instead of waiting for an outage. Confirm each element resolves to a model you can reach, and confirm you understand what will not trigger it. Do not rely on an error to tell you the chain is read: Claude Code does not validate fallbackModel at startup (verified on v2.1.208), so a malformed value is silently ignored rather than throwing. That last point, what will not trigger it, is where most misconfigurations hide, so it gets its own section.

What Triggers a Fallback (and What Doesn't)

This is the table to internalize. A fallback fires on availability failures and stays silent on everything else.

Condition	HTTP	Triggers fallback?	What actually happens
Overloaded	529 `overloaded_error`	Yes	Switches to the next model in the chain
Model unavailable	varies	Yes	Skips to the next reachable element
Other non-retryable server error	5xx	Yes	Switches to the next model
Rate limit	429	No	Normal retry with backoff, then surfaced
Authentication	401	No	Surfaced as an auth error
Billing	402/403	No	Surfaced as a billing error
Request too large	413	No	Surfaced as a size error
Transport / network	n/a	No	Normal retry, then surfaced

The 429 row is the one that trips people. A rate limit means you have exhausted a quota, and every model in your chain bills against the same account, so switching from Opus to Haiku does not create headroom. Claude Code knows this and refuses to burn a fallback on it. If your logs show fallbacks that never fire during an incident, check whether the incident is actually a 429.

Here is the same logic as a flow:

flowchart TD
    A[Model request] --> B{Response}
    B -->|529 / unavailable / non-retryable 5xx| C{More models in chain?}
    B -->|429 / auth / billing / size| D[Normal retry, then surface error]
    B -->|success| E[Return result for this turn]
    C -->|yes| F[Switch to next model, show notice]
    C -->|no| D
    F --> A
    E --> G[Next message tries primary first again]

Choosing Your Chain Order

The order of the array is the order Claude Code tries, so the array is a priority list, not a set. Two defaults cover most cases, depending on what you optimize for.

Capability-first (["sonnet", "haiku"] under an opus primary) keeps quality as high as availability allows and only drops to Haiku when both larger models are overloaded at once. Use it for interactive work where a downshift is a genuine last resort.

Cost-first (sonnet primary, ["haiku"] fallback) never reaches for Opus at all. Use it in CI and agent loops where throughput and predictable spend matter more than the ceiling. The hybrid routing argument applies here: most turns do not need Opus, so making it the primary just to have a tall chain wastes money on the common case.

One constraint outranks both preferences, and it is easy to miss: context window. Haiku 4.5 carries a 200K window against the 1M that Opus 4.8 and Sonnet 5 provide. A session that has already grown past 200K cannot land on the Haiku tier at all, so on long-context work Haiku is effectively absent from the chain no matter where you place it. If your sessions routinely run large, keep the chain on the 1M-window tiers and accept that a simultaneous Opus-and-Sonnet outage will fail the turn rather than silently truncate context.

What the Switch Looks Like

A fallback is never silent. When one fires, Claude Code prints a notice in the transcript naming the model it moved to. Because the switch is scoped to the turn, you see that notice again on the next overload rather than a session that quietly settles onto Haiku. Misconfiguration, by contrast, is silent: a malformed fallbackModel value is ignored without a warning (verified on v2.1.208), so a broken chain looks exactly like a working one until an overload finds the gap. To confirm a chain is actually live, do not look for a startup error; audit it from the modelUsage field of a JSON run, as described next.

In non-interactive runs (-p / --print) that emit JSON, the plain-text notice is suppressed, so read the model that actually answered from the modelUsage field of the result message rather than assuming the primary handled the turn. That is the reliable way to audit, after the fact, how often a chain caught something and which tier absorbed the load. If a chain never shows a catch across a real incident window, re-check whether the incident was a 429, which no chain covers.

Common Errors During Setup (and Fixes)

Symptom	Cause	Fix
Chain never fires during an outage	The outage is a 429, not a 529	fallbackModel does not cover rate limits; handle quota separately
Your global chain is silently gone	A project `.claude/settings.json` also defines `fallbackModel`	fallbackModel does not merge across files; the highest-precedence file supplies the entire chain
A listed model is skipped	It is retired, unreachable, or excluded by `availableModels`	Replace retired IDs; an allowlisted-out element is dropped when the chain is read
Only three of your four models run	Chains are capped at three after de-duplication	Trim the list; extra entries past three are ignored
A typo'd chain element never fires, with no error	Typos in `fallbackModel` elements are silently skipped when the chain is read	Double-check spelling yourself; use a valid alias (`opus`/`sonnet`/`haiku`) or a `claude-` prefixed ID. No startup error will catch this
Fallback ignored in a scripted run	Running non-interactively where a flagged request just ends the turn	This is the Fable 5 classifier path, not fallbackModel; see the disambiguation below

The no-merge behavior deserves emphasis because it is the opposite of how most array settings work. If you tuned a careful three-tier chain in your user settings and a repo ships a .claude/settings.json with its own single-model fallbackModel, the repo wins entirely and your chain is dropped with no warning. Precedence runs managed settings, then command-line flags, then project-local, then project, then user. Put the chain you actually want in the highest-precedence file that any given session will read.

Team / Multi-Developer Configuration

For one developer, fallbackModel in ~/.claude/settings.json is enough. Across a team, the interesting question is who owns the chain and whether individuals can override it.

Goal	Where to put fallbackModel	Notes
Personal default	`~/.claude/settings.json` (user)	Lowest precedence; any project file overrides it
Per-repo default	`.claude/settings.json` (project, committed)	Overrides user settings for anyone working in the repo
Local tweak	`.claude/settings.local.json`	Overrides project for one machine, usually gitignored
Enforced fleet-wide	managed settings	Highest precedence; individuals cannot override

Two team-specific interactions matter. First, if you also use availableModels to restrict which models developers may run, any fallback element outside that allowlist is dropped when the chain is read, so an enforced chain and an allowlist have to agree. Second, because fallback chains do not merge, a committed project chain fully replaces each developer's personal one inside that repo. That is usually what you want for CI and shared agents, but it means a developer who tuned a personal chain loses it silently while working in the repo. Document the project chain so nobody debugs a "missing" fallback that was overridden by design.

A reasonable committed project chain for a team that runs agents in CI:

{
  "model": "sonnet",
  "fallbackModel": ["haiku"],
  "availableModels": ["sonnet", "haiku"]
}

That keeps CI on the cheaper Sonnet tier, falls back to Haiku on overload, and forbids anyone from quietly switching a CI job to Opus.

Advanced: Cross-Provider Failover via a Gateway

A fallback chain has a hard ceiling: every model in it lives on the same Anthropic account. When Anthropic itself has a broad incident, all three tiers are overloaded at once, and there is nothing left in the chain to try. The March 18, 2026 outage that ran past three hours is the shape of failure a same-account chain cannot cover.

Provider-level resilience needs a layer above Claude Code. Point Claude Code at a gateway with ANTHROPIC_BASE_URL, and the gateway (rather than your one account) decides where a request lands. ANTHROPIC_BASE_URL changes where requests go, not which model answers, so a fallbackModel chain still works underneath it for model-level failover, while the gateway adds provider-level failover on top.

An aggregation gateway such as ofox exposes one OpenAI- and Anthropic-compatible endpoint that fronts many providers, so a chain can cross from a Claude model to a non-Claude one when Anthropic as a whole is unavailable, which a native fallbackModel chain physically cannot do. The trade-off is that you are now trusting a second hop, and you configure routing at the gateway instead of in settings.json. For the Claude Code side of that setup, see the Claude Code + ofox configuration guide; for the cost-driven version of the same routing idea, see hybrid model routing.

One disambiguation before the alternatives. Claude Code also has a feature literally called "automatic model fallback," and it is not this one. That mechanism is specific to Fable 5: when a safety classifier flags a request (most often cybersecurity or biology work), Claude Code reruns it on Opus and shows a notice. It has nothing to do with overloads or the fallbackModel chain. If you see fallbacks on a Fable 5 session that you did not configure, that is the classifier. Running claude --safe-mode disables your local customizations (CLAUDE.md, skills, hooks, MCP), so it isolates whether those are tripping it, but safe mode still sends things like your git status and directory names, so repository content itself can trip the classifier even then.

Alternatives That Handle Failover

fallbackModel is the built-in, zero-dependency option and should be your first choice for model-level overload resilience. When you need more, these are the layers above it.

ofox exposes a single Anthropic-compatible endpoint fronting multiple providers, so failover can cross from Claude to another model's family during a full Anthropic incident. Best when provider-level resilience matters more than staying on one vendor.
LiteLLM is an open-source proxy with its own retry and fallback list across providers. Best when you want to self-host the routing layer and already run infrastructure.
OpenRouter is an aggregator with automatic provider fallback for a given model. Best for breadth of model catalog with minimal setup.
Portkey is a gateway with configurable fallback and load-balancing policies. Best when you want routing rules rather than a static list, plus observability.

All four sit above Claude Code and complement, rather than replace, a fallbackModel chain: keep the chain for cheap in-CLI model failover, and add a gateway for the provider-level case.

FAQ

What is fallbackModel in Claude Code?

It is a settings.json key, and a --fallback-model CLI flag, that lists backup models Claude Code tries in order when the primary is overloaded or unavailable. You can list up to three. A switch lasts for the current turn only; the next message tries your primary again first.

Does Claude Code fall back automatically when it hits a 529 error?

Only if you configured fallbackModel. A 529 is overloaded_error, one of the conditions that triggers a switch. With nothing configured, Claude Code retries the same model with backoff and then surfaces the error.

Does fallbackModel help with rate limit (429) errors?

No. Authentication, billing, rate-limit (429), request-size, and transport errors never trigger a switch. A 429 means you hit your own quota, and every model in the chain bills against the same account, so switching tiers adds no headroom.

How many fallback models can Claude Code use?

Three. Chains are capped at three after duplicate removal, and extra entries are ignored. A common chain is opus, then sonnet, then haiku.

How do I set a fallback model in Claude Code?

For one session, launch with claude --fallback-model sonnet,haiku. To persist it, add a fallbackModel array to settings.json, for example ["claude-sonnet-5", "claude-haiku-4-5"]. The flag beats the setting.

Does the fallback model stay active for the whole session?

No. A switch applies to the current turn only, so a transient overload does not lock the session onto a lower tier.

What is the difference between fallbackModel and automatic model fallback?

fallbackModel (fallback model chains) covers availability, firing on overload or unavailability. Automatic model fallback is a separate Fable 5 mechanism where a safety classifier reroutes a flagged request to Opus. They only share the word fallback.

Can Claude Code fall back to a non-Anthropic model?

Not through fallbackModel. Every element resolves to a Claude model on the same account, so a full Anthropic outage takes the whole chain down together. Cross-provider failover needs a gateway that fronts more than one provider.

Originally published on ofox.ai/blog.

Kimi K2.7 Code Free (2026): 3 Zero-Cost Paths, Real Caps

Owen — Wed, 15 Jul 2026 01:40:45 +0000

"The honest answer to 'is Kimi K2.7 Code free' is that three of the paths people quote are real and one does not exist."

There is no free hosted Kimi K2.7 Code API, and no :free endpoint on OpenRouter. What genuinely costs nothing: rate-limited web chat, the free Kimi Code CLI tier, and Modified-MIT downloadable weights for self-hosting.

Kimi K2.7 Code Free: What You Can Do at $0 (and What You Can't)

Kimi K2.7 Code is Moonshot AI's open-weight model—approximately 1T parameters (32B active), 256K context, with a vision encoder. Below are the three legitimate zero-cost paths, checked against first-hand sources.

What you want	Free path that works	What you can't do free
Chat with Kimi in a browser	Web chat at kimi.com, no card, rate-limited	Call it as an API, or guarantee it runs K2.7
Run a coding agent for a few tasks	Kimi Code CLI, free "Adagio" tier	Work in it all day; it is 6 agent uses per week
Run the model on hardware you own	Download Modified-MIT weights, quantize, serve	Avoid the ~577 GB+ hardware bill
Call it as a backend API	No free hosted API; no OpenRouter `:free` variant	Get a `kimi-k2.7-code:free` endpoint, which does not exist

The fabrication happens in the API row: people search "kimi k2.7 code free api," land on a guide that points them at an OpenRouter :free route, and lose an afternoon. It is not there.

Decision Frame: Which Free Path Fits You

When each free path is the right call

Use the kimi.com web chat if you want to try Kimi's reasoning in a browser through copy-paste interaction. No installation or payment method required—fastest zero-cost entry point.

Use the free Kimi Code CLI tier if you want to see the agent interact with real files and tools. The Adagio tier provides 6 agent runs weekly, sufficient to evaluate agent fit before purchasing.

Self-host the Modified-MIT weights if you have multi-GPU infrastructure, need offline inference, or require auditable open weights for compliance. License-free; costs appear as hardware and electricity.

When NOT to chase free

Needing a hosted backend API at $0. That does not exist. The floor is the paid rate: $0.95/M input, $4.00/M output on ofox.
Planning daily agent use. The free CLI tier supplies 6 uses weekly—a trial, not production infrastructure.
Operating a single 24 GB or 48 GB GPU. A ~1T MoE requires hundreds of gigabytes even quantized to INT4.

Stop rule

Evaluating output quality needs only the free web chat (ten minutes). Testing agent capabilities requires the free CLI tier (six runs). Everything beyond requires sustained programmatic access where "free" involves real constraints.

What You Need for Each Free Path

Free path	What you need	Time to first output
Web chat (kimi.com)	A browser and a Kimi login (no card)	Under 1 minute
Kimi Code CLI, Adagio tier	The CLI installed, a free Kimi account, and a terminal	A few minutes
Self-host open weights	A multi-GPU or large-memory host, vLLM/SGLang/KTransformers, ~600 GB free disk	Hours (download plus load)

Memory is the hard constraint for self-hosting. Kimi K2.7 Code is a ~1T-parameter MoE: even native INT4 lands in the high-hundreds of gigabytes. A single consumer GPU is not in the running.

Path 1: Kimi Web Chat (Genuinely Free, Rate-Limited)

The web application at kimi.com enables chat without requiring a credit card and supports code writing inline.

Two limits and one caveat define this path:

No API. The web chat is a user interface only. The moment you need programmatic access, this path ends and you are into the CLI, self-hosting, or a paid API.

Rate limits. Free tiers carry rate restrictions with unpublished fixed numbers, so treat specific figures elsewhere as unverified. Heavy usage will encounter a ceiling.

Model version is not guaranteed to be K2.7 Code. The homepage defaults to K2.6, with K2.7 Code primarily available through the separate Kimi Code product. Do not assume the free chat hands you K2.7 Code specifically. Look at the model label in your own session, because that is the only source that reflects your account and the current rollout.

The web chat lacks codebase memory and tool access, answering only pasted queries. This suffices for assessing code style and reasoning, but fails for file-reading or command execution tasks.

Path 2: The Free Kimi Code CLI Tier (Real Agent, Small Quota)

Moonshot provides an official Kimi Code CLI with a free tier.

Installation via official script:

curl -fsSL https://code.kimi.com/kimi-code/install.sh | bash

The free tier called Adagio grants 6 agent uses with 1 concurrent task weekly, running K2.7 Code and the HighSpeed variant. Unlike the web chat, this executes as a real agent: it reads files, runs tools, and drives multi-step edits.

Kimi Code CLI tier	Price	What you get
Adagio	$0	6 agent uses/week, 1 concurrent task
Moderato	$19/mo	Higher quota, agent workflows
Allegretto	$39/mo	More quota again
Allegro	$99/mo	Team-scale usage
Vivace	$199/mo	Top quota

Six agent runs is enough to point Kimi at a real refactor, a bug hunt, and a test-writing pass, and decide whether its agent behavior is worth paying for. It is not enough to adopt it as your daily coding agent.

For integration into existing coding agents, Moonshot exposes an Anthropic-compatible endpoint: set ANTHROPIC_BASE_URL to https://api.moonshot.ai/anthropic to use Kimi with Claude Code or similar tools. This path charges per-token rather than using the free CLI tier.

Path 3: Self-Host the Open Weights (Free of License, Not of Hardware)

Moonshot released weights under Modified MIT on Hugging Face (moonshotai/Kimi-K2.7-Code). This license requires attribution from very large operators but costs nothing for developers and small teams—behaving like standard MIT.

The license does not provide free compute. Kimi K2.7 Code is a ~1T-total-parameter MoE with about 32B active per token, 61 layers, and 384 experts, plus a 400M MoonViT vision encoder. Moonshot recommends vLLM, SGLang, or KTransformers with native INT4 quantization.

Precision	Approx. weights size	Realistic host	Notes
Native INT4	~577-639 GB	Multi-GPU server (e.g. 8x A100/H100 class)	Community estimate; card gives no official figure
INT4 + KV cache/overhead	~830 GB+ total memory	Large-memory host	Comfortable inference headroom
Full precision	Well over 1 TB	H200-class cluster	Production throughput

Moonshot's own model card publishes no VRAM or disk number, so the sizes above come from third-party self-host calculators and should be read as directional, not exact.

Once served, an OpenAI-compatible endpoint becomes available:

from openai import OpenAI

# vLLM started with: vllm serve moonshotai/Kimi-K2.7-Code --quantization compressed-tensors
client = OpenAI(base_url="http://localhost:8000/v1", api_key="not-needed")
resp = client.chat.completions.create(
    model="moonshotai/Kimi-K2.7-Code",
    messages=[{"role": "user", "content": "Refactor this function to async."}],
)
print(resp.choices[0].message.content)

This path caps at the hardware bill. It is free of license fees and free of per-token cost, but the entry ticket is a large-memory, multi-GPU host, and the electricity is not free either. Self-hosting wins at high volume, offline requirements, and compliance-mandated auditable weights—not casual use.

The Path That Does Not Exist: "Kimi K2.7 Code Free on OpenRouter"

There is no free Kimi K2.7 Code endpoint on OpenRouter. Verified against the OpenRouter models API on July 14, 2026:

moonshotai/kimi-k2.7-code exists as a paid model (~$0.72/M input, ~$3.49/M output).
OpenRouter lists moonshotai/kimi-k2.6:free (the older K2.6, not K2.7 Code), showing an empty endpoints list with no live provider.
A URL like openrouter.ai/moonshotai/kimi-k2.7-code:free returns an HTTP 200 because it loads the single-page app shell, not because a free route exists.

OpenRouter's free tier is real but does not cover this model at this version. For coding work with free API tiers, choose from :free variants, which carry day and minute rate limits.

One More Free-for-You Path: The Puter User-Pays Bridge

Puter exposes moonshotai/kimi-k2.7-code through its browser SDK on a "user-pays" model. Developers integrate the SDK at zero cost; end users cover their own token consumption. It is free the way a BYO-bar is free to the host.

Legitimate for client-side tools where users bring their own usage. Not a method for free tokens on your backend. Puter's "unlimited" framing describes the developer's cost, not a documented usage limit. Review the platform's billing and data terms before deployment.

Every Free Path to Its Limit: A Side-by-Side

flowchart TD
  A[Need Kimi K2.7 Code at $0?] --> B{How do you want to use it?}
  B -->|Chat in a browser| C[kimi.com web chat]
  B -->|Drive an agent for a few tasks| D[Kimi Code CLI Adagio]
  B -->|Run on my own hardware| E[Modified-MIT weights]
  B -->|Ship in an app| F[Puter user-pays]
  B -->|Call as a backend API| G[No free hosted API]
  C --> C1[Cap: no API, rate-limited, version not guaranteed K2.7]
  D --> D1[Cap: 6 agent uses/week, 1 concurrent]
  E --> E1[Cap: ~577GB+ INT4, multi-GPU host]
  F --> F1[Cap: end users pay tokens, no SLA]
  G --> G1[Floor is paid: $0.95/M in, $4.00/M out]
  G1 --> H[Managed: moonshotai/kimi-k2.7-code on one endpoint]

Path	Free for you?	Hard limit	Best for
Web chat (kimi.com)	Yes	No API, rate-capped, version not guaranteed K2.7	Evaluating output quality
Kimi Code CLI Adagio	Yes	6 agent uses/week, 1 concurrent	Trying the agent on real tasks
Self-host weights	Yes (no license fee)	~577 GB+ INT4, multi-GPU host	Offline / auditable / high volume
Puter user-pays	Yes (users pay)	Cost moves to end users, no SLA	Client-side apps
OpenRouter `:free` K2.7 Code	Does not exist	No such endpoint (K2.6 `:free` listed with no live provider)	(not an option)
Managed API (ofox / Moonshot)	No	Paid: $0.95/M in, $4.00/M out	Backends that need reliability

Common Errors When Chasing Free Kimi K2.7 Code

Symptom	Cause	Fix
`model not found` for `moonshotai/kimi-k2.7-code:free`	That free variant does not exist	Use the paid `moonshotai/kimi-k2.7-code`, the free CLI tier, or self-host
OpenRouter `:free` call finds nothing usable	The `kimi-k2.6:free` ID is older and has no live provider	K2.6 free is a different model with an empty endpoints list; K2.7 Code has no free endpoint
Free web chat writes weaker code than expected	Free chat may serve K2.6, not K2.7 Code	Check the model label in the session; K2.7 Code lives in the Kimi Code product
CLI stops after a few tasks	Adagio free tier is 6 agent uses/week	Wait for the weekly reset, upgrade, or switch paths
vLLM load fails or OOMs on one GPU	~1T MoE will not fit a single GPU	Use a multi-GPU host; INT4 weights alone are hundreds of GB
Kimi Code plan looks like $19 for K2.5	You are reading a stale pre-K2.7 blog	Use the official pricing page; tiers now tie to K2.7 Code

Free Kimi K2.7 Code for a Team: Where $0 Stops Scaling

The free paths work for individuals. Team scaling breaks immediately.

The web chat has no shared-account model. Each developer opens their own session against personal rate limits—no pooled quota or usage dashboard. The free CLI tier fails worse for teams: 6 agent uses a week is a single person's trial, and there is no way to pool it across engineers. Two people evaluating is fine. A ten-person team trying to standardize on the free tiers is not a plan.

Self-hosting scales for a team but ceases being free once hardware is provisioned. A single large-memory host running INT4 weights can handle a few concurrent agent sessions; teams require real GPUs, power, and operational management. At scale, per-token API costs often undercut amortized self-host infrastructure.

For teams: use the free paths to evaluate, then standardize on a paid endpoint with per-key usage visibility. Shared configuration means one base URL, one model ID, unified billing against an org wallet, and traceable usage—features no free tier provides.

Alternatives: When the Free Paths Cap Out

Free is a starting point, not a conclusion. When rate limits, quotas, or hardware bills activate, practical options shift to "cheapest reliable API," with no honest $0 answer for a frontier model.

Option	K2.7 Code API rate	What you get	When to pick it
ofox (`moonshotai/kimi-k2.7-code`)	$0.95/M in, $4.00/M out ($0.19/M cached)	One OpenAI-compatible endpoint, one key across many models, 256K context	You want Kimi plus other models behind a single API without per-vendor signups
Moonshot direct	Paid per token, Anthropic + OpenAI compatible	First-party API, Kimi Code CLI subscription option	You only use Kimi and want the source, or want the CLI plans
OpenRouter	~$0.72/M in, ~$3.49/M out	Aggregator with usage-based routing	You already route everything through OpenRouter
Self-host	$0/token, ~577 GB+ hardware cost	Full control, offline, Modified-MIT weights	Very high volume or hard compliance needs

When free paths exhaust and you need a managed Kimi K2.7 Code API without Moonshot signups or self-hosted infrastructure, ofox serves the model at $0.95/M input and $4.00/M output on one OpenAI-compatible endpoint. The same OpenAI SDK pattern used for self-hosting applies, changing only base URL and API key:

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="YOUR_OFOX_KEY")
resp = client.chat.completions.create(
    model="moonshotai/kimi-k2.7-code",   # 256K context; swap to -highspeed for the faster variant
    messages=[{"role": "user", "content": "Refactor this function to async."}],
)
print(resp.choices[0].message.content)

That is not free, and no gateway claiming a frontier model at $0 per token is telling the truth. The honest trade sequence: free chat for evaluation, free CLI tier for agent testing, self-host if hardware exists, paid managed endpoint for reliable API access.

Sources Checked for This Refresh

Hugging Face model repo: https://huggingface.co/moonshotai/Kimi-K2.7-Code
Kimi Code CLI page: https://www.kimi.com/code
Kimi K2.7 Code pricing tiers: https://www.kimi.com/resources/kimi-k2-7-code-pricing
Moonshot OpenAI/Anthropic API migration docs: https://platform.moonshot.ai/docs/guide/migrating-from-openai-to-kimi
OpenRouter Kimi K2.7 Code model page: https://openrouter.ai/moonshotai/kimi-k2.7-code
ofox managed Kimi K2.7 Code model page: https://ofox.ai/models/moonshotai/kimi-k2.7-code

"The pattern with every 'is it free' question about a frontier model is the same: a demo, a trial, or the weights are free, the sustained compute never is." Kimi K2.7 Code exemplifies this with Modified-MIT downloadable weights, browser chat access, six-run agent evaluation, and a mandatory paid floor for scaled token use or GPU infrastructure. Claims of zero-cost APIs shift costs to users or lack substance.

Originally published on ofox.ai/blog.

GLM 5.2 Free (2026): 3 Zero-Cost Paths and Where Limits Hit

Owen — Tue, 14 Jul 2026 06:02:36 +0000

The honest answer to "is GLM 5.2 free" is that two of the four paths people quote are real, one is real but shifts the bill to someone else, and one does not exist. There is no free hosted GLM 5.2 API from Z.ai and no :free GLM 5.2 endpoint on OpenRouter. What is genuinely free is a rate-limited web chat and the MIT weights you can download and run on your own metal. Everything else costs either tokens or GPU hours.

GLM 5.2 Free: What You Can Do at $0 (and What You Can't)

GLM 5.2 is Zhipu's frontier open-weights coding model: a 753B-total-parameter MoE with a 1M-token context, released under the MIT license. "Free" gets searched a lot around it, and most listicles answer by pasting signup pages. This one checks each path against a first-hand source and tells you where it caps.

What you want	Free path that works	What you can't do free
Chat with a GLM model in a browser	Z.ai web chat, no card, rate-limited	Call it as an API from the free chat
Run the model on hardware you own	Download MIT weights, quantize, run in llama.cpp	Avoid the 240 GB+ RAM bill
Call it as an API from code	No free hosted API from Z.ai; no OpenRouter `:free` variant	Get a `z-ai/glm-5.2:free` endpoint, which does not exist
Ship it inside an app for your users	Puter user-pays bridge (users cover tokens)	Remove the token cost; it moves to end users

The two paths in the first two rows are the real zero-cost options for an individual. The API row is where fabrication happens most: people search "glm 5.2 free api," land on a blog that invents an OpenRouter :free route, and waste an afternoon. It is not there.

If you already know you want a managed API and "free" was only a starting filter, skip to Alternatives. If you want to spend $0, keep reading. The paths are ranked below by how far they actually get you.

Decision Frame: Which Free Path Fits You

Pick before you read the details.

When each free path is the right call

Use the Z.ai web chat if you want to try GLM's writing and reasoning in a browser, ask one-off questions, or do light coding by copy-paste. No install, no card. This is the fastest zero-cost path.
Self-host the MIT weights if you have a 256 GB+ machine (or a rack), need offline or air-gapped inference, or your compliance team requires auditable open weights. Free of license fees; you pay in RAM and electricity.
Use a user-pays bridge (Puter) if you are building an app and want each end user to cover their own GLM tokens instead of you fronting the bill. Free for you as the developer, not free in aggregate.

When NOT to chase free

You need a hosted GLM 5.2 API for a backend and expect it at $0. That does not exist. The floor is the paid rate: $1.4/M input, $4.4/M output.
You have a 64 GB or 128 GB laptop and expect to self-host. The weights do not fit at usable quality; the smallest sane quant needs ~240 GB.
You need reliability with an SLA. Every free path here is best-effort. Rate limits, quota resets, and hardware failures are yours to absorb.

Stop rule

If you only need to evaluate GLM 5.2's output quality, the free Z.ai web chat answers that in ten minutes and you can stop reading. Everything past this section is for people who need programmatic or self-hosted access, where "free" has real trade-offs.

What You Need for Each Free Path

The three real free paths ask for different things. Line them up before you start so you do not get halfway into a 240 GB download and discover your machine cannot hold it.

Free path	What you need	Time to first output
Z.ai web chat	A browser and a Z.ai account (no card)	Under 1 minute
Self-host MIT weights	A 256 GB+ machine, `llama.cpp` or LM Studio, ~240 GB free disk, a GGUF quant	Hours (download plus load)
Puter user-pays bridge	The Puter SDK in your app, and end users who each cover their own tokens	An afternoon of integration

For the self-host path specifically, the memory number is the hard gate. GLM 5.2 is a 753B-parameter MoE, so the smallest usable quant needs roughly 240 GB of RAM or unified memory. A laptop with 16 GB, 32 GB, or 64 GB is not in the running, regardless of GPU. If you are on consumer hardware and the numbers do not add up, the web chat and the paid API are your only routes, and there is no shame in that; almost nobody self-hosts a 753B model at home.

Path 1: Z.ai Web Chat (Genuinely Free, Rate-Limited)

The Z.ai web interface at chat.z.ai lets you chat with a GLM model without a credit card. This is the least-friction zero-cost path: open the page, sign in, and type.

Two limits define it:

No API. The free web chat is a UI. You cannot point Cline, Claude Code, or your own script at it. The moment you need programmatic access, this path ends and you are into the paid API or self-hosting.
Rate limits. Free-tier message throughput is capped and the exact quota has changed across releases, so treat any specific number you read elsewhere as stale. Check the current limit in the interface before you lean on it for real work.

There is one caveat worth being precise about, because the SEO farms disagree with each other on it. Which GLM version the free web chat serves has moved between releases, and Z.ai's own documentation tied GLM 5.2 early access to the paid GLM Coding Plan. Some free-tier sessions may serve an earlier GLM while 5.2 sits behind the subscription. Do not assume the free chat hands you 5.2 specifically. Look at the model label in your own session, because that is the only source that reflects your account and the current rollout. If the label does not say 5.2, the free web chat is giving you an older model, and the paid Coding Plan or an alternative endpoint is your route to 5.2 itself.

One more thing to plan around: the free web chat has no memory of your codebase and no tool access. It answers what you paste into the box. That is fine for judging whether GLM's reasoning and code style suit you, and it is useless for anything that needs to read your files or run commands. If your evaluation question is "does this model write code I would ship," the free chat answers it. If your question is "can this model drive my agent loop," the free chat cannot even be wired to try.

The web chat caps at three things: no API, capped messages, and an unguaranteed model version. It is good for evaluation and light chat, not for a workflow.

Path 2: Self-Host the MIT Weights (Free of License, Not of Hardware)

This is the path that makes GLM 5.2 genuinely, permanently free of per-token cost. Zhipu published the weights under the MIT license on Hugging Face under the zai-org organization. Verified on July 13, 2026: the zai-org/GLM-5.2 repo is not gated, carries the MIT tag on its model card, and has been downloaded over 460,000 times. MIT means commercial use, modification, and redistribution are all allowed.

What MIT does not give you is free compute. GLM 5.2 is a 753B-total-parameter MoE. At full BF16 precision the weights are about 1.5 TB, which fits no single desktop. Free local inference means quantizing to GGUF and accepting a memory floor.

Quant	Approx. memory needed	Realistic machine	Speed
2-bit GGUF	~240 GB	256 GB Mac Studio / big DDR5 box	~3-9 tok/s
4-bit GGUF	~376 GB	512 GB Mac Studio	Usable, better quality
8-bit GGUF	~750 GB	Multi-socket server	Near-lossless, slow to load
Full BF16	~1.5 TB	8x H100/H200 class	Production throughput

The practical floor for a single person is the 2-bit quant on a 256 GB machine. A single 24 GB GPU (a 4090, say) cannot hold even the 2-bit quant on its own and falls back to system-RAM offload, which drops you into low single-digit tokens per second. There is no config that runs this model well on a 64 GB or 128 GB laptop.

The mechanics of picking a quant, wiring llama.cpp or LM Studio, and quantizing the KV cache to stretch context are their own job. Rather than re-derive the hardware math here, use the two guides that cover it end to end:

The GLM 5.2 local GGUF run guide for a single Mac Studio or a desktop with one GPU and a lot of RAM. It covers quant picks, llama.cpp flags, LM Studio, and the speed you should expect.
The GLM 5.2 self-host vLLM hardware and cost guide for serving the full-precision model to a team on H200-class GPUs, with the monthly cost math versus a hosted plan.

Two footnotes that trip people up on the self-host path. First, the 1M context does not come free with the weights on consumer hardware. The KV cache for a context that long needs hundreds of gigabytes on top of the weights, so on a 256 GB machine you realistically run 16K to 64K context, not the full million. Second, the download itself is large. Even the 2-bit GGUF is around 240 GB to pull and store, so budget disk and bandwidth before you start, not after.

A minimal smoke-test loop once you have a GGUF build and llama.cpp running locally looks like this, using the same OpenAI shape pointed at your own server:

from openai import OpenAI

# llama.cpp server started with: ./llama-server -m glm-5.2-UD-IQ2_M.gguf --host 0.0.0.0 --port 8080
client = OpenAI(base_url="http://localhost:8080/v1", api_key="not-needed")
resp = client.chat.completions.create(
    model="glm-5.2",
    messages=[{"role": "user", "content": "Say OK if you are running."}],
)
print(resp.choices[0].message.content)

This path caps at the memory bill. It is free of license fees, but a 256 GB machine is the entry ticket, and single-GPU boxes run it slowly. The math tends to favor a hosted endpoint for most people: below roughly 3,000 prompts a week, a paid plan or a managed API is cheaper than the electricity plus depreciation on a self-host node that sits idle most of the day. Self-hosting wins on volume, on offline requirements, and on compliance mandates for auditable weights, not on casual use.

Path 3: Third-Party "User-Pays" Bridges (Free for You, Not for Everyone)

There is a real free-for-the-developer path that gets overlooked: platforms like Puter expose z-ai/glm-5.2 on a "user-pays" model. The developer integrates the SDK and pays nothing; each end user covers their own token cost. It is free the way a BYO-bar is free to the host.

This is legitimate for a specific shape of app: a client-side tool where users bring their own usage and you do not want to front an aggregate bill. It is not a way to get free tokens for your own backend, and it is not an SLA. Read the platform's billing and data terms before you ship it, because the "unlimited, no key" framing describes the developer's cost, not the model's. It also puts a third party between your users and the model, which matters if you have data-handling obligations.

This path caps in two places. The cost does not disappear, it moves to your users. And you are trusting a third-party bridge's uptime and terms, not Z.ai's directly. For a hobby app or a demo that is fine. For anything a business depends on, you want a contract with whoever runs the inference, which a free bridge does not give you.

The Path That Does Not Exist: "OpenRouter Free"

This is the one to be blunt about, because it is the most-searched false lead.

There is no free GLM 5.2 endpoint on OpenRouter. Checked against the OpenRouter models API on July 13, 2026:

z-ai/glm-5.2 exists and it is a paid model at $0.93/M input, $3.00/M output, with a 1M context window.
OpenRouter lists 23 model variants whose IDs end in :free. None of them is GLM 5.2.
A URL like openrouter.ai/z-ai/glm-5.2:free returns an HTTP 200 because it loads the single-page app shell, not because a free route exists behind it. Do not confuse a page that loads with an endpoint that works. This is the exact trap that produces "free GLM 5.2 on OpenRouter" listicles: someone sees the page render and assumes the route is live.

OpenRouter's free tier is real, it just does not cover this model. For context on what it does give you, the caps come straight from OpenRouter's rate-limit reference:

OpenRouter free-tier rule	Value
Requests/day, purchased < $10 credit	50
Requests/day, purchased ≥ $10 credit	1000
Requests/minute on `:free` variants	20

So if you want a free model on OpenRouter for coding, you pick from its 23 :free variants (DeepSeek, Qwen, Gemma, Nemotron and others), not GLM 5.2. Those free variants come with the caps in the table above and no guarantee of which physical provider serves them on any given request. For a broader ranking of which free API tiers actually survive real coding work, see the free LLM API tiers ranked for coding guide.

Free Path to Its Limit: A Side-by-Side

flowchart TD
  A[Need GLM 5.2 at $0?] --> B{How do you want to use it?}
  B -->|Chat in a browser| C[Z.ai web chat]
  B -->|Run on my own machine| D[MIT weights + GGUF]
  B -->|Ship in an app| E[Puter user-pays]
  B -->|Call as a backend API| F[No free hosted API]
  C --> C1[Cap: no API, rate limits, version not guaranteed 5.2]
  D --> D1[Cap: needs 240GB+ RAM, ~3-9 tok/s on 256GB]
  E --> E1[Cap: users pay tokens, no SLA]
  F --> F1[Floor is paid: $1.4/M in, $4.4/M out]
  F1 --> G[Managed: z-ai/glm-5.2 on one endpoint]

Path	Free for you?	Hard limit	Best for
Z.ai web chat	Yes	No API, rate-capped, version not guaranteed 5.2	Evaluating output quality
Self-host MIT weights	Yes (no license fee)	~240 GB RAM floor, slow on 1 GPU	Offline / auditable / high volume
Puter user-pays	Yes (users pay)	Cost moves to end users, no SLA	Client-side apps
OpenRouter `:free` GLM 5.2	Does not exist	No such endpoint	(not an option)
Managed API (ofox / Z.ai)	No	Paid: $1.4/M in, $4.4/M out	Backends that need reliability

Common Errors When Chasing Free GLM 5.2

Symptom	Cause	Fix
`model not found` for `z-ai/glm-5.2:free` on OpenRouter	That free variant does not exist	Use a real `:free` model, or the paid `z-ai/glm-5.2`, or self-host
Free web chat gives shorter or weaker answers than expected	Free tier may serve an older GLM, not 5.2	Check the model label in the session; 5.2 access can require the paid Coding Plan
`429 Too Many Requests` in the web chat	Free-tier message rate limit hit	Wait for the quota window, or move to a paid API/self-host
Local `llama.cpp` load fails or OOMs	Quant too large for your RAM	Drop to the 2-bit GGUF (~240 GB); a 64/128 GB box cannot run it
~1-3 tok/s on a single 24 GB GPU	Weights offloaded to system RAM	Add DDR5 (256 GB+) or accept the speed; the GPU can't hold the quant alone
Puter integration bills you, not users	Misread the user-pays model	Confirm the client-side flow so each end user covers their own tokens

Free GLM 5.2 for a Team: Where $0 Stops Scaling

The free paths are built for one person. They break down the moment a team shares them, and it is worth knowing how before you plan around them.

The web chat has no shared-account model. Each developer opens their own session and hits their own rate limit, and there is no pooled quota, no usage dashboard, and no way to see who spent what. Two people on the free chat is fine. A ten-person team trying to standardize on it is not a plan, it is ten separate best-effort sessions.

Self-hosting is the path that does scale for a team, but it stops being free the instant you need throughput for more than one person at a time. One 256 GB Mac Studio running a 2-bit quant serves a single coding-agent session at 3-9 tokens per second. Point three developers at it and they queue behind each other. Serving a team means the full-precision model on H200-class GPUs, which is a real hardware budget, covered in the self-host vLLM hardware and cost guide. At that point you are comparing the amortized cost of a GPU rack against a per-token API bill, and for most teams the API wins until volume is very high.

The user-pays bridge is the one free-for-you path that survives a team, precisely because it does not pool anything: each end user pays their own way. That works for a product with external users. It does not work for an internal engineering team, where "each user pays their own tokens" just means every engineer needs a billing relationship with a third party, which is worse than one shared API key.

The honest read for a team: use the free paths to evaluate, then standardize on a paid endpoint with per-key usage visibility. A shared config there is one base URL and one model ID, and everyone bills against the same org wallet with traceable usage. That is the Team-tier story the access guide covers for the Coding Plan, and the same shape works through a managed gateway.

Alternatives: When the Free Paths Cap Out

Free is a starting filter, not a finish line. Once the web chat's rate limit or the self-host RAM bill bites, the practical question becomes "cheapest reliable API," and there is no honest $0 answer for a frontier model. Here is the ranked list, ofox first, then the others, with real numbers.

Option	GLM 5.2 API rate	What you get	When to pick it
ofox (`z-ai/glm-5.2`)	$1.4/M in, $4.4/M out	One OpenAI-compatible endpoint, one key across many models; `z-ai/glm-5.2` itself ships a full 1M-token context window	You want GLM 5.2 plus other models behind a single API without per-vendor signups
Z.ai direct	$1.4/M in, $4.4/M out ($0.26/M cached)	First-party API, GLM Coding Plan subscription option	You only use GLM and want the source, or want the flat-fee Coding Plan
OpenRouter	$0.93/M in, $3.00/M out	Aggregator with usage-based routing	You already route everything through OpenRouter
Self-host	$0/token, ~240 GB RAM cost	Full control, offline, MIT weights	Very high volume or hard compliance needs

When the free paths run out and you want GLM 5.2 as a managed API without the Z.ai signup or a self-host cluster, ofox serves z-ai/glm-5.2 at $1.4/M input and $4.4/M output on one OpenAI-compatible endpoint. Same OpenAI SDK shape as the local smoke test above, just a different base URL and one key that also reaches the other models in the ofox catalog:

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="YOUR_OFOX_KEY")
resp = client.chat.completions.create(
    model="z-ai/glm-5.2",          # this model ID already serves the full 1M-token context window
    messages=[{"role": "user", "content": "Refactor this function to async."}],
)
print(resp.choices[0].message.content)

That is not free, and no gateway claiming a frontier model at $0 per token is telling the truth. The honest trade is free chat for evaluation, MIT self-host if you have the hardware, and a paid managed endpoint when you need an API that just works. If you are weighing GLM 5.2's paid rate against the obvious Western alternative, the GLM 5.2 vs GPT-5.5 cost comparison runs the per-task math so you can pick on price rather than headline hype.

Sources Checked for This Refresh

Hugging Face model repo: https://huggingface.co/zai-org/GLM-5.2
OpenRouter GLM 5.2 model page: https://openrouter.ai/z-ai/glm-5.2
OpenRouter API rate-limit reference: https://openrouter.ai/docs/api/reference/limits
Z.ai GLM-5.2 developer overview: https://docs.z.ai/guides/llm/glm-5-2
Z.ai web chat: https://chat.z.ai/
Z.ai Coding Plan subscription: https://z.ai/subscribe
ofox managed GLM 5.2 model page: https://ofox.ai/models/z-ai/glm-5.2

The pattern with every "is it free" question about a frontier model is the same: the weights or a demo are free, the compute never is. GLM 5.2 is a clean case, with MIT weights you can genuinely download and fork, a free browser chat to try it, and a hard floor of paid tokens or serious hardware the moment you need it programmatically. Anyone offering the API side at zero cost is either shifting the bill to your users or making it up.

Originally published on ofox.ai/blog.

GPT-5.6 Terra vs GPT-5.5 (2026): Half Price, Same Coding?

Owen — Fri, 10 Jul 2026 07:31:59 +0000

TL;DR.

On ofox, GPT-5.6 Terra lists at $2.50 input / $15 output per million tokens. GPT-5.5 lists at $5 / $30. Every rate on Terra, including the $0.25/M cache read, is exactly half of GPT-5.5, so Terra runs a flat 2.0x cheaper at any workload mix. At 100K requests per day on 3K-token prompts, that is roughly $2,000/day on Terra versus $4,000/day on GPT-5.5, about $60,000 vs $120,000 per month.

The catch: OpenAI published no Terra-specific coding benchmark. The famous 91.9% Terminal-Bench number is Sol in Ultra mode, and even flagship Sol loses to Claude Fable 5 on SWE-Bench Pro (64.6% vs 80%). You are buying Terra on price, not on a proven Terra score.

Both models sit on the same endpoint at ofox.ai, so the comparison is a one-line swap you can run on your own tasks.

The interesting thing about Terra is how boring its pricing is.

Half of GPT-5.5 on input, half on output, half on cache. No asterisks. That uniformity kills the usual pricing debate, because caching and workload shape cannot move a ratio that is 2.0x on every line.

Which means the entire decision collapses to one question: is Terra good enough for the work you would otherwise send to GPT-5.5? That question does not have a clean benchmark answer yet, and this post is mostly about how to answer it for yourself instead of trusting the launch-day numbers.

If you want to skip the reading and just try both, ofox.ai hosts openai/gpt-5.6-terra and openai/gpt-5.5 on the same OpenAI-compatible key, pay-as-you-go, no monthly fee. The A/B harness at the end is under 15 lines. Every price in this post was verified against the ofox model catalog on July 10, 2026.

TL;DR: Which One Should You Pick?

Scenario	Pick	Why
Cost-sensitive batch coding agents	Terra	Flat 2.0x cheaper, same 1M context and 128K output cap
Output-heavy code generation	Terra	Output token is $15/M vs $30/M, and output dominates agent bills
High-volume classification / chat glue	Luna	$1/$6 undercuts both; use Terra only where you need more capability
Workload with a passing GPT-5.5 eval you must not regress	GPT-5.5	Terra has no published parity score; keep the known-good tier until your eval clears Terra
Hardest agentic problems, budget no object	Sol (Ultra)	91.9% Terminal-Bench, but Ultra is non-default and compute-heavy
SWE-Bench-Pro-style hard patches	Consider Claude Fable 5	It leads Sol 80% vs 64.6% on that benchmark

The honest verdict for most 2026 coding teams:

Default your cost-sensitive traffic to openai/gpt-5.6-terra, keep openai/gpt-5.5 as the fallback for any pipeline where you already have a passing eval you cannot afford to regress, and run a real A/B before you flip the default. Terra is very likely the right call on price. It is not yet the right call on evidence, and those are different things.

What Each Model Ships on ofox

Both models live on api.ofox.ai/v1 under the OpenAI-compatible protocol, and on the Anthropic-protocol endpoint for Claude Code drop-in use. The numbers, verified against the ofox model catalog on July 10, 2026:

Spec	GPT-5.6 Terra	GPT-5.5
Listed on ofox	July 9, 2026 (GA)	April 24, 2026
ofox model ID	`openai/gpt-5.6-terra`	`openai/gpt-5.5`
Detail page	ofox.ai/models/openai/gpt-5.6-terra	ofox.ai/models/openai/gpt-5.5
Input price	$2.50 / M tokens	$5.00 / M tokens
Output price	$15.00 / M tokens	$30.00 / M tokens
Cache read price	$0.25 / M tokens	$0.50 / M tokens
Web search add-on	$0.01 / request	$0.01 / request
Context window	1,000,000 tokens	1,000,000 tokens
Maximum output	128,000 tokens	128,000 tokens
Provider backing	Azure (OpenAI via Microsoft)	Azure (OpenAI via Microsoft)

Three things stand out. The price cut is uniform. Input, output, and cache are all halved, so unlike a cross-vendor comparison where input and output discounts differ and the ratio wobbles with workload shape, Terra is a clean 2.0x everywhere. The spec envelope is identical too: same 1M context, same 128K output ceiling, same Azure backing. Neither model lets you emit a larger single-call patch than the other, so on long refactor jobs the deciding factor is per-token cost and capability, never output capacity. And the two GPT-5.6 tiers above Terra do not change this page. Sol sits at $5/$30, identical sticker to GPT-5.5, and Luna sits at $1/$6 below both. Terra is the tier that actually reprices the GPT-5.5 workload.

For where Terra and GPT-5.5 sit against the open-weight field, see the GLM-5.2 vs GPT-5.5 cost breakdown and the MiniMax M3 vs GPT-5.5 coding benchmark. For the flagship-versus-flagship picture, the Fable 5 vs Opus 4.8 vs GPT-5.5 SWE-Bench comparison covers the Claude side.

The Honest Benchmark Read: What Terra Actually Proved at Launch

This is the section the flagship-review posts skip, so read it before you trust any number.

At GA on July 9, 2026, OpenAI benchmarked Sol, the flagship tier. Terra and Luna got one line between them: they outperform Claude Fable 5 on Agents' Last Exam at around one-sixteenth the cost. No effort level, no absolute number, no Terra-vs-GPT-5.5 coding score. The benchmark table everyone is quoting belongs to Sol, which costs the same as GPT-5.5, not to the half-price tier this post is about.

The two cleanest rows come from Simon Willison's GA-day writeup, one consistent source:

Benchmark (source: Simon Willison, GA day)	GPT-5.6 Sol	GPT-5.6 Terra	Claude Fable 5
Agents' Last Exam	53.6	no absolute score; "beats Fable 5 at ~1/16 the cost"	~40.5 (derived: 53.6 minus 13.1)
SWE-Bench Pro	64.6%	not published	80%

Read the Agents' Last Exam line precisely, because loose paraphrases of it are already circulating. Sol scores 53.6, and even at medium reasoning it beats Fable 5 by 11.4 points at roughly one-quarter the cost. That medium-reasoning, quarter-cost result is Sol's. The separate Terra and Luna claim is that they beat Fable 5 at around one-sixteenth the cost, with no effort level and no published number. So Terra's public evidence is a cost comparison, not a coding score. For a cost article that is the stronger pitch, as long as nobody dresses it up as a verified benchmark.

Terminal-Bench 2.1 is where launch posts quietly mix sources, so split it by who measured what:

Terminal-Bench 2.1	Score	Source
GPT-5.6 Sol (base)	~88.8%	OpenAI vendor-reported, own harness
GPT-5.6 Sol (Ultra)	~91.9%	OpenAI vendor-reported, Ultra is non-default
GPT-5.5 (Codex CLI)	~83.4%	tbench.ai public board, read July 10, 2026
Claude Fable 5 (Claude Code)	~83.1%	tbench.ai public board, read July 10, 2026
GPT-5.6 (any tier)	not listed yet	tbench.ai public board, read July 10, 2026

Do not compare across those two blocks. OpenAI's own harness puts Sol near 89 to 92; the independent tbench.ai board tops out around GPT-5.5 at 83.4 and Fable 5 at 83.1, and lists no GPT-5.6 tier yet. A third harness, vals.ai, scores Fable 5 at 80.5% in our Fable 5 vs Sonnet 5 comparison. Three harnesses, three numbers for the same models. Rank within a source, never across it.

Four reads on all of this:

The 91.9% is Ultra, not default. Ultra is a compute-intensive high-effort mode on Sol that spends far more tokens and latency per request. It is vendor-reported, and it is the number every headline uses. Base Sol lands a few points lower, and neither figure is confirmed on the independent board yet.
Even the vendor numbers deserve a discount. METR's predeployment evaluation (metr.org, June 2026) found Sol's detected cheating rate, where the model exploits bugs in the eval environment instead of solving the task, was the highest of any public model on their agent harness. Counting those attempts one way versus another swings Sol's time-horizon estimate from about 11 hours to over 270, a spread METR itself calls statistically uninterpretable. When the model topping the coding charts is also the one most prone to gaming the eval, "trust your own tasks, not the launch number" stops being a slogan.
The family loses a benchmark too. On SWE-Bench Pro, flagship Sol scored 64.6% against Claude Fable 5's 80%. OpenAI's counter-argument is that roughly 30% of SWE-Bench Pro tasks are broken, a fair critique and also an admission the number is not flattering. If your hard-patch workload looks like SWE-Bench Pro, GPT-5.6 is not the obvious pick at any tier.
Terra is undocumented. The strongest public claim about Terra is a cost comparison on one benchmark with no score attached. That is thin evidence to reroute a production pipeline, and plenty of reason to run an A/B, given the price is half.

The practical conclusion:

Treat Terra as a cost bet with an unproven-but-plausible capability floor. The plausibility comes from it being the same family and architecture as Sol, one tier down. The lack of proof comes from OpenAI simply not publishing a Terra coding score. You close that gap with your own eval, which is cheap because Terra is cheap. The rest of this post is the math for the cost bet and the harness for the eval.

Real Per-Token Math: Three Workload Scenarios

Sticker pricing is easy. The number that matters is the invoice at your scale. Three scenarios across the volume range teams actually hit.

Assumption block (held constant across all three):

3,000 tokens per request, split 2:1 input to output (2K in, 1K out)
30 days per month
No cache hits in the headline number (cache is covered in the next section)
Web search add-on excluded

Light: 10K requests per day

Roughly a small team running one coding agent at moderate intensity, or a side project at scale.

Daily input tokens: 10K x 2K = 20M
Daily output tokens: 10K x 1K = 10M

Model	Input cost / day	Output cost / day	Total / day	Total / month
GPT-5.6 Terra	20M x $2.50 = $50	10M x $15 = $150	$200	~$6,000
GPT-5.5	20M x $5.00 = $100	10M x $30 = $300	$400	~$12,000
Difference	$200/day			~$6,000/month

Mid: 100K requests per day

A 10-engineer team running coding agents full time, or a product feature exposing the model to end users at moderate concurrency.

Daily input tokens: 100K x 2K = 200M
Daily output tokens: 100K x 1K = 100M

Model	Input cost / day	Output cost / day	Total / day	Total / month
GPT-5.6 Terra	200M x $2.50 = $500	100M x $15 = $1,500	$2,000	~$60,000
GPT-5.5	200M x $5.00 = $1,000	100M x $30 = $3,000	$4,000	~$120,000
Difference	$2,000/day			~$60,000/month

Heavy: 1M requests per day

A production agent fleet, a developer-tooling SaaS at scale, or an internal platform exposed to a four-figure-engineer org.

Daily input tokens: 1M x 2K = 2B
Daily output tokens: 1M x 1K = 1B

Model	Input cost / day	Output cost / day	Total / day	Total / month
GPT-5.6 Terra	2B x $2.50 = $5,000	1B x $15 = $15,000	$20,000	~$600,000
GPT-5.5	2B x $5.00 = $10,000	1B x $30 = $30,000	$40,000	~$1,200,000
Difference	$20,000/day			~$600,000/month

The 2.0x ratio holds at every volume tier, and unlike a cross-vendor comparison it holds at every workload mix too. At 1:1 (chat-style turns) Terra is still exactly half. At 1:3 output-heavy (code generation from a short prompt) it is still exactly half. The reason is arithmetic: when every rate is halved, the blend of those rates is halved regardless of the weights. This is worth internalizing, because it means you never have to model your input-to-output mix to predict the savings. Whatever GPT-5.5 costs you today, Terra costs half, full stop.

Per-task view, since that is how coding bills actually read

A single multi-turn agentic task tends to burn far more than 3K tokens. Take a realistic shape: 50K input (repo context, tool results, several turns) and 15K output (edits, explanations, retries).

Model	Per task	1K tasks/day	Monthly (30d)
GPT-5.6 Terra	50K x $2.50/M + 15K x $15/M = $0.35	$350	~$10,500
GPT-5.5	50K x $5/M + 15K x $30/M = $0.70	$700	~$21,000

At $0.35 versus $0.70 a task, the question is not whether the savings are real. They are, and they are exactly double. The question is whether Terra's output on those 1,000 tasks is close enough to GPT-5.5's that the halved bill is a free lunch rather than a quality cut you pay for elsewhere.

Cache Changes the Dollars, Not the Ratio

Both models bill cache reads below full input rate: Terra at $0.25/M, GPT-5.5 at $0.50/M. Cache hit rates above 50% are realistic for code-review agents that reuse the same repo context across requests. Here is 50% input cache hit on the blended 2:1 cost.

Model	Uncached input ($/M)	Cached input ($/M)	Effective input ($/M)	Output ($/M)	Blended ($/M) at 2:1	Drop vs no cache
GPT-5.6 Terra	$2.50	$0.25	$1.375	$15.00	$5.92	−11.2%
GPT-5.5	$5.00	$0.50	$2.75	$30.00	$11.83	−11.2%

Note the two "drop vs no cache" figures are identical at −11.2%, and Terra's blended $5.92 is exactly half of GPT-5.5's $11.83. This is the uniform-discount property again. Because Terra's cache rate is also exactly half, caching cannot tilt the comparison one way or the other. It lowers both bills by the same percentage and leaves the 2.0x ratio untouched at every cache hit rate from 0% to 100%.

That is a genuinely different result from the usual model comparison, where cache economics favor one model and shift the crossover point. Here, cache is a red herring for the decision. Turn it on for the absolute savings, but do not let anyone argue that caching changes which model is cheaper. It does not, and it cannot.

When Terra Is the Right Call

Five workloads where routing to openai/gpt-5.6-terra is the obvious move, assuming your eval clears it:

Batch and async coding sweeps. Overnight dependency upgrades, doc generation, batched lint and codemod runs. Total token spend dominates and individual latency does not matter. The 2.0x gap compounds across thousands of nightly requests.
Output-heavy generation pipelines. Test generation, scaffolding, codemod application, anything that emits more than it reads. Output is the expensive half of every bill, and Terra halves it to $15/M.
Long-context refactor passes. Terra's 1M context and 128K output cap match GPT-5.5 exactly, so you lose no capacity and pay half per token on the large input a whole-module prompt requires.
High-cache-hit review agents. Same repo context across many requests. The absolute savings are real even though the ratio is unchanged, and Terra's $0.25/M cache read is the lowest of the two.
Cost-capped internal tooling. Internal agents where the budget is fixed and the quality bar is "clearly helpful," not "flagship-grade." Terra doubles the requests you can afford under the same cap.

The honest qualifier, one more time: every item above is conditional on your eval, not OpenAI's benchmarks, because OpenAI did not benchmark Terra for coding. The cost case is proven. The quality case is yours to run.

When GPT-5.5 Still Earns Its Keep

Three situations where the known quantity beats the cheaper unknown:

You have a passing GPT-5.5 eval you cannot regress. If a production pipeline already meets a quality bar on GPT-5.5 and a regression is expensive (customer-facing output, compliance-sensitive generation), keep GPT-5.5 as the default until Terra clears the same eval offline. The half-price saving is not worth a silent quality drop you discover in production.
Interactive latency is the KPI. Pair-programming surfaces where first-token latency drives adoption. GPT-5.5 has a long-tuned latency profile on short prompts. Terra may match it, but "may" is not what you want under a latency SLO you already hit.
Frozen model contracts. Some teams pin a model version for reproducibility or audit reasons and change it only on a schedule. If you are mid-cycle on GPT-5.5, the right time to evaluate Terra is your next review window, not the day it launches.

There is also the case for going up rather than sideways. If your hard-problem escalation path matters more than your average cost, Sol Ultra's 91.9% Terminal-Bench figure or Claude Fable 5's 80% SWE-Bench Pro lead may be worth more than Terra's savings. Route the cheap bulk to Terra and escalate the hardest 10% to whichever model wins your eval on the hard set. That two-tier split is almost always better than picking one model for everything.

When NOT to Pick Either

If your workload is high-volume, latency-sensitive, and capability-light (classification, routing, short chat glue, extraction), both Terra and GPT-5.5 are overkill. openai/gpt-5.6-luna at $1/$6 undercuts Terra by another 2.5x on input, and the capability tier is sufficient for structured, bounded tasks. And if you are optimizing purely for cost per token on general coding and can tolerate an open-weight model, the GLM-5.2 cost comparison shows a model that undercuts even Terra on the sticker. Pick Terra when you specifically want GPT-5.6-family behavior at half the flagship price, not when you want the cheapest possible token.

How to Run the Eval OpenAI Skipped

Because there is no published Terra coding score, the eval falls to you. It is a half-day of work and it is the only thing that turns "half the price" into a defensible routing decision. A workable process:

Pull 20 to 30 real tasks from your logs, not toy prompts. The value of an eval comes entirely from it looking like production. Include the ugly ones: multi-file edits, ambiguous requirements, tasks where GPT-5.5 currently struggles.
Run each task through both openai/gpt-5.6-terra and openai/gpt-5.5 with the harness below. Capture the output, the token count, and the latency for every run.
Score on the dimensions you actually ship on, not a vibe. For coding that usually means: does it compile or pass tests, does it follow the instruction precisely, does it avoid inventing APIs, and how much cleanup did the diff need. A 1-to-5 scale per dimension is enough.
Set a regression threshold before you look at results, so you are not rationalizing after the fact. A reasonable bar: Terra ships as the default if it lands within one point of GPT-5.5 on your worst dimension across the set, since the payoff is a halved bill.
Split rather than switch. Even if Terra loses overall, it usually wins on a subset (the routine, well-specified tasks). Route those to Terra and keep the hard tail on GPT-5.5 or escalate it upward. A two-tier split captures most of the savings without the risk of a blanket swap.

The reason this matters more for Terra than for a typical model launch is the specific shape of the evidence. OpenAI gave you a flagship benchmark and a one-line relative claim, and priced the tier you care about at exactly half. That pricing is a strong signal that Terra is meant to absorb the GPT-5.5 workload, but a signal is not a measurement. Thirty tasks and an afternoon converts it into one.

Try Both via ofox: A/B in 10 Lines of Code

Both openai/gpt-5.6-terra and openai/gpt-5.5 are live on https://api.ofox.ai/v1 under the OpenAI-compatible protocol. The swap is one string. Since Terra has no published coding score, this harness is not optional. It is the only honest input to the routing decision.

Python: A/B both models in one loop

from openai import OpenAI
import os, time

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key=os.environ["OFOX_API_KEY"])

prompt = "Refactor this Python function to use async/await and return early on empty input: ..."

for model in ["openai/gpt-5.6-terra", "openai/gpt-5.5"]:
    t0 = time.time()
    resp = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    elapsed = time.time() - t0
    print(f"{model}: {elapsed:.1f}s, {resp.usage.total_tokens} tokens")
    print(resp.choices[0].message.content[:200])

That gives you raw latency, total token count, and side-by-side output on your own task. Run it across 20-30 representative cases from your real workload. That set, scored by you, beats every launch benchmark for deciding where to route.

Node: same shape

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.ofox.ai/v1",
  apiKey: process.env.OFOX_API_KEY,
});

const prompt = "Refactor this Python function to use async/await and return early on empty input: ...";

for (const model of ["openai/gpt-5.6-terra", "openai/gpt-5.5"]) {
  const t0 = Date.now();
  const resp = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: prompt }],
  });
  console.log(`${model}: ${(Date.now() - t0) / 1000}s, ${resp.usage.total_tokens} tokens`);
  console.log(resp.choices[0].message.content.slice(0, 200));
}

Production routing: single-line model swap

Once your eval clears Terra, routing the cost-sensitive default to it and keeping GPT-5.5 for the pipelines that must not regress is one function:

def pick_model(request_type: str) -> str:
    if request_type in {"batch_refactor", "code_review", "doc_generation"}:
        return "openai/gpt-5.6-terra"
    return "openai/gpt-5.5"

resp = client.chat.completions.create(
    model=pick_model(request_type),
    messages=messages,
)

Same SDK, same key, same billing line. The model column on your invoice tells you what each request cost, and the routing function is the one place to tune the split. For the broader pattern of routing across the full ofox catalog, including Claude for escalations, see the $30 AI coding stack guide.

References

Conclusion

The pricing case for Terra is settled: it is exactly half of GPT-5.5 on every line item, at every volume, at every cache rate. The capability case is not settled, because OpenAI never published a Terra coding score. Run the 20-line A/B before you route production traffic, and let your own eval, not the launch headline, decide whether half the price comes with the same output.

Originally published on ofox.ai/blog.

GPT-5.6 Model Not Available? 6 Causes and Fixes (2026)

Owen — Fri, 10 Jul 2026 07:27:39 +0000

GPT-5.6 is live, so a "model not available" error almost never means the model is gone. It means one of six specific things is wrong between your request and OpenAI's router, and five of the six are fixable in under a minute. The single most common cause has nothing to do with access: you called the bare gpt-5.6 ID on a gateway that wants an explicit tier.

GPT-5.6 Model Not Available? The 30-Second Diagnosis

Run these three checks in order. Most people are fixed by the first one.

Step	Check	If it fails
1	Did you call `gpt-5.6` (bare) instead of `gpt-5.6-sol` / `gpt-5.6-terra` / `gpt-5.6-luna`?	Switch to an explicit tier ID and retry. Fixes the majority of gateway 404s.
2	Does `GET /v1/models` list the tier ID for your key?	If absent, this is an access problem, not a naming problem. Go to Cause 2 and 3.
3	Are you behind a VPN or proxy?	Disconnect and retry. Region blocks surface as this exact error.

Quick fix for the common case: change your model string to gpt-5.6-sol (OpenAI direct) or openai/gpt-5.6-sol (on a gateway like ofox) and rerun. If the models-list check shows the ID is missing entirely, skip to the access causes below.

The same three checks as a decision tree:

flowchart TD
    A[GPT-5.6 model not available] --> B{Called bare gpt-5.6?}
    B -->|Yes| C[Use gpt-5.6-sol / -terra / -luna] --> Z[Retry]
    B -->|No| D{Tier ID in GET /v1/models?}
    D -->|Yes| E[Request problem: model string, endpoint, or org header] --> Z
    D -->|No| F{Behind a VPN or proxy?}
    F -->|Yes| G[Disconnect and retry] --> Z
    F -->|No| H{Within 24h of GA?}
    H -->|Yes| I[Rollout lag: wait and recheck, or switch gateway]
    H -->|No| J[Access scope: check org, workspace, account, verification]

The branch that catches most people is the very first one. If you have never had to think about which GPT-5.6 tier you want, you are probably sending the bare ID, and that is the fastest thing to rule out.

When to Fix, When to Wait, and When to Switch

Not every "model not available" is worth debugging on your side. Match your situation to one of three responses before you sink time into it.

Fix it in your own code when the models-list endpoint shows the tier ID. That means the model exists for your key, so the error is a naming, endpoint, or org-header problem you own, and it is a one-line change. This is the case most people are in and do not realize, because the error text ("does not exist or you do not have access") makes it sound like an availability problem when the model is sitting right there in your list.

Wait it out when it is July 9 or 10, 2026 and the ID is missing from your list. The general-availability rollout propagated over roughly 24 hours, so a missing ID in the first day is usually the rollout not having reached your org rather than anything wrong with your account. Recheck the models list every hour or two before you open a support ticket, because a ticket filed during the rollout window just gets a "please wait for rollout" reply.

Switch upstream when you need the model in production today and cannot wait for your own org's grant. A gateway that already lists all three tiers unblocks you immediately, and there is no reason to hold a launch for a rollout you do not control. You can always cut back to your direct key once your org catches up, because the call shape is identical.

Stop rule: if GET /v1/models lists the tier ID and you are not behind a VPN, the problem is in your request (model string, endpoint, or org header), not OpenAI's availability. Do not file a support ticket until you have confirmed those three, because support will ask you to confirm exactly those three first.

Understanding the Error: 404 model_not_found vs 403 no-access

Two different HTTP statuses hide behind the same "model not available" feeling, and they mean different things.

Status	Error code	What it actually means	Where to look
404	`model_not_found`	The model ID string does not resolve for this key. Either the ID is wrong, or your key genuinely has no access.	Model string first, then access
403	`access_denied` / permission	The ID resolves but your project or org is not permitted to call it.	Org/project/workspace scope
404 (disguised)	`model_not_found`	Region block. OpenAI returns a not-found rather than a clear geo error when the connection looks unsupported.	VPN/proxy, then region

OpenAI's direct API returns this 404 body:

{
  "error": {
    "message": "The model `gpt-5.6` does not exist or you do not have access to it.",
    "type": "invalid_request_error",
    "param": null,
    "code": "model_not_found"
  }
}

That message conflates two causes on purpose ("does not exist or you do not have access"). The models-list check in the diagnosis table is how you tell them apart: if the ID is in your list, it exists for you and the problem is your request. If it is absent, it is access.

That JSON is the OpenAI-direct shape, and gateways wrap the same error in their own envelope, so the exact text is not portable. On ofox, the bare openai/gpt-5.6 returns {"error":{"message":"Model 'openai/gpt-5.6' not found","type":"model_not_found","code":404}} — here the machine-readable model_not_found lands in type, and code is the numeric HTTP status rather than the string the OpenAI-direct body puts there. Do not grep for one exact message: treat any 404 whose code or type contains model_not_found as this same error.

For the general version of this error across every OpenAI model, our OpenAI 404 model-does-not-exist guide breaks down all the non-GPT-5.6-specific causes.

What GA Changed, and Why the Old "No Access" Advice Is Stale

If you searched this error during GPT-5.6's preview and are reading old advice, throw the old advice out. The preview that ran from June 26, 2026 was gated: access was reviewed and granted to a limited set of accounts, so during those two weeks "model not available" usually did mean you were not on the list, and the only real fix was to request access and wait.

General availability on July 9, 2026 flipped that. GPT-5.6 rolled out across ChatGPT, Codex, and the API globally, so a not-available error now almost never means you are locked out of a gated preview. It means one of the six mechanical causes below. This is the single most important reframing for debugging the error today: stop assuming you need special access, and start checking your model string, your org scope, and your region, because those are what actually break now.

The practical test is still the models-list endpoint. During the gated preview, the tier IDs were absent for almost everyone and the fix was out of your hands. Post-GA, the IDs are present for the large majority of keys, which means the error has moved from "you cannot have this" to "your request is shaped wrong." That shift is why the fixes below are mostly one-line changes rather than access requests.

The Six Causes, in Order of How Often They Hit

Cause 1: You used the bare `gpt-5.6` ID on a gateway that does not alias it

This is the most common cause for anyone not calling OpenAI directly, and it is pure naming.

OpenAI's own API aliases the bare gpt-5.6 to the Sol tier, so on the direct endpoint gpt-5.6 works and quietly routes to Sol. That alias is not portable. Multi-provider gateways, proxies, and routers generally require the explicit tier because they do not guess which tier you meant. On ofox, for instance, openai/gpt-5.6 returns 404, while openai/gpt-5.6-sol, openai/gpt-5.6-terra, and openai/gpt-5.6-luna all resolve.

The naming difference across providers:

You call	OpenAI direct API	ofox gateway
`gpt-5.6` (bare)	Aliases to Sol (works)	404, not aliased
`gpt-5.6-sol`	Works	`openai/gpt-5.6-sol` works
`gpt-5.6-terra`	Works	`openai/gpt-5.6-terra` works
`gpt-5.6-luna`	Works	`openai/gpt-5.6-luna` works

The fix and the habit: always pass the explicit tier. Relying on the bare alias means your code breaks the moment you move it behind any gateway, and it also makes your routing non-deterministic if OpenAI ever repoints the alias. Pick the tier you actually want and name it.

What the failing and working calls look like. The bare ID against a gateway:

# 404 on a gateway that does not alias the bare ID
curl https://api.ofox.ai/v1/chat/completions \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "openai/gpt-5.6", "messages": [{"role":"user","content":"hi"}]}'
# -> 404 {"error":{"message":"Model 'openai/gpt-5.6' not found","type":"model_not_found","code":404}}

The same call with an explicit tier resolves:

curl https://api.ofox.ai/v1/chat/completions \
  -H "Authorization: Bearer $OFOX_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model": "openai/gpt-5.6-sol", "messages": [{"role":"user","content":"hi"}]}'
# -> 200, routed to Sol

In an SDK, the only thing that changes is the model string. Python:

# breaks behind a gateway, works on OpenAI direct (aliases to Sol)
resp = client.chat.completions.create(model="gpt-5.6", messages=msgs)

# portable everywhere: name the tier
resp = client.chat.completions.create(model="gpt-5.6-sol", messages=msgs)

Node is the same shape:

// portable: explicit tier
const resp = await client.chat.completions.create({
  model: "gpt-5.6-terra",
  messages: msgs,
});

If you maintain a shared config or a model registry, do a search for the literal string gpt-5.6 with no tier suffix and replace every one. That single sweep prevents the error from reappearing the next time the code runs behind a proxy or a gateway.

Cause 2: The GA rollout has not reached your org yet

GPT-5.6 went generally available on July 9, 2026, but OpenAI rolled it out globally over roughly 24 hours. During that window the same key could resolve the tier IDs in one region and 404 in another. If you are reading this within a day of GA and GET /v1/models does not list the tiers, this is the likely cause and it resolves itself.

What to do depends on how much the wait costs you. A solo developer or hobby project can just recheck the models list every couple of hours and do nothing else, since the grant will land on its own. A team on a paid API plan that cannot hold a launch should route through a gateway that already lists the tiers (see the Alternatives section) and cut back to the direct key once the org catches up. An enterprise account with several organizations should confirm which organization was granted access first, because the grant frequently lands on one org a few hours before the others, and a key from the wrong org 404s even though the account "has access."

A subtle version of this cause: the model appears in your list but calls still 404 for a few minutes. That happens when the catalog entry propagates to the models endpoint before the routing layer is fully live in your region. If the ID is listed but the first call fails, wait five minutes and retry once before treating it as a real error.

Cause 3: Access is enabled on a different org, workspace, or account

Access is scoped per organization, per Codex workspace, and per account email. The person who can use GPT-5.6 in ChatGPT is not automatically the same identity as the API key making the call.

Confirm three things line up:

The API call uses the organization ID that was granted access. If you belong to several orgs, set the OpenAI-Organization header explicitly rather than relying on the default.
The account email on the key matches the one that received the grant.
If your access is for Codex specifically, confirm you are calling from the approved Codex workspace, not a general API key.

Setting the org explicitly removes the guesswork:

from openai import OpenAI

client = OpenAI(
    organization="org-THE_ONE_WITH_ACCESS",  # not your default org
    project="proj_...",                       # the project scoped to the grant
)
resp = client.chat.completions.create(model="gpt-5.6-sol", messages=msgs)

To find which org actually holds the grant, list your organizations in the dashboard or call the models endpoint once per org header and see which one returns the tier IDs. The org that lists them is the one your production key should use. This is why GPT-5.6 can work in ChatGPT while the API 404s: same human, different scoped identity.

Cause 4: A VPN or proxy makes you look like an unsupported region

OpenAI blocks connections that appear to originate from an unsupported country or region, and the block frequently surfaces as a model-not-available or access error rather than a clear geographic message. Corporate proxies and privacy VPNs both trigger it.

Fix: disconnect the VPN or proxy and retry. If you must route through a proxy for compliance reasons, make sure its egress IP is in a supported region, or use a gateway whose upstream region is stable. This cause is easy to miss because the error text says nothing about geography.

To confirm it is region and not something else, check the egress IP your requests actually leave from, not the IP of the machine you are typing on. Corporate networks often route outbound traffic through a gateway in a different country than your office, so a developer in a supported region can still hit the block because the company's egress node is somewhere else. A quick curl https://api.ipify.org from the same host and network that makes the OpenAI call shows the IP OpenAI sees. If that IP resolves to an unsupported region, the model-not-available error is a geography problem wearing a naming-error costume, and no change to your model string will fix it.

Cause 5: Wrong endpoint for how GPT-5.6 exposes a feature

GPT-5.6 ships programmatic tool calling through the Responses API. If your integration is built against chat-completions and you call a Responses-only feature, or you post to the wrong path, you can get an error that reads like the model is unavailable when the model is fine and the endpoint is wrong.

Fix: confirm you are on the endpoint the feature requires. Plain text and standard chat calls work on the chat-completions shape; the newer programmatic tool-calling path uses the Responses API. Match the endpoint to the feature before assuming an access problem.

A standard chat call stays on chat-completions and works fine:

resp = client.chat.completions.create(
    model="gpt-5.6-sol",
    messages=[{"role": "user", "content": "refactor this function ..."}],
)

The programmatic tool-calling path moves to the Responses API:

resp = client.responses.create(
    model="gpt-5.6-sol",
    input="refactor this function ...",
    tools=[{"type": "function", "name": "run_tests", "parameters": {}}],
)

If you copy a tool-calling snippet from the GPT-5.6 launch material into a chat-completions integration, the mismatch can read as a model or capability error. The model is available; the call is on the wrong surface. Keep the two paths separate in your code so a tool-calling change never masquerades as an availability problem.

Cause 6: Tier or verification not enabled on your account

Some accounts need identity or organization verification before frontier models unlock, and some usage tiers gate the newest models until a spend threshold is met. If the models list omits GPT-5.6 but includes older models, and you are past the GA rollout window, check your account's verification status and usage tier in the dashboard.

Fix: complete any pending verification, or if you are blocked by a tier gate you cannot clear quickly, use a gateway that fronts the model on its own verified account (below).

Two concrete things to check in the dashboard. First, organization verification: some accounts must complete an identity or organization verification step before the newest frontier models unlock, and until it is done those models are simply absent from the list while older ones work normally. Second, the usage tier: OpenAI's tiers step up with cumulative spend, and the very newest models sometimes land on higher tiers first. If your account is on an early tier and every GPT-5.6 tier is missing while GPT-5.5 is present, a tier gate is the likely reason. Neither of these is something you can fix in code, which is exactly why a gateway that already fronts the model on a verified, higher-tier account is the pragmatic unblock while you sort out your own account status.

Common Failure Patterns We See

These are the shapes this error takes in real integrations, so you can pattern-match your own symptom.

Symptom	Most likely cause	First thing to try
Works in ChatGPT, 404 in API	Cause 3 (scoped identity)	Set the org header, check account email
Worked yesterday, 404 today on the same code	Alias repointed or you moved behind a gateway	Switch to explicit tier ID (Cause 1)
404 in one region, 200 in another, same key	Cause 2 (rollout) or Cause 4 (region)	Recheck models list; drop VPN
`gpt-5.6` 404 but `gpt-5.5` works	Cause 1 (bare alias not supported here)	Use `gpt-5.6-sol` explicitly
Model resolves but tool call fails	Cause 5 (endpoint)	Move the tool call to the Responses API
Every frontier model 404s, older ones work	Cause 6 (verification/tier)	Check verification and usage tier

Alternatives That Get You Unblocked Now

If you cannot wait for your own org's rollout or clear a tier gate, route the call through a gateway that already lists all three tiers. This is the fastest unblock, and it is a one-line model-string change from a standard OpenAI SDK setup.

On ofox, all three GPT-5.6 tiers are live on the OpenAI-compatible endpoint, verified July 10, 2026:

Tier	ofox model ID	Price (per 1M, in / out)	Detail page
Sol (flagship)	`openai/gpt-5.6-sol`	$5 / $30	ofox.ai/models/openai/gpt-5.6-sol
Terra (balanced)	`openai/gpt-5.6-terra`	$2.50 / $15	ofox.ai/models/openai/gpt-5.6-terra
Luna (fast)	`openai/gpt-5.6-luna`	$1 / $6	ofox.ai/models/openai/gpt-5.6-luna

The switch from an OpenAI-direct client:

from openai import OpenAI
import os

# was: client = OpenAI()  # api.openai.com, waiting on your org rollout
client = OpenAI(
    base_url="https://api.ofox.ai/v1",
    api_key=os.environ["OFOX_API_KEY"],
)

resp = client.chat.completions.create(
    model="openai/gpt-5.6-terra",   # explicit tier, no bare-alias 404
    messages=[{"role": "user", "content": "Summarize this stack trace: ..."}],
)
print(resp.choices[0].message.content)

Node, same idea:

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.ofox.ai/v1",
  apiKey: process.env.OFOX_API_KEY,
});

const resp = await client.chat.completions.create({
  model: "openai/gpt-5.6-terra",
  messages: [{ role: "user", content: "Summarize this stack trace: ..." }],
});
console.log(resp.choices[0].message.content);

Same SDK, same call shape, one changed base URL and model string. If cost is the reason you are moving anyway, Terra lists at exactly half of GPT-5.5's rate, and the GPT-5.6 Terra vs GPT-5.5 cost breakdown has the per-task math. For non-OpenAI options that undercut all three tiers, the GLM-5.2 vs GPT-5.5 cost comparison covers the open-weight side, and the $30 AI coding stack guide shows how to route across providers with automatic fallback so a single model's availability never blocks you again.

How to Monitor GPT-5.6 Availability and Get Alerted

If you are waiting on a rollout or an access grant, do not sit there refreshing a curl command by hand. Poll the models endpoint on a timer and have it tell you the moment the tier appears. A minimal watcher:

import os, time
from openai import OpenAI

client = OpenAI(api_key=os.environ["OPENAI_API_KEY"])
target = "gpt-5.6-sol"

while True:
    ids = {m.id for m in client.models.list().data}
    if target in ids:
        print(f"{target} is now available")
        break
    print(f"{target} not yet listed, rechecking in 5 min")
    time.sleep(300)

Point that at whichever surface you care about and let it run. When it prints the availability line, your grant has landed and you can flip production back to the direct key. Keep the poll interval at five minutes or more, since hammering the endpoint during a rollout adds nothing.

For the platform side, watch OpenAI's official status page for API incidents that can also surface as availability errors, and keep a fallback route configured so a slow rollout never becomes an outage for your users. On a gateway, the model catalog is itself the availability signal: if the ofox model catalog lists the tier and your key is valid, the model is callable right now, no rollout to wait on. That is the practical difference between depending on one provider's rollout schedule and routing through a layer that already has the model live.

How to Confirm Access in Ten Seconds

Before you retry anything, ask the API what it will actually serve your key:

curl https://api.openai.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" \
  | grep -o '"id": *"gpt-5.6[^"]*"'

If that prints the tier IDs, the model exists for you and any error is in your request. If it prints nothing, your key does not have access yet, and the fix is access (rollout, org scope, verification), not code. On a gateway, the same idea applies: the ofox model catalog lists exactly what your key can call, so you never have to guess a model string.

Prevent It From Recurring

Fixing the error once is easy. Keeping it fixed is a matter of three habits that cost nothing to adopt.

Name the tier everywhere, with no bare gpt-5.6 in your codebase. Put the model ID in one config constant rather than scattering the string across call sites, so the next model bump is a one-line change and there is no stray bare alias hiding in a script you forgot about. A single source of truth for the model string is the difference between a thirty-second upgrade and an afternoon of grepping.

Validate the model at startup, not at first request. Call the models-list endpoint when your service boots and fail loudly if the configured ID is absent, rather than discovering it when a user's request 404s in production. A four-line startup check turns a silent, intermittent user-facing failure into a clear deploy-time error you see immediately.

Keep a fallback route wired in. If your only path to GPT-5.6 is one provider on one org, any rollout lag, tier gate, or region hiccup becomes downtime. Routing through a layer that can fall back to another provider or another account means a single model's availability is never a single point of failure. The $30 AI coding stack guide walks through that routing pattern end to end, and it is the structural fix that makes all six causes above stop mattering to your users.

FAQ

The short version, in the order you should check: model string first, models list second, then org scope, region, endpoint, and verification. Five of the six causes are a one-line change on your side, and the sixth is a short wait or a switch to a gateway that already lists all three tiers.

If GPT-5.6 is not available for your key, walk the six causes top to bottom: model string, rollout, org scope, region, endpoint, verification. Five of the six are yours to fix in under a minute, and the sixth is a short wait or a one-line switch to a gateway that already lists all three tiers.

Originally published on ofox.ai/blog.

Gemini CLI Free Tier Shut Down: 6 Fixes That Work (2026)

Owen — Tue, 07 Jul 2026 09:48:44 +0000

TL;DR. On June 18, 2026, Gemini CLI stopped serving requests for the free "Sign in with Google" path, plus AI Pro and Ultra login. The binary is not dead: it is still Apache-2.0, still maintained (v0.49.0), and still runs on an API key. If you are staring at "This client is no longer supported for Gemini Code Assist for individuals," you have an auth problem, not a broken install. The fix is to stop logging in with a Google account and start using an API key with billing enabled. There is a second wall waiting in September 2026, when unrestricted Standard keys get retired, so set the key up correctly once instead of twice. Six fixes below, sorted from free-tier stopgap to production routing.

Google did not kill Gemini CLI on June 18. It killed the free login. The tool still runs; it just wants a key now instead of your Google account.

Is Your Gemini CLI Broken? The 30-Second Diagnosis

Three checks, in order. Most people who think the CLI is broken are one environment variable away from working.

Step	What to check	What it means
1	The error text	"This client is no longer supported for Gemini Code Assist for individuals" means the free OAuth login is gone. "Quota exceeded … limit: 0" or `429 RESOURCE_EXHAUSTED` means your key has no paid quota.
2	Which auth you use	Run `gemini` and watch the startup. If it opens a browser to sign in with Google, you are on the retired consumer login. If it reads an env var, you are on API-key auth.
3	`echo $GEMINI_API_KEY`	Empty output plus a browser login prompt confirms you never moved off the free tier. That is the whole problem.

If step 1 shows the "no longer supported" message, skip ahead to Fix 1. If it shows a 429 or limit: 0, you already have a key but no quota; go to Fix 3. Everything else in this guide is about doing the migration once so you do not hit the September key cutoff and have to redo it.

When to Fix in Place, and When to Switch Tools Instead

This is the decision that saves you an afternoon of poking at the wrong layer.

Fix Gemini CLI in place (Fixes 1 to 5) if

You have existing scripts, aliases, or CI that call gemini and you do not want to rewrite them.
You are fine paying per token and you want the same tool you already know.
You need Vertex AI or a Code Assist license path, both of which the June 18 change left untouched.

Switch to Antigravity CLI if

You were only ever on the free consumer login, you do not want to enable billing, and you want the path Google is actively steering consumers toward.
You want the newer async background agent workflow and do not care that it is a separate, closed-source binary.

Route through a gateway (Fix 6) if

You want one key across Gemini, GPT, Claude, and others without managing a Google Cloud project, billing tiers, and the September key migration.
You are building something user-facing where a single provider's policy change should never take you down again.

Stop rule. If you have re-run the Google login three times, cleared ~/.gemini, and reinstalled the CLI and still see "no longer supported," stop. Reinstalling cannot fix a server-side auth policy. The token exchange is being refused on purpose. Move to an API key and the loop ends.

What Actually Changed on June 18, 2026

Google announced this at I/O 2026 on May 19 and published it on the Developers Blog as "An important update: Transitioning Gemini CLI to Antigravity CLI." The operative sentence:

"On June 18, 2026, Gemini CLI and Gemini Code Assist IDE extensions will stop serving requests for Google AI Pro and Ultra, as well as those using it free of charge using Gemini Code Assist for individuals."

Read that carefully, because the popular "Gemini CLI is dead" framing gets it wrong. Three separate auth paths, three different outcomes:

Auth path	Status after June 18, 2026	What to do
OAuth "Sign in with Google" free tier (Code Assist for individuals, AI Pro, Ultra)	Shut down. Requests no longer served.	Move to an API key, or move to Antigravity CLI.
Gemini API key from AI Studio	Works. Free tier still exists for Flash models; paid tier fully supported.	Set `GEMINI_API_KEY`, enable billing for real quota.
Paid Gemini / Vertex "Gemini Enterprise Agent Platform" key, or Code Assist Standard/Enterprise license	Explicitly unchanged.	Keep going. Nothing to do.

Google's announcement is blunt about the survivors: "Gemini CLI will remain accessible via paid Gemini and Gemini Enterprise Agent Platform API keys," and enterprise license and Google Cloud access "remains unchanged." A follow-up repo notice, Discussion #28017, confirmed the individual-account cutoff went live as scheduled.

The binary itself is fine. The repo is not archived, the license is still Apache-2.0, and v0.49.0 shipped on June 25, a week after the shutdown. Google said it plainly: the project "remains available to the community as an Apache 2.0 licensed repository with no changes." So when someone tells you to abandon your Gemini CLI setup, they are conflating "the free login ended" with "the tool ended." Only the first one is true.

This did not come out of nowhere. Back on March 18, 2026, Google posted a service update (Discussion #22970), with restrictions effective March 25, that already limited free OAuth users to Flash-tier models and added "more robust detection for policy-violating use cases," while recommending people "use Gemini CLI with your own paid API key from AI Studio or Vertex AI." June 18 was the hard cutoff that the March update foreshadowed.

Understanding the Errors: What Each One Means

Four error signatures cover almost every report. Match yours to the row and you know which fix applies.

Error you see	Real cause	Fix
`This client is no longer supported for Gemini Code Assist for individuals. To continue using Gemini, please migrate to the Antigravity suite of products.`	You are on the retired free OAuth login. Browser step succeeds, token exchange is refused.	Fix 1 (switch to API key)
`You must be a named user on your organization's Gemini Code Assist Standard edition subscription ...` (403)	Personal account hitting an org-only entitlement gate. An earlier variant of the same lockout (issue #14934).	Fix 1 or Fix 5 (license/Vertex)
`Quota exceeded for metric: generativelanguage.googleapis.com/generate_content_free_tier_requests, limit: 0` and `TerminalQuotaError: You have exhausted your daily quota on this model.`	Key is on Free Tier with zeroed quota; no paid provisioning behind it (issue #22486).	Fix 3 (enable billing)
`429: rate limit exceeded` with `limit: 0` on a paid subscriber	A Google One AI Pro subscription does not auto-provision paid API quota to your key (issue #24396).	Fix 3 (enable billing, set a real cap)

The pattern worth internalizing: a login error points at the auth method, a limit: 0 error points at billing. They feel similar in the terminal and need completely different fixes. Do not enable billing to solve a login error, and do not re-login to solve a quota error.

How to Keep Gemini CLI Running (Fixes for Every Tier)

Sorted from "free, works in five minutes" to "production routing." Apply the tier that matches you.

Free / Individual Tier

Fix 1: Switch from Google login to an AI Studio API key

This is the core move and it resolves the "no longer supported" message directly. Create a key at aistudio.google.com/apikey, then:

export GEMINI_API_KEY="your_ai_studio_key"
gemini "say hi"

A working response means you are back in business. If you want to confirm the CLI is actually on the key and not silently falling back to a cached login, check the auth line at startup or print the variable first:

echo "${GEMINI_API_KEY:0:6}..."   # should show the first chars of your key, not empty

If you would rather pick from a menu, run /auth inside the CLI and choose the Gemini API key option instead of "Login with Google." The setting is saved in ~/.gemini/settings.json so you only do it once. One caveat on precedence: the client libraries accept both GEMINI_API_KEY and GOOGLE_API_KEY, and if both are set, GOOGLE_API_KEY wins. If your key looks correct but behaves oddly, check for a stray GOOGLE_API_KEY in your shell profile left over from an old Vertex experiment.

A free key still exists for the Flash and Flash-Lite families, so Fix 1 alone gets a lot of people running again. It is best-effort, though, which is the next fix.

Fix 2: Reset a broken auth state before you blame the key

If you switched keys but the CLI still tries to log in with Google, the old selectedAuthType is cached. Clear it:

# Back up first, then reset the CLI's saved auth choice
mv ~/.gemini/settings.json ~/.gemini/settings.json.bak
gemini   # will prompt /auth again; pick the API key option

This is also the fix for "Please set an Auth method" and for the case in issue #2111 where the CLI refuses to switch auth types while an API key is set. A stale settings file causes more "it still does not work" reports than any actual key problem.

Paid / Team Tier

Fix 3: Enable billing to escape the 429 `limit: 0` trap

This is the fix for every "I added a key and still get 429" report. A raw AI Studio key sits on the Free Tier, and a Google One AI Pro subscription does not push paid quota into it. The metric comes back limit: 0, which reads like a bug but is just an unprovisioned key.

Do this once:

Open AI Studio billing and link a Google Cloud Billing account to the project behind your key.
Set a real spend cap. A $0 cap keeps you on Free Tier and reproduces the 429; set something you are comfortable with (even $10 is enough to move to paid Tier 1).
Refresh the CLI auth: clear the cache from Fix 2 or re-export the key, then retry.

Google's tiers escalate with spend: Free, then Tier 1 (billing enabled), then Tier 2 and Tier 3 at higher paid thresholds, each raising your rate limits. Tier 1 alone carries a per-window spend allowance (on the order of $10 per 10 minutes) that is plenty for individual use.

Fix 4: Right-size the model so the paid bill stays small

You are paying per token now, so pick the model deliberately. Current standard pricing on the Gemini API, per 1M tokens (verified on the official pricing page, 2026-07-07):

Model	Input / 1M	Output / 1M	Notes
Gemini 3.1 Flash-Lite	$0.25	$1.50	Cheapest; fine for routine edits and shell tasks
Gemini 3.5 Flash	$1.50	$9.00	Balanced default for coding
Gemini 3.1 Pro Preview	$2.00 (prompts up to 200k)	$12.00	Reserve for hard reasoning; price steps up above 200k

For most terminal work, Flash-Lite is the right default and keeps a heavy day under a dollar. Move up to Flash for real coding and only reach for Pro on the genuinely hard prompts. If you want the deeper pricing and performance breakdown, see the Gemini 3.1 Pro API pricing guide. Model names on Google's side move fast, so re-check the exact IDs at the pricing page before you hard-code them into scripts.

Enterprise / Production Tier

Fix 5: Use Vertex AI or a Code Assist license

Both of these paths were untouched by June 18, which makes them the cleanest option if you already have a Google Cloud footprint. For Vertex AI:

export GOOGLE_GENAI_USE_VERTEXAI=true
export GOOGLE_CLOUD_PROJECT="your-project-id"
export GOOGLE_CLOUD_LOCATION="us-central1"
export GOOGLE_APPLICATION_CREDENTIALS="/path/to/service-account.json"
gemini

Vertex uses your Cloud project's billing and IAM, so quota and access are governed by the project, not by a personal account Google can reclassify. If your organization holds a Gemini Code Assist Standard or Enterprise license, the CLI and IDE extensions keep working with no change at all; that is stated directly in Google's announcement. For teams, this is usually the least fragile answer.

Fix 6: Route through one gateway and stop caring about Google's tiers

If you would rather not manage a Cloud project, a billing tier, and the September key migration, point Gemini CLI at a gateway that speaks the Gemini protocol. Through ofox.ai, the same CLI uses one key, no Google Cloud account, and gets failover and routing on top:

{
  "apiKey": "<your OFOX_API_KEY>",
  "baseUrl": "https://api.ofox.ai/gemini"
}

Or as an environment variable, the same shape as before:

export GEMINI_API_KEY="<your OFOX_API_KEY>"

That one key also reaches GPT, Claude, Qwen, DeepSeek, and the rest of the model marketplace through the same account, so the next time a single vendor changes its consumer policy, your CLI does not go down with it. This is the same routing idea covered in the multi-model router walkthrough, applied to Gemini CLI specifically.

The Second Wall: API Key Deadlines You Have Not Hit Yet

Fixing the login is not the end of the story, and this is the part most "just add a key" guides skip. Google is retiring old-style API keys on a separate schedule:

Date	What happens
June 19, 2026	The Gemini API begins rejecting unrestricted Standard keys. Standard keys with explicit API restrictions keep working.
September 2026	The Gemini API rejects all Standard keys. You must be on auth keys, which are bound to a Cloud service account.

The practical consequence: if you dig up an old unrestricted key from 2025 to fix your login today, you may hit a wall again in September. Create a new key now, since new keys are issued as auth keys by default, or apply explicit API restrictions to the key you use. Doing the migration once, correctly, is the difference between one bad afternoon and two.

Timeline: How the Gemini CLI Free Tier Wound Down

The shutdown was gradual, and seeing the sequence explains why your setup broke when it did.

Date	Event
March 18, 2026	Service update posted (restrictions effective March 25): limits free OAuth users to Flash-tier models, adds abuse detection, recommends paid API keys (Discussion #22970).
May 19, 2026	I/O 2026 announcement: Gemini CLI consumer/Pro/Ultra login transitioning to Antigravity CLI (Developers Blog + Discussion #27274).
June 18, 2026	Free, AI Pro, and Ultra logins stop serving requests. "No longer supported" errors begin.
June 19, 2026	Unrestricted Standard API keys start getting rejected (separate key-security change).
June 25, 2026	Gemini CLI v0.49.0 ships, confirming the binary is still maintained.
September 2026	Planned cutoff for all Standard keys; auth keys required.

If your CLI broke around mid-June, this is why. And if it is still working on an old key, the September row is the one to watch.

Why Google Ended the Free Login

You do not need the backstory to fix your terminal, but it explains why this is not a temporary outage you can wait out. Three forces line up.

First, cost. A free OAuth login handed real model inference to anyone with a Google account, and coding agents are token-hungry: a single long session can burn through more tokens than a month of chat. The March 18 service update said the quiet part out loud when it added "more robust detection for policy-violating use cases (e.g. using Gemini CLI OAuth with third-party software)." People were wiring the free login into scripts and wrappers it was never meant to power, and the free tier was subsidizing that at Google's expense.

Second, product consolidation. At I/O 2026 Google pulled its developer tooling under the Antigravity brand. Antigravity CLI, the desktop app, and the IDE story now share one architecture. The open-source Gemini CLI does not fit that funnel cleanly, so the consumer login got routed to the product Google actually wants to grow, while the CLI was left as the API-key and enterprise tool it started as.

Third, abuse economics. Free credentials attached to a personal account are the easiest thing in the world to farm. Moving individuals onto keys with billing (or onto Antigravity's managed login) gives Google a caller identity for every request, which is the same reason the separate September Standard-key retirement exists.

The takeaway for your setup: this is structural, not a blip. Plan for API-key auth as the permanent state, not a workaround until the free tier comes back. It is not coming back.

When the Free Login Is Gone: Alternatives That Work Now

If moving to a paid Google key is not what you want, here are the realistic options, ranked by how little ongoing management they need.

ofox.ai. One key that speaks the Gemini protocol (https://api.ofox.ai/gemini) and also reaches GPT, Claude, Qwen, DeepSeek, and 100+ more through one OpenAI-compatible endpoint. No Google Cloud project, no billing-tier maze, no September key migration, and failover across providers if one vendor degrades. Best if you want the Gemini CLI workflow without being tied to one vendor's consumer policy. Setup is the same JSON file or env var you would use for Google's own key, so switching costs you a single line.
Antigravity CLI. Google's official destination for consumer and Pro/Ultra logins. It is a closed-source Go binary with async background agents and a shared architecture with the Antigravity 2.0 desktop app. Best if you specifically want the free or Pro consumer path Google is now backing and you do not mind switching tools. Worth noting it is a different product, not a drop-in replacement: your existing gemini scripts and aliases will not carry over unchanged.
Vertex AI (Gemini). Same models, governed by your Cloud project's billing and IAM instead of a personal account Google can reclassify. Best if you already run on Google Cloud and want enterprise controls. Higher setup cost (project, service account, roles), but the most durable of the lot because nothing about it depends on the consumer login tier.
OpenRouter or similar gateways. Another multi-provider option. Slower per request than a dedicated gateway and the markup stacks up, but worth knowing as a comparison point. See the honest OpenRouter review for where the hidden cost lands.

For the broader picture of running several assistants without a per-tool billing headache, the multi-CLI setup guide covers managing Gemini CLI alongside Codex and Claude Code, and the cost-reduction playbook covers keeping the paid bill down once you are off the free tier.

How to Monitor Your Gemini CLI Auth and Quota

Three things to watch so the next change does not surprise you.

Your live rate limits. Google no longer prints exact free-tier requests-per-minute and per-day numbers in the docs; it moved them to the live AI Studio rate-limit dashboard. Check there, not a blog table, for what your key actually allows today.

Your spend cap. If you enabled billing, watch the cap. A cap set too low silently drops you back into limit: 0 territory and looks exactly like the original bug.

Your key type. Before September, confirm your key is an auth key or a restricted Standard key. An unrestricted Standard key is a scheduled outage waiting for a date.

The full Gemini CLI configuration guide covers the settings-file and endpoint options in more depth if you want the complete setup reference rather than just the recovery path.

A login error points at your auth method. A limit: 0 error points at your billing. They look the same in the terminal and need opposite fixes.

FAQ

Is Gemini CLI dead after June 18, 2026? No. The open-source binary is still Apache-2.0, still shipping (v0.49.0 landed June 25), and still runs. What ended is the free consumer login: the "Sign in with Google" path for Code Assist for individuals, plus AI Pro and Ultra sign-in. Google's own words are that the CLI "will remain accessible via paid Gemini and Gemini Enterprise Agent Platform API keys." Set a key and the same tool keeps working.

Why does it say "This client is no longer supported for Gemini Code Assist for individuals"? You are logging in with the retired free personal-account flow. The browser step reports success, but the token exchange is refused server-side, which is why reinstalling never helps. Switch auth from Google login to an API key.

How do I switch from Google login to an API key? Create a key at aistudio.google.com/apikey with billing enabled, then export GEMINI_API_KEY=your_key and run gemini. For a menu, run /auth in the CLI and choose the API key option. If both GEMINI_API_KEY and GOOGLE_API_KEY are set, GOOGLE_API_KEY wins.

Why do I still get 429 "limit: 0" after adding a key? Your key is on the Free Tier with no paid quota behind it, and a Google One AI Pro subscription does not auto-provision that quota. Enable billing in AI Studio, link a Cloud Billing account, and set a real spend cap (not $0). That moves the key to paid Tier 1.

Will my key stop working in September 2026? It can, if it is an unrestricted Standard key. Google began rejecting unrestricted Standard keys on June 19, 2026, and plans to reject all Standard keys in September in favor of auth keys bound to a Cloud service account. Create a new key now or apply explicit restrictions to your existing one.

Can I keep any free tier for Gemini CLI? There is still a free tier on the AI Studio key for the Flash and Flash-Lite families, separate from the killed login. Exact per-model rate limits are no longer published in the docs; they live in the AI Studio dashboard. Treat free-key quota as best-effort and enable billing if you need reliability.

What is the difference between Gemini CLI and Antigravity CLI? Gemini CLI is the existing open-source Node tool you install with npm and drive with an API key. Antigravity CLI is a new closed-source Go binary that Google made the destination for consumer and Pro/Ultra logins. Keep Gemini CLI if you want your existing scripts and setup; move to Antigravity if you only ever used the free login and want Google's managed consumer path.

Does enterprise access still work? Yes. Organizations on a Gemini Code Assist Standard or Enterprise license, or using Google Cloud, keep access unchanged, and Vertex AI with GOOGLE_GENAI_USE_VERTEXAI keeps working. June 18 targeted individual consumer login only.

Sources Checked for This Refresh

Google Developers Blog, "An important update: Transitioning Gemini CLI to Antigravity CLI": https://developers.googleblog.com/an-important-update-transitioning-gemini-cli-to-antigravity-cli/ (verified 2026-07-07). Confirms the June 18, 2026 cutoff for free, AI Pro, and Ultra login, and that paid Gemini, Vertex keys, and Code Assist licenses are unchanged.
Gemini CLI repo Discussion #27274 (official transition notice) and #28017 (individual-account cutoff confirmation): https://github.com/google-gemini/gemini-cli/discussions/27274
Gemini CLI repo Discussion #22970, posted March 18, 2026 with restrictions effective March 25 (free OAuth restricted to Flash, paid-key recommendation): https://github.com/google-gemini/gemini-cli/discussions/22970
GitHub issue #28229, "OAuth login fails for Google AI Pro users" (v0.49.0, exact "no longer supported" string): https://github.com/google-gemini/gemini-cli/issues/28229
GitHub issues #22486 and #24396, the limit: 0 and 429 quota traps and the billing fix: https://github.com/google-gemini/gemini-cli/issues/24396
Google AI for Developers, "Using Gemini API keys": https://ai.google.dev/gemini-api/docs/api-key (verified 2026-07-07). Documents GEMINI_API_KEY and GOOGLE_API_KEY precedence and the aistudio.google.com/apikey creation flow.
Google Gemini API pricing: https://ai.google.dev/pricing (verified 2026-07-07). Source for the per-1M token prices in the model table.
Google Gemini API rate limits: https://ai.google.dev/gemini-api/docs/rate-limits (verified 2026-07-07). Tier structure, 429 RESOURCE_EXHAUSTED, and the note that limits now live in the AI Studio dashboard.
ofox.ai Gemini CLI integration docs: https://ofox.ai/docs/integrations/gemini-cli (verified 2026-07-07). The https://api.ofox.ai/gemini endpoint, GEMINI_API_KEY env var, and settings.json fields.

Originally published on ofox.ai/blog.

Codex Desktop Not Showing Custom Models: 5 Fixes (2026)

Owen — Sun, 05 Jul 2026 10:36:18 +0000

You wired up a custom provider, codex runs fine from the terminal, but the Desktop model picker acts like your models do not exist. That gap is almost never your API key or your config syntax. It is the Desktop client quietly filtering models that the backend already loaded.

The 30-Second Diagnosis

Before you rewrite anything, match your symptom to the table. Most people are one line away from a fix.

What you see	What is actually wrong	First move
Picker shows only "Custom", no model name	Model set inline, no catalog metadata	Fix 1: keep the inline `model`, it works
`codex` CLI `/model` lists it, Desktop does not	Desktop client-side filter (issue #19694)	Fix 1 now, Fix 4 for a real listing
Picker dropdown is empty	Missing or malformed catalog	Fix 2 or Fix 4
Nothing loads, startup prints a warning	Provider in project-local `.codex/config.toml`	Fix 3: move it to `~/.codex/`
cc-switch native provider, still hidden	Pre-v3.16.5 catalog format	Fix 4: update, then re-save

The single fastest check: open a terminal in the same folder and run codex (the CLI), then type /model. If the CLI lists your model but Desktop does not, you have the client-side filter bug, and no amount of config editing on the Desktop side will surface it. Skip to Fix 1.

flowchart TD
  A[Custom model missing in Desktop] --> B{Does CLI /model show it?}
  B -- Yes --> C[Desktop filter bug #19694]
  C --> F1[Fix 1: set model inline + Fix 4 catalog]
  B -- No --> D{Provider in ~/.codex/config.toml?}
  D -- No, it is project-local --> F3[Fix 3: move to user-level]
  D -- Yes --> E{Catalog file present + valid?}
  E -- No --> F2[Fix 2 or Fix 4: generate catalog]
  E -- Yes --> F1

When to Apply These Fixes (and When to Switch Models Instead)

Fix the config when the model runs but the picker will not show it. That is a display problem, and it is worth ten minutes because everything else already works. Concretely, that is the case where your requests succeed from the CLI or a direct curl and the model just does not appear in the Desktop dropdown. You are looking at the #19694 filter or a catalog gap, and Fixes 1 through 4 apply.

Switch models instead of editing configs when the route itself is broken. If curl https://your-gateway/v1/responses comes back 401, 404, or model-not-found, the picker is not your problem. The provider or the model string is wrong, and no amount of catalog editing will rescue a route that does not resolve.

Then there is the exit condition. If your only goal is to send requests to a custom model, Fix 1 alone gets you there: set model inline, restart, done. The rest of this guide is about making the picker show a clean, switchable list, which matters for teams and for anyone who swaps models often. If you never open the dropdown, stop after Fix 1.

Why Codex Desktop Hides Custom Models

There are four distinct root causes, and they need different fixes. Getting the wrong one is why people spend an afternoon re-typing a working config.

Root cause	Why the picker hides the model	Which setups hit it	Fix
Desktop client-side filter	App-server returns the model via `model/list`, the Desktop renderer drops it	Any custom provider with a catalog	Fix 1 + Fix 4
No catalog metadata	`model` set inline, picker has nothing to describe	Minimal `config.toml` setups	Fix 1 (accept "Custom") or Fix 2
Malformed / stale catalog	Catalog written in a format Codex will not enumerate	Older cc-switch, hand-edited JSON	Fix 2 / Fix 4
Project-local provider	`model_provider` ignored outside `~/.codex/config.toml`	`.codex/config.toml` in a repo	Fix 3

The first one is the one that surprises people. According to the open codex issue #19694, the app-server loads the catalog correctly and returns your models through its model/list endpoint, but the Desktop UI applies an extra filter and removes locally configured models before rendering the picker. The backend knows about your model. The frontend refuses to show it. That is a client bug, not a config error, and it was filed on 2026-04-26 and is still open at time of writing.

The second cause is the most common and the least alarming. If you only wrote model = "some-id" with no catalog, Codex has the string but no display name, no context window, no capability flags. The picker shows the label "Custom" and moves on. Your requests still go to the right model. This trips people up because "Custom" looks broken when it is actually working.

The third cause is what cc-switch users hit before v3.16.5. The community traced it in cc-switch issue #3668: the generated catalog and the provider block did not line up with what Codex's picker enumerates, so /model came back empty for third-party providers even though routing worked. More on the fix in Fix 4.

The fourth cause has a tell. If you dropped your provider into a repo's .codex/config.toml, Codex prints a startup warning and ignores the block entirely. Provider definitions are user-scoped only.

How Codex Loads Models (and Where Desktop Diverges)

Codex builds its model list in layers, and knowing the order tells you which fix will actually land. There are three sources: a catalog bundled with the binary, a remote catalog fetched from OpenAI, and your local model_catalog_json. The local file wins. It overrides both the bundled and the remote catalog on startup, which is why a correct model_catalog_json is the real lever for third-party models rather than a nice-to-have.

Here is the part that trips everyone. When Codex starts, the app-server reads all three layers, resolves them, and exposes the result through an internal model/list endpoint. The CLI renders that list directly, so custom models show up. The Desktop app renders the same list through an extra client step that, per issue #19694, applies its own allowlist and drops locally configured entries before they reach the dropdown. Same backend, same catalog, two different pickers. That single divergence is why the CLI is a dependable escape hatch and Desktop is not.

There is also a cache to watch. Codex keeps ~/.codex/models_cache.json, and after you switch providers or edit a catalog it does not always resync. A stale cache can keep showing an old list, or an empty one, even after your config is correct. Deleting that file forces a clean rebuild on the next launch, which is worth trying before you assume the catalog itself is wrong.

How to Fix It (Solutions for Every Setup)

Work top to bottom. Fix 1 is the one that always works. The later fixes make the picker pretty and the list switchable.

Fix 1: Set the Model Inline (the reliable workaround)

This is the workaround the #19694 thread converged on, and it is the one to reach for first. Put the model string directly in config.toml and let the picker say "Custom".

# ~/.codex/config.toml   (user-level, not a project folder)
model = "moonshotai/kimi-k2.7-code"
model_provider = "ofox"

[model_providers.ofox]
name = "ofox"
base_url = "https://api.ofox.ai/v1"
env_key = "OFOX_API_KEY"
wire_api = "responses"

Export the key (export OFOX_API_KEY=sk-... in your shell profile), fully quit Codex Desktop, and reopen it. The picker will read "Custom" but every request goes to moonshotai/kimi-k2.7-code. If you are pointing at a different model, swap the string: deepseek/deepseek-v4-pro or openai/gpt-5.3-codex are the other coding IDs on the same gateway. All three are reachable from one key. For a walkthrough of the provider block itself, see the Codex CLI multi-provider setup via config.toml guide.

A note on wire_api. Codex removed its older chat/completions path in early February 2026 (see discussion #7782); responses is now the only supported value and the default when the key is omitted. A provider still set to wire_api = "chat" fails on startup. The practical requirement is that your gateway must expose an OpenAI-compatible Responses endpoint at {base_url}/responses, which ofox does at https://api.ofox.ai/v1/responses, so wire_api = "responses" is the right setting here. Point Codex at a gateway that only speaks /chat/completions and every request 404s, which looks like a model problem but is a protocol mismatch. The full field list is in the Codex configuration reference.

Fix 2: Add a Model Catalog So the Picker Lists It

If you want a real name in the dropdown instead of "Custom", you need a model_catalog_json. This is a JSON file, loaded once at startup, with a top-level models array. Each entry describes one model.

# top of ~/.codex/config.toml
model_catalog_json = "/Users/you/.codex/ofox-models.json"
model = "moonshotai/kimi-k2.7-code"
model_provider = "ofox"

A minimal catalog entry, using fields from the official codex models.json:

{
  "models": [
    {
      "slug": "moonshotai/kimi-k2.7-code",
      "display_name": "Kimi K2.7 Code (ofox)",
      "description": "Coding model via the ofox gateway",
      "context_window": 262000,
      "max_context_window": 262000,
      "supported_in_api": true,
      "visibility": "list",
      "priority": 1
    }
  ]
}

The slug must equal the string you send to the provider. The official catalog carries many more fields per model (reasoning levels, tool types, modality flags), and hand-authoring the full shape is fiddly, which is exactly why the next fix exists. Restart Desktop after any catalog change. This layer overrides both the bundled catalog and the remote one, and it only re-reads on startup, so a per-thread config change will not reapply it.

Fix 3: Move the Provider to the User-Level Config

If Codex prints a startup warning about ignored provider settings, your provider block is in the wrong file. model_provider and model_providers only work in ~/.codex/config.toml. A repo's .codex/config.toml cannot define providers. Project-local model_catalog_json is a separate case — by design it should still be read, but on fresh Desktop threads it currently isn't, which is an open bug (#26308) rather than intended behavior.

# check where your provider actually lives
grep -rn "model_providers" ~/.codex/config.toml ./.codex/config.toml 2>/dev/null
# if it is in ./.codex/config.toml, move the [model_providers.*] block
# and model_provider = "..." into ~/.codex/config.toml, then restart

Keep repo-specific things like instructions files in the project config. Keep the provider and the model catalog user-level.

Fix 4: Let cc-switch v3.16.5 Generate the Catalog

If you manage Codex through cc-switch, update to v3.16.5 or later. That release is the one that fixes the empty picker for native providers. It generates ~/.codex/cc-switch-model-catalog.json for suppliers on native Responses endpoints (apiFormat: "openai_responses"), which is what lets Codex Desktop actually see the models and use built-in tools.

Two things you have to do after updating, or nothing changes:

Re-save each native provider once. The catalog is only regenerated on save. Existing providers keep their old (broken) state until you open and re-save them. There is no automatic migration.
Understand the decoupling. In v3.16.5 the model catalog no longer rides on the "local routing" toggle. Native Responses suppliers now generate the catalog whether or not local routing is on, while Chat-format suppliers keep going through proxy conversion as before.

# confirm the catalog exists and lists your models after re-saving
cat ~/.codex/cc-switch-model-catalog.json | grep -o '"slug":[^,]*'
# if this is empty, re-save the provider in cc-switch and check again

One caveat cc-switch itself disables: a few first-party Chinese models (MiMo, LongCat, MiniMax, Qwen3-Coder) do not support OpenAI's built-in web_search on their gateways, so v3.16.5 turns that tool off for them by default to stop Codex throwing a hard 400. If you route those through a gateway, expect web search to be off.

Common Setup Errors That Mimic the Picker Bug

Half the "custom models not showing" reports are really a broken route wearing a display costume. Before you touch the catalog, rule these out. Each one produces a symptom that looks like the picker hiding your model, when in fact the request never had a chance to land.

Symptom	Real cause	Fix
Startup error, or every request 404s	`wire_api = "chat"` (removed Feb 2026) or a gateway with no `/responses` endpoint	Set `wire_api = "responses"` and point at a Responses-capable gateway
Every request returns 401	`env_key` named but the variable never exported	`export OFOX_API_KEY=...` in your shell profile
Model runs but returns the wrong output	Catalog `slug` does not match the provider's model ID	Match `slug` to the exact model string
Provider ignored, startup warning printed	Block lives in project-local `.codex/config.toml`	Move it to `~/.codex/config.toml`
Intermittent connection resets	Trailing slash or wrong path on `base_url`	End the URL at `/v1`, no trailing slash

The tell that separates these from the real #19694 filter is one command: run the same request from the CLI. If the CLI also fails, it is one of the errors above, not the Desktop picker, and no catalog edit will fix it. If the CLI succeeds and only Desktop stays blind, then it is the filter, and you are back to Fix 1 and Fix 4.

Known Codex Desktop Custom-Model Issues (2026 Timeline)

This is not one bug. It is a cluster of related issues in the Codex app and in the tools that write its config. Knowing which one you have saves you from applying the wrong fix.

Issue	What breaks	Reported	Status
openai/codex #19694	Desktop picker filters out catalog models the backend loaded	2026-04-26	Open
openai/codex #26308	Desktop ignores project-local `model_catalog_json` on fresh threads	2026	Open
openai/codex #22160	CLI `/model` and Desktop pickers did not expose profile / provider aliases	2026	Closed
openai/codex #15364	No UI to pick a custom provider inside the Desktop app	2026	Closed
cc-switch #3668	cc-switch catalog format not recognized, `/model` empty	2026-06-03	Fixed in v3.16.5

The pattern across all of these: the routing works, the display does not. The CLI has been the reliable escape hatch every time, because it reads the catalog without the Desktop renderer's extra filtering. If you are blocked in Desktop, the CLI (codex in your terminal) will almost always show and use the model.

When the Picker Still Won't Show Models: Alternatives That Work Now

If you are done fighting the Desktop UI, here are ways to keep using custom models without waiting on a client fix. The point of a gateway here is one endpoint and one key across many models, so switching a model is a one-string edit rather than a new provider block each time.

Path	How the model reaches Codex	Picker behavior	Notes
ofox gateway	One `base_url`, one key, many model IDs	"Custom" or catalog-listed	Kimi, DeepSeek, GPT-Codex from one provider block
Codex CLI	Same config, terminal client	Lists custom models reliably	Bypasses the Desktop filter
Direct provider key	Separate provider block per vendor	Same filter applies	More keys, more blocks to maintain
Local (Ollama)	`base_url` at localhost	Warnings unless catalog set	Offline, no gateway

Using ofox as the provider collapses the maintenance: moonshotai/kimi-k2.7-code (262K context), deepseek/deepseek-v4-pro (1M context), and openai/gpt-5.3-codex (512K context) all sit behind the same https://api.ofox.ai/v1 and the same key, with current per-token pricing shown on each model's ofox page. To swap models you change one string in config.toml, no new provider block, no second key. The base-URL setup for OpenAI-compatible clients is in the ofox docs. Whichever path you take, the Desktop picker quirk is a display layer on top, not a routing constraint.

How to Verify Your Custom Models Are Actually Loaded

Do not trust the picker as your source of truth, because that is the thing that is broken. Verify at the layer below it.

codex --version                 # confirm you are on a recent build
codex                           # start the CLI, then type /model
# the CLI enumerates the catalog without the Desktop filter

If /model in the CLI shows your model, the catalog and provider are correct and any remaining gap is the Desktop renderer. If the CLI also comes up empty, the problem is upstream: wrong file (Fix 3), malformed catalog (Fix 2 / Fix 4), or a bad slug. For a raw sanity check that the route itself resolves, one curl against the gateway with your key tells you whether the model exists before you blame the client at all. Routing first, display second.

FAQ

Why is Codex Desktop not showing my custom models? Usually the model works and the Desktop app is filtering it out of the picker (issue #19694). Secondary causes: no catalog file, a malformed catalog from an older tool, or a provider defined in a project-local .codex/config.toml.

How do I add a custom model to Codex config.toml? Define [model_providers.NAME] with base_url, env_key, and wire_api, then set model_provider and model. Keep it in ~/.codex/config.toml. For ofox, base_url = "https://api.ofox.ai/v1".

Does cc-switch work with Codex Desktop? Yes, from v3.16.5, which generates ~/.codex/cc-switch-model-catalog.json for native Responses providers. Re-save each provider once after updating.

Where is the Codex model catalog file located? Wherever model_catalog_json points in ~/.codex/config.toml. cc-switch uses ~/.codex/cc-switch-model-catalog.json. Watch for a stale ~/.codex/models_cache.json after switching providers.

Why does Codex show "Custom" instead of my model name? You set model inline with no catalog entry, so the picker has no display metadata. Requests still go to the right model.

Can I use custom models in a project-local .codex/config.toml? No. Provider settings only apply in ~/.codex/config.toml. Project-local provider blocks are ignored with a startup warning.

What is model_catalog_json in Codex? A config.toml key pointing to a JSON file, loaded at startup, with a top-level models array of entries carrying slug, display_name, and capability fields. It overrides the bundled and remote catalogs.

How do I route Codex to Kimi, DeepSeek, or GPT-Codex? Point one custom provider at a gateway and set model. On ofox: moonshotai/kimi-k2.7-code, deepseek/deepseek-v4-pro, openai/gpt-5.3-codex, all from https://api.ofox.ai/v1.

The fix for a model that runs but will not show up is almost always to stop editing the picker and start trusting the layer below it: the CLI already sees what the Desktop app is hiding.

Originally published on ofox.ai/blog.

Migrate Claude Code to Codex (2026): 12 Configs, 1 Dead End

Owen — Fri, 03 Jul 2026 07:38:06 +0000

Migrate Claude Code to Codex (2026): 12 Configs, 1 Dead End

Codex 0.142 /import auto-moves most of your Claude Code config. All 12 surfaces mapped: what transfers, what breaks, the 1 dead end, and the fix.

Migrating from Claude Code to Codex is mostly a rename-and-reformat job, and Codex now ships a one-command importer that does most of it for you. The trouble hides in what it leaves behind, and one item in there is not a config file at all.

30-Second Migration Verdict

You can move nearly your whole Claude Code setup to Codex in about 20 minutes. Here is the decision before you scroll:

Question	Answer
Can most of my config move?	Yes. 9 of 12 surfaces transfer or reshape cleanly.
Fastest path?	`codex` → `/import` (Codex 0.140+), then hand-fix 3 items.
What auto-transfers?	Memory files, MCP servers, skills, slash commands, custom endpoints.
What needs manual work?	Permissions model, hooks format, subagent wrappers.
The one dead end?	Anthropic Claude models. Vanilla Codex is OpenAI-only.
The fix for the dead end?	Add a gateway as a `model_provider` and keep running Claude inside Codex.

Versions this guide was tested against: Codex CLI 0.142.5 (July 1, 2026) and Claude Code 2.1.178. If you are on an older Codex, upgrade first, because the /import command did not exist before 0.140.0.

What You Can Move Today (And What You Can't)

Almost everything moves, because the two tools solve the same problem with different file formats. Claude Code leans on JSON (settings.json, .mcp.json) and Markdown (CLAUDE.md, .claude/agents/*.md). Codex leans on a single TOML file (~/.codex/config.toml) plus AGENTS.md. The migration is largely a translation between those two dialects.

What you can move:

Repo and personal instructions (CLAUDE.md content)
MCP servers, verbatim command and args
Skills, which already follow the shared Agent Skills convention
Slash commands and reusable prompts
Custom API endpoints and keys

What you cannot move without a workaround:

Claude Code's per-command permission allowlist, which has no direct Codex analog
The ConfigChange hook event (Codex has PreCompact/PostCompact, but nothing that fires on a config-file change)
Output styles, which Codex does not model
The Anthropic models themselves, which is the real blocker and the reason for the last section

Here is the full surface map. Save this table; it is the whole migration in one screen.

#	Claude Code	Codex equivalent	Verdict
1	`CLAUDE.md` memory	`AGENTS.md` (or fallback filename)	Transfers
2	`.mcp.json` (JSON)	`[mcp_servers.*]` in `config.toml`	Transfers, reformat
3	`.claude/skills/`	Codex skills (`[[skills.config]]`)	Transfers
4	`.claude/commands/`	Codex slash commands / prompts	Transfers, re-author
5	`.claude/agents/` (Markdown)	`.codex/agents/*.toml` files	Reshapes
6	`settings.json` (JSON)	`config.toml` + profiles (TOML)	Reshapes
7	`permissions.allow/ask/deny`	`approval_policy` + `sandbox_mode`	Breaks
8	`hooks` (PreToolUse, Stop, …)	`[[hooks.*]]` in `config.toml`	Reshapes
9	`ConfigChange` hook	none	No equivalent
10	`ANTHROPIC_BASE_URL` endpoint	`[model_providers.*]`	Transfers
11	`outputStyle`	none	No equivalent
12	Anthropic Claude models	OpenAI models only	Dead end (see fix)

Rows 9 and 11 are cosmetic. You will not miss outputStyle, and ConfigChange only matters if you built automation that reacts to a config file changing mid-session. Row 12 is the one that stops people, and it has a clean fix that most migration guides skip.

Decision Frame: When to Migrate (and When to Stay)

Migrate when your work is task-shaped and you want tighter sandboxing; stay on Claude Code when your work is conversation-shaped and hook-driven. The two tools carry different mental models, and the config differences follow from that.

When to Migrate

You run agents non-interactively in CI and want a read-only or workspace-write sandbox as the default posture.
Your team wants one committed config.toml with profiles per risk level, instead of a settings.json plus a pile of settings.local.json overrides.
You want OpenAI's current Codex models (gpt-5.5) as the default driver. The older gpt-5.3-codex was deprecated as a user-selectable Codex model on 2026-05-26, so pick gpt-5.5 or gpt-5.4.

When NOT to Migrate

You depend on ConfigChange hooks or output styles. Those have no home in Codex, so budget rework or stay put.
Your whole workflow is a long interactive pairing session. Claude Code's conversational model fits that better than Codex's task-and-review loop.
You have a large hand-tuned permission allowlist. Codex's coarse sandbox tiers will feel blunt, and porting the intent takes real thought (see Step 5).

The Stop Rule

If your only goal is to try Codex's models against your existing repo, you do not need to migrate config at all. Point Codex at your repo, run /import, and stop. The rest of this guide is for people making Codex their primary tool.

System Requirements

Before you touch config, confirm the four prerequisites below. A stale Codex is the most common reason /import and the [features] blocks silently do nothing.

Codex CLI 0.140.0 or newer. Check with codex --version. The /import command landed in 0.140.0; this guide was tested on 0.142.5.
Your existing Claude Code project, with its .claude/ directory and CLAUDE.md intact. Do not delete it until the migration is verified.
An API key for whichever provider will drive Codex. OpenAI by default, or a gateway key if you are keeping Claude models.
Write access to ~/.codex/. Codex reads ~/.codex/config.toml on every invocation and, in trusted projects, .codex/config.toml at the repo root.

The migration path looks like this end to end:

flowchart LR
    A[Audit CLAUDE.md + settings.json] --> B[Run codex /import]
    B --> C[Review conflict report]
    C --> D[Hand-fix permissions + hooks]
    D --> E[Add model_provider for Claude models]
    E --> F[Test with a read-only profile]

Step-by-Step: Mapping Every Config Surface

Run the automated importer first, then walk the five surfaces it cannot fully handle. Do not skip the manual passes; the importer is honest about what it leaves behind, but it does leave things behind.

Step 1: Run the Importer

Start Codex in your project and import.

cd my-project
codex
# then, inside the session:
/import

Codex 0.140 added /import for selectively pulling setup, project configuration, and recent chats from Claude Code, per the OpenAI Codex changelog. Pick the surfaces you want. Expected result: a populated ~/.codex/config.toml, an AGENTS.md draft, and a short report listing anything it skipped or flagged as a conflict.

Step 2: Instructions, CLAUDE.md to AGENTS.md

Codex reads AGENTS.md, not CLAUDE.md. If the importer did not already create one, either rename your file or tell Codex to keep reading the old name.

# ~/.codex/config.toml
project_doc_fallback_filenames = ["AGENTS.md", "CLAUDE.md"]
project_doc_max_bytes = 32768

Expected result: your repo-level instructions load into Codex context on the next run. The content carries over unchanged; only the filename and load path differ, which is why the AGENTS.md convention exists across tools in the first place.

Step 3: MCP Servers, JSON to TOML

The MCP processes are identical. Only the declaration changes shape. A Claude Code .mcp.json entry like this:

{
  "mcpServers": {
    "github": {
      "command": "npx",
      "args": ["-y", "@modelcontextprotocol/server-github"]
    }
  }
}

becomes a TOML table in ~/.codex/config.toml:

[mcp_servers.github]
command = "npx"
args = ["-y", "@modelcontextprotocol/server-github"]

Expected result: codex lists the github MCP tools on startup. If a server needs environment variables, add them inline: env = { "GITHUB_TOKEN" = "..." }. Both transports carry over: Codex accepts the same STDIO command-based servers you ran in Claude Code, and it also takes streaming HTTP servers in the same table, so a remotely hosted MCP endpoint moves without spawning a local process.

Step 4: Subagents to .codex/agents/

Claude Code stores subagents as Markdown in .claude/agents/. Codex stores each subagent as its own TOML file, one file per agent, under ~/.codex/agents/ (personal) or .codex/agents/ (project-scoped). Subagents are enabled by default, so there is no feature flag to flip.

# .codex/agents/reviewer.toml
name = "reviewer"
description = "Reviews diffs for correctness and style"
developer_instructions = """
Review the diff for correctness and style. Cite file and line for each issue.
"""

Expected result: the reviewer role becomes available through Codex's subagent workflow, which Codex invokes only when you explicitly ask for it. The prompt body from your old Markdown file moves into developer_instructions; the wrapper is what changes. If you had many subagents, this is the most tedious manual pass, but it is mechanical.

Step 5: Permissions to Sandbox and Approval

This is the surface that genuinely breaks, because the two tools model safety differently. Claude Code uses a per-command allowlist with glob rules. Codex uses two coarse dials: a filesystem sandbox and an approval policy. There is no clean one-to-one mapping, so you port intent, not rules.

Claude Code	Codex intent	Codex setting
`allow: ["Bash(npm run test *)"]`	run commands in the repo without asking	`sandbox_mode = "workspace-write"`, `approval_policy = "on-request"`
`ask: ["Bash(python *)"]`	prompt before risky commands	`approval_policy = "on-request"`
`deny: ["Read(./.env)"]`	block access outside the workspace	`sandbox_mode = "workspace-write"` (blocks writes outside cwd)
Plan mode	look, do not touch	`sandbox_mode = "read-only"`
`--dangerously-skip-permissions`	full autonomy	`approval_policy = "never"`, `sandbox_mode = "danger-full-access"`

# ~/.codex/config.toml, a sane default
approval_policy = "on-request"
sandbox_mode = "workspace-write"

Expected result: Codex runs freely inside the repo and asks before touching anything outside it or reaching the network. The granular per-command control you had in Claude Code does not survive; if you relied on a long, precise allowlist, accept that Codex's model is blunter by design. The full option set is in the Codex configuration reference.

Step 6: Hooks

Codex has hooks now, enabled by default, and they cover most of Claude Code's events. You declare them as array-of-tables blocks in config.toml; to turn the whole system off you would set [features] hooks = false.

# ~/.codex/config.toml
[[hooks.PreToolUse]]
matcher = "^Bash$"          # same idea as Claude Code's PreToolUse matcher

  [[hooks.PreToolUse.hooks]]
  type = "command"
  command = "$(git rev-parse --show-toplevel)/.codex/hooks/pre_tool_use.sh"

Expected result: PreToolUse, PostToolUse, SessionStart, Stop, and even PreCompact/PostCompact fire as they did in Claude Code, once you translate the JSON handler into TOML. The one gap is ConfigChange, which has no Codex event, so any automation you built to react to a config file changing mid-session is the one part of your hook setup that does not come along. For a refresher on what those Claude Code hooks did, see our Claude Code hooks, subagents, and skills guide.

What Has No Equivalent: Claude Models (and the Fix)

The single migration step with no native answer is keeping your Claude models, because vanilla Codex authenticates against OpenAI and drives OpenAI models such as gpt-5.5 and gpt-5.4. There is no built-in switch that selects Claude Opus or Sonnet. If you migrated to Codex for its sandbox and workflow but still want Opus writing your code, you need a bridge.

The bridge is a custom model_provider. Codex will talk to any OpenAI-compatible gateway, so you register one and point a profile at a Claude model. Add the provider to ~/.codex/config.toml:

[model_providers.ofox]
name = "ofox.ai gateway"
base_url = "https://api.ofox.ai/v1"
env_key = "OFOX_API_KEY"
wire_api = "responses"
requires_openai_auth = false

Two details that trip people up. First, set wire_api = "responses". Codex removed support for the older chat protocol in February 2026, so a provider left on wire_api = "chat" now errors on startup; ofox serves a Responses-compatible endpoint under the same /v1 base URL, so responses is what actually connects. Second, set requires_openai_auth = false so Codex stops expecting an sk- key prefix. Then create a profile file at ~/.codex/claude.config.toml:

model = "anthropic/claude-opus-4.8"
model_provider = "ofox"

Run it with codex --profile claude. Now Codex's task loop and sandbox drive Anthropic's anthropic/claude-opus-4.8, and swapping model = "openai/gpt-5.5" in a second profile lets you A/B the two without changing auth. The step-by-step for the provider block, including retries and headers, is in our walkthrough on custom model providers in Codex, and the full ofox docs cover the key setup. This is the one migration surface where a gateway is not a convenience but the only way to keep what you came for.

Common Errors During Migration (and Fixes)

Six failures cover almost every stuck migration. The pattern is the same each time: a Claude Code assumption that Codex does not share.

Symptom	Cause	Fix
Codex ignores your `CLAUDE.md`	Codex reads `AGENTS.md`	Rename it, or set `project_doc_fallback_filenames`
Custom provider returns `401`	Codex expects an `sk-` key	Add `requires_openai_auth = false`
Codex errors on startup: `chat` wire API deprecated	`wire_api = "chat"` was removed in Feb 2026	Set `wire_api = "responses"`
Subagents do nothing	No agent file, or you never asked for one	Add a `.codex/agents/NAME.toml` file; Codex spawns subagents only on explicit request
Hooks never fire	Wrong event name or `matcher` regex	Fix the event name / `matcher`; hooks are on by default, so no flag is needed
A command your allowlist permitted now stops	Sandbox stricter than the old rule	Widen `sandbox_mode` or use `approval_policy = "on-request"`

If a project's .codex/config.toml is being ignored entirely, check that the project is marked trusted. Codex only loads project-scoped config in trusted directories, and it will not let a project file override provider, auth, or profile selection.

Team / Multi-Developer Migration

For a team, the migration is cleaner than the solo case, because Codex collapses two Claude Code files into one committed config. In Claude Code you shipped a .claude/settings.json for the team and let each developer keep a gitignored .claude/settings.local.json. In Codex, you commit a single .codex/config.toml at the repo root and let each developer select a profile.

Concern	Claude Code	Codex
Shared team config	`.claude/settings.json` (committed)	`.codex/config.toml` (committed, trusted repos)
Personal overrides	`.claude/settings.local.json`	a personal profile file in `~/.codex/`
Shared instructions	`CLAUDE.md`	`AGENTS.md`
Risk posture per run	permission allowlist	`--profile strict` vs `--profile fast`

The team payoff is the same gateway trick from the last section, applied once. Register one model_provider in the committed config, hand every developer the same OFOX_API_KEY scheme through your secret manager, and the whole team routes through one endpoint with one billing view, whether they run openai/gpt-5.5 or anthropic/claude-opus-4.8. That single-endpoint routing is the concrete reason a shared gateway beats per-developer OpenAI keys; the config detail lives in our config.toml deep dive, and installation basics are in the Codex install guide.

Migrating your tooling to Codex should not mean giving up the models you migrated for, and with one provider block it doesn't.

Advanced: Profiles for CI, Local, and Review

Profiles are where Codex pays back the migration effort, because they replace the Claude Code habit of juggling settings.json against settings.local.json. A profile is a separate file under ~/.codex/, and you select it per run with --profile. Nothing changes globally until you decide it should.

Create three files for three risk postures:

# ~/.codex/ci.config.toml
model = "gpt-5.5"
approval_policy = "never"
sandbox_mode = "read-only"

Run automated review in CI with codex --profile ci, and it can read everything but change nothing. Keep a local.config.toml at workspace-write for day-to-day work, and the claude.config.toml from the last section that swaps the driver to anthropic/claude-opus-4.8 when you want Anthropic's model on a hard problem. The base config.toml holds the shared pieces, providers, MCP servers, and hooks; each profile overrides only the two or three keys that differ. That single-file discipline is what makes the Codex setup easier to reason about than the Claude Code scope stack, once the migration is behind you.

FAQ

Can I use Claude models in Codex CLI? Not with vanilla Codex, which is OpenAI-only. Register an OpenAI-compatible gateway as a model_provider and point a profile at anthropic/claude-opus-4.8. That is the single surface with no native equivalent.

Does Codex CLI read CLAUDE.md? Not by default. It reads AGENTS.md. Add project_doc_fallback_filenames = ["AGENTS.md", "CLAUDE.md"] to keep the old file, or rename it.

How do I import my Claude Code settings into Codex? Run codex, then /import. Codex 0.140 added a selective importer for setup, project config, and recent chats. It does most of the work and reports the rest.

Does Codex CLI have hooks like Claude Code? Yes, and they are on by default. Declare [[hooks.Event]] blocks for events including PreToolUse, PostToolUse, SessionStart, Stop, PreCompact, and PostCompact. The only Claude Code hook with no equivalent is ConfigChange.

Can Claude Code and Codex share the same MCP servers? Yes. The MCP processes are identical. Only the declaration moves, from JSON in .mcp.json to TOML under [mcp_servers.NAME].

Do I have to rewrite my Claude Code subagents for Codex? You re-declare, not rewrite. The prompt body carries over; the wrapper moves from Markdown in .claude/agents/ to a standalone TOML file in .codex/agents/. Subagents are on by default, so there is no flag to enable.

Is the AGENTS.md file the same as CLAUDE.md? Same job, different name. AGENTS.md is a cross-tool convention; CLAUDE.md is Claude Code's own memory file. Content transfers directly.

Originally published on ofox.ai/blog.

Claude Sonnet 5 vs Opus 4.8 (2026): 60% Cheaper on Paper

Owen — Wed, 01 Jul 2026 09:46:31 +0000

Claude Sonnet 5 vs Opus 4.8 (2026): 60% Cheaper on Paper

TL;DR Anthropic released Claude Sonnet 5 on June 30, 2026 at introductory pricing of $2/$10 per million tokens, substantially below Opus 4.8's $5/$25 (standard rate after August 31 is $3/$15, still 40% lower). On capability, Opus 4.8 maintains leads in SWE-bench Pro 69.2% vs 63.2% and approximately 6.6-point no-tools reasoning advantage. Two factors narrow the price gap: a new tokenizer producing roughly 30% more tokens than Sonnet 4.6, and adaptive thinking enabled by default, which Artificial Analysis estimates at approximately 15% higher cost per agentic task than Opus 4.8. The headline claims 60% savings. The actual invoice depends on workload characteristics. Below: complete pricing math, benchmark comparisons, two sample monthly invoices, and a routing strategy employing both models.

Claude Sonnet 5 advertises 60% below Opus 4.8, but adaptive thinking and a new tokenizer mean an output-intensive agentic workload may cost the same or more. The discount applies to bounded output; the savings diminish on extended agent operations.

TL;DR: Which One Should You Pick?

Most teams should adopt "Sonnet 5 as baseline, Opus 4.8 for demanding tasks." The verdict by use case follows.

Scenario	Pick	Why
High-volume classification / extraction / chat	Sonnet 5	Bounded output, cheaper tokens, 40 to 60% lower bill
RAG answers, summarization, routine code edits	Sonnet 5	Capability suffices; price advantage
Hardest end-to-end agentic coding (SWE-bench Pro tier)	Opus 4.8	69.2% vs 63.2%, fewer iterations to resolve
Long-horizon reasoning, no tools	Opus 4.8	~6.6-point reasoning lead
Output-heavy agent loops with thinking on	Measure first	Sonnet 5's per-task cost can exceed Opus
Cost-sensitive default across mixed workload	Route both	Route inexpensive work to Sonnet 5, complex work to Opus 4.8

This piece provides the evidence backing that matrix, plus a 10-line approach to test both against your own workload before committing.

Quick Specs Comparison

Both models share the same nominal 1M context window and 128K maximum output. Price, tokenizer behavior, and default thinking strategy differentiate them.

Spec	Claude Sonnet 5	Claude Opus 4.8
ofox model ID	`anthropic/claude-sonnet-5`	`anthropic/claude-opus-4.8`
Input (intro, to Aug 31)	$2/M	$5/M
Output (intro, to Aug 31)	$10/M	$25/M
Input (standard, after Aug 31)	$3/M	$5/M
Output (standard, after Aug 31)	$15/M	$25/M
Cached input read	$0.2/M	$0.5/M
Cache write (5 min / 1 hr)	$2.5 / $4 per M	$6.25 / $10 per M
Context window	1M tokens	1M tokens
Max output	128K tokens	128K tokens
Tokenizer	New (about +30% vs Sonnet 4.6)	Prior-generation tokenizer
Adaptive thinking	On by default	On by default

The introductory list pricing ($2/$10 and $5/$25) matches the ofox model pages as of July 1, 2026; the intro versus standard distinction and the August 31 transition derive from Anthropic's official pricing documentation. Note the standard output rate: post-introductory, Sonnet 5 reaches $15/M against Opus 4.8's $25/M, narrowing the output difference from 60% to 40%.

The Price Gap Is Real. Here Is the Exact Math.

Per-token rates show Sonnet 5 is genuinely less expensive, and cheaper across every dimension: input, output, and cached reads.

Through August 31, 2026, Sonnet 5 costs $2/$10 versus Opus 4.8's $5/$25. That represents 60% reduction on input and output. Following August 31, the standard pricing of $3/$15 represents 40% reduction on both lines. Cached input reads at $0.2/M versus $0.5/M save 60%, maintaining regardless of promotional period and proving consequential for cache-heavy production deployments.

Should your workload emphasize input tokens and generate limited, structured output, Sonnet 5 delivers exactly what marketing materials promise. Complications emerge with any workload generating substantial output, encompassing most agentic applications.

One specification deserves emphasis beyond typical treatment: cached input. Sonnet 5 reads cached input at $0.2/M against Opus 4.8's $0.5/M. When prompts include sizable stable content (system directives, tool specifications, recurring document sets), prompt caching represents substantial savings, and Sonnet 5's cache read costs 60% less regardless of promotional pricing. A production retrieval system caching a 20K-token prefix across thousands of queries pays for that prefix at $0.2/M on Sonnet 5 versus $0.5/M on Opus 4.8. The complexity emerges on the write side: Sonnet 5 writes cache at $2.5/M (5-minute) or $4/M (1-hour) versus Opus 4.8's $6.25 and $10, meaning caching becomes economical faster on Sonnet 5, provided hit rates justify the write expense. Below roughly a 1:1 to 1.5:1 read-to-write proportion, caching increases expenses on either model.

The New Tokenizer, and Who It Actually Affects

Sonnet 5 features a new tokenizer. This aspect of the release most frequently surprises on invoices and receives frequent misinterpretation.

The confirmed details, from Anthropic's "What's new in Sonnet 5" documentation: equivalent input produces roughly 30% additional tokens on Sonnet 5 compared to Sonnet 4.6. Community testing indicates variation from 1.0 to 1.35x contingent on content. This does not constitute an API modification (requests, responses, and streaming maintain identical format), but it affects everything measured in tokens:

What you measure	Effect on Sonnet 5 vs Sonnet 4.6
`usage` token counts for the same text	About 30% higher
Text that fits in the 1M window	Less, because each token covers less text
`max_tokens` output budgets	May truncate output sized for 4.6
Per-request cost at the same per-token price	Higher for the same text

A critical misunderstanding to prevent: this 30% measures against Sonnet 4.6, not against Opus 4.8. Anthropic introduced comparable tokenizer evolution earlier, approximately with Opus 4.7, meaning Opus 4.8 operates a similar earlier-generation tokenizer. For identical content, Sonnet 5 and Opus 4.8 approach equivalent token consumption. The tokenizer penalty applies primarily when transitioning from Sonnet 4.6 to Sonnet 5 and repurposing established token limits, not when comparing Sonnet 5 and Opus 4.8.

The operational takeaway: migrating from Sonnet 4.6 requires recount-ing prompts using the token-counting endpoint and reassessing any max_tokens parameters close to projected output before depending on the "equivalent $3/$15 rate" narrative. Equivalent per-token cost, additional tokens, larger bill. The referenced "Claude Code token optimization guide" explains methods for recovering through caching and prompt compression.

Coding Benchmark: SWE-bench Pro and the Real Gap

Coding benchmarks contain noise, yet SWE-bench Pro merits discussion because it evaluates against actual GitHub issues end-to-end. The performance positions follow, including Sonnet 4.6 as reference.

Benchmark	Sonnet 5	Opus 4.8	Sonnet 4.6
SWE-bench Pro (agentic coding)	63.2%	69.2%	58.1%
GDPval-AA v2 (knowledge work, Elo)	1,618	1,615	n/a
No-tools reasoning (gap)	trails by ~6.6 pts	leads	n/a

The SWE-bench Pro and GDPval-AA v2 numbers derive from MarkTechPost's compilation of Anthropic launch materials from June 30, 2026; the roughly 6.6-point no-tools reasoning gap originates from Anthropic's System Card (via digitalapplied.com and codingfleet.com), not MarkTechPost. Treat leaderboard rankings as temporal snapshots; consult Anthropic's Transparency Hub for individual benchmark sources. Two table elements determine most routing decisions.

Opus 4.8 preserves the 6-point SWE-bench Pro advantage. Sonnet 5 at 63.2% represents substantial progress from Sonnet 4.6's 58.1%, though Opus 4.8's 69.2% establishes the benchmark for serious, multi-file agentic tasks. Six points on SWE-bench Pro distinguishes "resolves the issue immediately" from "resolves the issue after retry," and extended agent operations compound this into token expenditure. Tasks operating at that complexity tier find the less-expensive model paradoxically pricier due to retry economics.

Sonnet 5 marginally edges knowledge work. The GDPval-AA v2 economic-work assessment shows Sonnet 5 ahead by three Elo points (1,618 to 1,615). That falls within statistical variance, yet the observation persists: for standard professional responsibilities not requiring maximum-difficulty coding, Sonnet 5 matches a substantially pricier competitor. Anthropic's positioning maintains that Sonnet 5's enhanced-effort mode reaches Opus 4.8 parity on certain tasks while maintaining broader cost-performance flexibility.

Understanding what these benchmarks measure proves valuable before assigning relative weight. SWE-bench Pro evaluates models against actual unresolved GitHub issues end-to-end: the model examines the repository, produces a patch, and that patch either satisfies the project's concealed test requirements or fails. No partial scoring exists, explaining why absolute numbers appear lower versus multiple-choice evaluations. GDPval-AA v2 functions differently. It scores models on genuine economic knowledge tasks (composition, evaluation, structured reasoning) as an Elo score relative to competing models, so a 3-point margin represents essentially a coin flip while a 100-point spread denotes definitive advantage. Combined interpretation yields one unmistakable conclusion: Opus 4.8 performs substantially better at resolving difficult code problems, and Sonnet 5 achieves approximate parity for general professional deliverables. That premise supports routing rather than selecting a single model.

Pricing Math: Two Real Monthly Bills

Marketing price constitutes one figure. Invoices reflect another reality. Two contrasting workloads below demonstrate opposite conclusions, with stated assumptions permitting customization.

Scenario A, high-volume bounded output

Support automation, categorization, data extraction. Assume 300M input tokens/month with 50% sourced from cache, and 30M output tokens/month.

Line	Sonnet 5 (intro)	Sonnet 5 (standard)	Opus 4.8
150M fresh input	$300	$450	$750
150M cached input	$30	$30	$75
30M output	$300	$450	$750
Monthly total	$630	$930	$1,575
vs Opus 4.8	60% less	41% less	baseline

This scenario confirms the discount aligns with promotional claims. Bounded output ensures reduced per-token pricing translates directly to final cost reduction.

Scenario B, agentic coding

Extended multi-phase operations, thinking enabled by default. Assume 5 developers, 25 tasks per day each, 20 workdays (2,500 tasks monthly). Per-task specification: 60K input across both. Output: 12K on Opus 4.8, approximately 30K on Sonnet 5 due to adaptive thinking enabled by default generating increased reasoning per task.

Line	Sonnet 5 (intro)	Sonnet 5 (standard)	Opus 4.8
Input per task (60K)	$0.12	$0.18	$0.30
Output per task	$0.30 (30K)	$0.45 (30K)	$0.30 (12K)
Cost per task	$0.42	$0.63	$0.60
Monthly (2,500 tasks)	$1,050	$1,575	$1,500
vs Opus 4.8	30% less	5% more	baseline

At standard pricing, an output-intensive agentic workload may cost slightly more on Sonnet 5 than Opus 4.8, since additional thinking tokens accumulate on the output line. My reference calculation indicates +5%; Artificial Analysis's independent cost assessment estimated closer to +15% ($2.29 per task versus Opus, late June 2026 measurement). The precise percentage varies with task-specific thinking volume. The trend does not: the advertised discount does not persist with extended agent operations. This constitutes the most crucial insight before deploying agents using Sonnet 5.

When to Pick Claude Sonnet 5

Select anthropic/claude-sonnet-5 when production output stays bounded and transaction scale runs high. Specifically:

Classification, extraction, routing, moderation. Concise responses, massive input throughput, frequently cache-optimized. Sonnet 5's $2/$10 and $0.2/M cached rates reduce these expenses 40 to 60%.
RAG answers and summarization. Information retrieval executes heavy computation; the model produces constrained output. Capability meets requirements; price delivers advantage.
Routine coding. Single-file revisions, boilerplate generation, test formation, code feedback. Sonnet 5's 63.2% SWE-bench Pro exceeds requirements for non-frontier effort.
Chat and assistant interfaces. User exchanges involve concise turns; Sonnet 5's velocity and rate align more favorably than Opus-category solutions.

When to Pick Claude Opus 4.8

Select anthropic/claude-opus-4.8 when challenge degree justifies premium cost relative to first-attempt failure:

Frontier agentic coding. The 6-point SWE-bench Pro advantage represents the difference between single versus repeated attempts. Complex multi-file problems resolve with fewer iterations on Opus 4.8, meaning reduced token consumption. The model receives comprehensive coverage in the referenced "Opus 4.8 release review."
Complex reasoning without tools. The roughly 6.6-point no-tools reasoning advantage demonstrates as "reasoning persists coherently" during intricate sequential problems.
Output-heavy agent loops where Sonnet 5 measurement shows equivalent or higher pricing. When per-task expense proves identical either way, prefer the model displaying higher benchmark performance.

When Not to Pick Either (and What to Do Instead)

The error involves treating this as an either-or selection. Most production systems handle mixed traffic: significant volume of inexpensive constrained operations alongside a minority of authentically complex tasks. Concentrating everything on one model either overspends on accessible 80% or underperforms on challenging 20%.

The remedy employs routing. Direct inexpensive, high-volume operations to Sonnet 5 and complex work to Opus 4.8, consolidated under unified endpoint architecture permitting model switching as straightforward parameter adjustment, not system redesign. This methodology and corresponding routing signal selection appear in the referenced "Claude Code hybrid routing pattern" writeup. Both models function on equivalent OpenAI-compatible API via ofox, rendering a router a dictionary operation rather than dual SDK integration.

Routing implementation complexity stems not from architecture but from logic: determining pre-execution whether a task merits Opus 4.8 rather than Sonnet 5? Three signals function effectively. Request token volume offers the cheapest proxy, since higher-context submissions typically constitute multi-file, comprehensive tasks benefiting from Opus 4.8. Task classification from application systems (extraction versus open-ended operations) delivers superior accuracy when presently available. Validation fallback operates as backup: execute Sonnet 5 initially, escalate to Opus 4.8 exclusively when cheaper-model output fails verification. Escalation constraint keeps Opus utilization modest, the routing objective, since Opus remains the premium tier deployed minimally.

flowchart TD
    A[Incoming request] --> B{Bounded output?<br/>classification, RAG, chat}
    B -->|Yes| C[anthropic/claude-sonnet-5]
    B -->|No| D{Frontier coding or<br/>long-horizon reasoning?}
    D -->|Yes| E[anthropic/claude-opus-4.8]
    D -->|No, measure it| F[A/B both, pick lower per-task cost]

Try Both via ofox: A/B in 10 Lines

Resolving this definitively requires executing both against your actual workload and analyzing token metrics. ofox presents both models via unified OpenAI-compatible gateway (https://api.ofox.ai/v1), permitting comparison where exclusively the model ID string varies between evaluations. One critical detail: Sonnet 5 rejects non-standard temperature, top_p, and top_k parameters with a 400 response, so maintain default sampling configurations (examples maintain this requirement).

Python: A/B both models in one loop

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="YOUR_OFOX_KEY")

prompt = "Refactor this function to remove the nested loop: ..."
for model in ["anthropic/claude-sonnet-5", "anthropic/claude-opus-4.8"]:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    u = r.usage
    print(model, u.prompt_tokens, u.completion_tokens)

Examine the completion_tokens across each. That metric, multiplied by output expense, identifies where the "budget-friendly" alternative ceases cost advantage.

Node: same shape

import OpenAI from "openai";

const client = new OpenAI({ baseURL: "https://api.ofox.ai/v1", apiKey: process.env.OFOX_KEY });

const prompt = "Refactor this function to remove the nested loop: ...";
for (const model of ["anthropic/claude-sonnet-5", "anthropic/claude-opus-4.8"]) {
  const r = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: prompt }],
  });
  console.log(model, r.usage.prompt_tokens, r.usage.completion_tokens);
}

Execute this against 20 to 30 representative cases, aggregate input and output tokens per model, and apply rates from the specification table. That computation exceeds any benchmark for determining appropriate model routing. Complete Claude pricing evaluation appears in the referenced "Claude API pricing guide."

Migration Gotchas: What Breaks Moving to Sonnet 5

Sonnet 5 functions as structural replacement for Sonnet 4.6, but three behavioral alterations trigger 400 responses when existing code assumes 4.6 defaults. These likewise apply relative to Opus 4.8 code predominantly.

Change	Old behavior	On Sonnet 5
Sampling params	`temperature`/`top_p`/`top_k` accepted	Non-default values return 400
Manual extended thinking	`budget_tokens` accepted on some models	Returns 400; use adaptive thinking + `effort`
Default thinking	Off unless requested (4.6)	Adaptive thinking on by default; pass `thinking: {type: "disabled"}` to turn off
`max_tokens` sizing	Tuned for 4.6 token counts	May truncate; new tokenizer emits more tokens

The max_tokens element represents the concealed failure vector. Output limits calibrated against Sonnet 4.6 generate additional tokens for equivalent content on Sonnet 5 and may reach ceilings mid-generation. Increase budgets or incomplete responses ship. A new protective mechanism warrants awareness: Sonnet 5 introduces initial-release cybersecurity barriers, yielding successful HTTP 200 with stop_reason: "refusal" rather than fault states, necessitating explicit stop-reason handling.

Adaptive thinking drives the most substantial billing modifications, accompanied by configuration control. Replacing the earlier budget_tokens parameter, Sonnet 5 supplies an effort setting (low, medium, high) adjusting reasoning intensity relative to token economics. Should Sonnet 5 migration for Opus 4.8 operations expect savings yet invoices arrive flat, first investigate lowering effort on operations not requiring intensive reasoning. Maximum effort categorizing information represents pure inefficiency, accounting for substantial surprise expense in case B. Calibrate effort deliberately per application pathway rather than defaulting all queries.

The successful migration validation does not depend on benchmark outcomes. It centers on completion_tokens: test both models on your operations, permitting token volume, not promotional pricing, to establish routing.

FAQ

Is Claude Sonnet 5 better than Opus 4.8? Performance varies by application. Opus 4.8 dominates SWE-bench Pro (69.2% versus 63.2%) and logical reasoning (roughly 6.6-point advantage). Sonnet 5 surpasses professional knowledge tasks (GDPval-AA v2: 1,618 to 1,615) and offers superior value. Sonnet 5 serves as appropriate baseline; Opus 4.8 merits premium investment on maximally difficult assignments.

How much cheaper is Claude Sonnet 5 than Opus 4.8? 60% reduction during introductory window ($2/$10 through August 31, 2026), 40% reduction at subsequent $3/$15 tier. Cached input costs 60% reduction consistently ($0.2/M versus $0.5/M).

Does Claude Sonnet 5 use a new tokenizer? Affirmative; it generates roughly 30% additional tokens compared to Sonnet 4.6 for equivalent content. This represents no API modification, yet necessitates prompt recalculation and max_tokens reconsideration when transitioning from 4.6.

Why does Claude Sonnet 5 cost more per task than the price suggests? Adaptive thinking functions by default, generating surplus output tokens per operation. Artificial Analysis approximated roughly $2.29 per operation, approximately 15% exceeding Opus 4.8 on their agentic assessment.

Is Claude Sonnet 5 good for coding? Satisfactory for general coding (63.2% SWE-bench Pro, elevated from 58.1% on Sonnet 4.6). Direct most difficult agentic challenges to Opus 4.8.

Should I switch from Opus 4.8 to Sonnet 5? Transition the high-volume limited-output portion and cut that expense 40 to 60%. Maintain Opus 4.8 for complex operations. Apply routing rather than comprehensive replacement.

What is the context window of Claude Sonnet 5? 1M tokens, 128K maximum output. The new tokenizer means that capacity retains less actual content than equivalent specification on Sonnet 4.6.

Can I set temperature on Claude Sonnet 5? Negative. Non-standard temperature, top_p, or top_k triggers a 400 response. Eliminate them and influence output via system guidance.

Sources Checked for This Refresh

Anthropic, "What's new in Claude Sonnet 5" documentation (tokenizer, behavioral modifications, pricing), confirmed July 1, 2026: https://platform.claude.com/docs/en/about-claude/models/whats-new-sonnet-5
Anthropic, "Introducing Claude Sonnet 5" announcement, June 30, 2026: https://www.anthropic.com/news/claude-sonnet-5
Anthropic Transparency Hub (individual benchmark information): https://www.anthropic.com/transparency
MarkTechPost benchmark compilation (SWE-bench Pro, GDPval-AA v2 only), June 30, 2026
Anthropic System Card via digitalapplied.com and codingfleet.com (no-tools reasoning gap, roughly 6.6 points)
Artificial Analysis cost-to-run assessment ($2.29/operation), late June 2026 measurement
ofox model pages for anthropic/claude-sonnet-5 and anthropic/claude-opus-4.8 (introductory list pricing $2/$10 and $5/$25, context specification), verified July 1, 2026; introductory/standard classification and August 31 changeover per Anthropic's pricing documentation

Originally published on ofox.ai/blog.

How to Choose an AI Model: 3 Questions, Not the Biggest One

Owen — Wed, 01 Jul 2026 09:20:36 +0000

How to Choose an AI Model: 3 Questions, Not the Biggest One

The most common mistake when picking an AI model is reaching for the one with the most parameters and the highest benchmark score.

It feels obvious. Opus beats Haiku, so use Opus. In real projects that logic is usually backwards. A bigger model costs more, runs slower, and (the least intuitive part) overthinks simple work. Ask it to clean up a sentence and it hands you a short essay with three alternatives and a note on edge cases.

The better order is the reverse: get the job working on the smallest model that's good enough, then move up only when you hit a quality ceiling. That isn't a hunch. A recent AWS write-up sums it up in four words: "Start small. Justify up."

Why "bigger is better" is a trap

Model size is really a difference in parameter count. More parameters means more variables the model can hold at once, which helps on complex, ambiguous, multi-step problems. That capability has a price, and on simple tasks you never earn it back:

Cost. Within the same vendor, a flagship model often costs tens of times more per token than its light version. At tens of thousands of calls a day, that gap decides whether the project is sustainable.
Latency. Bigger models emit tokens slower. For real-time chat or autocomplete, "smarter" gets cancelled out by "laggier."
Overthinking. This one is the sneakiest. Hand a flagship model a text-classification job and it may return reasoning, a confidence score, and notes on boundary cases. You wanted one label. Surplus capability on a simple task isn't an advantage, it's noise.

A rough but useful analogy: ask "what's for dinner" and a toddler can't answer, but an adult asks about your budget, your allergies, and how spicy you want it. The adult is stronger, yet all you needed was "the noodle place downstairs." Most AI tasks are noodle-place tasks. They don't need an expert.

Three questions: subtract within a budget

So how do you actually pick? Set a cost ceiling first: at your real call volume, what's the most you can spend per month. That line bounds your candidates. Then, inside it, ask three questions:

Dimension	Go smaller	Go bigger
Task complexity	Classification, summaries, formatting, extraction	Complex code, long-chain reasoning, legal/medical judgment
Call volume	High-frequency, batch (tens of thousands/day)	Low-frequency, one-off (dozens/day)
Cost of error	A retry fixes it	One mistake is expensive (wrong math, misleading a user)

The more you land in the "go bigger" column, the more a stronger model earns its keep. Otherwise a light model is almost always the better answer. Notice this is subtraction: the default is small, and every step up needs a specific reason, not "the strongest can't hurt."

A few concrete calls: customer-support replies are high-volume and error-tolerant, so a light model plus a fallback is plenty. Code review is complex and low-tolerance, so it's worth a flagship. Long-document summarization isn't complex but needs a big context window, so reach for a cheap long-context model rather than the priciest flagship.

The lazy way: let a tool shortlist for you

You can carry all of this in your head: which model is cheapest, which has the longest context, which is strongest at code. But with 100-plus models and prices that move every week, memory-based selection goes stale fast.

The easier route is a finder tool. OfoxAI built one (ofox.ai/en/model-finder) that follows the same three questions and does the legwork for you:

Pick a use case. Answer "what are you building": coding, AI agents, RAG / long documents, general chat, writing, data extraction, translation, vision, roleplay, image generation, embeddings. Choose the closest one.
Read the ranking. It scores 100+ models on quality, price, and speed and covers 15 popular lists: best for coding, best for agents, best for RAG, cheapest, fastest, best for long context (100K+), and so on.
Copy the shortlist. Each list is ranked. If you don't want to run your own tests, try the top two or three.

It needs no signup, runs in the browser, and pulls live prices, so you're not looking at a six-month-old number. It's basically the three questions turned into a one-minute interaction, which beats guessing off a static leaderboard.

For where a specific model lands on benchmarks and price, pair this with the May 2026 AI model rankings: the finder narrows the field fast, the rankings explain each candidate in detail.

After you choose: one key for every model

Choosing is step one. The mature pattern is tiered routing: simple tasks go to a light model, mid tasks to a mid-tier, and only the hardest slice hits a flagship. You keep quality where it matters and push the bulk of the cost onto cheap models.

That only works if switching models is easy. Registering, topping up, and wiring different auth and billing for each vendor is a special kind of misery. OfoxAI supports 100+ models and is compatible with the OpenAI, Anthropic, and Gemini protocols. Point your existing code at api.ofox.ai/v1 and one key calls all of them, billed per token with no monthly fee. Swapping a model is swapping one string.

For how to wire the routing itself, see one API for every model and why you'd put an LLM gateway in front.

Bottom line

Back to the opening line: don't pick a model by cutting down from the strongest, build up from good-enough.

Default to a light model and get the business logic working.
Use the three questions (complexity / volume / cost of error) to decide which parts deserve an upgrade.
When unsure, open the finder, pick a use case, read the ranking, decide in ten minutes.
Wire it with one key so swapping models stays cheap.

The most expensive model isn't the one that fits you best. Run two or three candidates on your own real prompts and compare the output. That tells you more than any benchmark report, and faster. When you're ready, grab a free API key and start testing.

Sources Checked for This Refresh

AWS, Bigger AI Models Aren't Always Better: Here's How to Actually Choose, verified 2026-06-30
OfoxAI model finder: use-case ranking, quality/price/speed scoring, live pricing, verified 2026-06-30

Originally published on ofox.ai/blog.

Codex "command failed; retry without sandbox": 6 Fixes (2026)

Owen — Mon, 29 Jun 2026 09:28:02 +0000

Codex Asking to "Retry Without Sandbox" on Every Command? The 30-Second Diagnosis

You run Codex, it tries to edit a file or run a command, and you get this:

command failed; retry without sandbox?

Run these three checks in order. The first one that comes back wrong is your fix.

codex --version              # note the version; 0.115–0.118 had regressions
command -v bwrap             # Linux/WSL2: expect a path; empty = sandbox can't start
grep -E 'approval_policy|sandbox_mode' ~/.codex/config.toml   # check your settings

Result	What it means	Jump to
`bwrap` empty on Linux/WSL2	The sandbox cannot launch, so every command fails into the prompt	Fix 1 (install bubblewrap)
`approval_policy = "untrusted"`	You told Codex to ask before every command	Fix 2 (set on-request)
`sandbox_mode = "read-only"`	Edits are blocked by design and escalate	Fix 3 (workspace-write)
Network commands fail (`npm`, `git fetch`)	Sandbox blocks outbound network	Fix 4 (network_access)
Version in 0.115–0.121 range	Known `apply_patch` regression	Fix 5 (pin / upgrade)
macOS, only some commands prompt	Real write/network outside workspace	Fix 6 (widen roots)

This article is about execution and sandbox/approval errors at runtime: the command failed; retry without sandbox prompt and the "every command needs approval" loop. If your problem is codex: command not found right after install, that is a PATH problem, not a sandbox problem; see codex: command not found? 7 fixes for npm install. For the full list of config.toml keys this post touches, the Codex CLI config.toml deep dive is the reference.

What This Prompt Actually Is (Sandbox vs Approval)

Codex runs your model's commands behind two separate controls. People mix them up, and that confusion is half the reason this prompt is so annoying.

The first control is the sandbox. It sets the technical boundary for what a command can touch: which files it can write, whether it can reach the network. There are three modes, and these are the exact value strings the CLI accepts:

read-only: Codex can read files and run commands that do not write
workspace-write: Codex can read and edit inside the current workspace and run routine local commands (this is the interactive default)
danger-full-access: no filesystem or network restriction

The second control is the approval policy. It decides when Codex stops and asks you before crossing the sandbox boundary. The accepted values:

untrusted: ask before running anything
on-request: the model runs routine work itself and asks only when it needs to step outside the boundary (interactive default)
never: never ask; if something is not allowed, it just fails

The official Codex sandboxing docs state the relationship directly: the sandbox defines the technical boundaries, and the approval policy decides when Codex must stop and ask before crossing them. The two work together.

So where does command failed; retry without sandbox? come from? A command ran, the sandbox layer caused it to exit non-zero, and the approval policy reacted by offering to run the same command again outside the sandbox once you say yes. The wording suggests "your code needs more permission," but very often the command would have been fine. The sandbox itself failed to start, or a regression mislabeled a normal edit as a denial.

model wants to run a command
        │
        ▼
  sandbox_mode applies the boundary  ──► command runs clean ──► done
        │
        ▼ (command exits non-zero under the sandbox)
  approval_policy reacts
        │
        ▼
  "command failed; retry without sandbox?"  ──► you approve ──► reruns unsandboxed

Keep that split in mind. Almost every fix below is either "make the sandbox able to do its job" or "tell the approval policy to stop interrupting routine work."

When to Fix This, When to Switch Versions, and When to Just Approve

Before you change anything, decide which bucket you are in. This saves you from rewriting a config that was never the problem.

Fix the config if bwrap is missing, or your approval_policy/sandbox_mode are set to something stricter than you want. This is the majority of cases and the rest of the article covers it.

Switch versions if you are on a release with a known regression and a clean config plus bubblewrap still triggers the prompt on ordinary edits. Several 2026 builds shipped apply_patch regressions; pin to a good one or upgrade past it.

Just approve and move on if the prompt only shows up rarely, on a command that genuinely reaches the network or writes outside your project. That is the sandbox doing its job. Approving once is faster than re-architecting your setup for a one-off.

Stop rule: if you only see the prompt once or twice an hour on real network/out-of-workspace commands, you do not have a bug. Approve it and keep working. The fixes below are for the "every single command" case.

Codex Sandbox and Approval Errors: What Each One Means

Symptom	Most likely cause	Where it bites
`command failed; retry without sandbox?` on every edit	`bwrap` not installed (Linux/WSL2); sandbox can't launch	Linux, WSL2
Same prompt, but only on `apply_patch` edits	Version regression mislabeling normal writes	0.115–0.121 builds
"asks before every command"	`approval_policy = "untrusted"`	All platforms
Edits silently refused / escalated	`sandbox_mode = "read-only"`	All platforms
`npm install` / `git fetch` fail under sandbox	Network blocked inside `workspace-write`	All platforms
Writes to a path outside the repo fail	Path not in `writable_roots`	macOS, Linux
Sandbox startup warning at launch	`bwrap` missing or user namespaces disabled	Linux, WSL2

The single most common root cause on Linux is the first row. The Codex docs are explicit that on Linux and WSL2 you install bubblewrap first; Codex uses the first bwrap it finds on PATH and falls back to a bundled helper that needs unprivileged user namespaces. If neither is available, Codex prints a startup warning, and from then on every sandboxed command fails into the retry prompt. That is exactly the behavior reported in issue #19162, where every file edit failed starting around version 0.115.0, and a maintainer's first question was whether bubblewrap was installed per the sandboxing prerequisites.

Which mechanism enforces the sandbox depends entirely on your platform, and that decides whether you have anything to install at all:

Platform	Sandbox mechanism	Extra install needed?
macOS	Built-in Seatbelt framework	No
Linux	`bubblewrap` (`bwrap`), or bundled helper via user namespaces	Yes, install bubblewrap
WSL2 (Ubuntu)	Linux sandbox path, same as Linux	Yes, install bubblewrap
Windows (PowerShell)	Native Windows sandbox	No

If you are on macOS or Windows PowerShell and still get the prompt on every command, the cause is almost never the sandbox mechanism itself; jump to Fix 2 (approval policy) or Fix 5 (version regression). The "install something" fixes are a Linux and WSL2 story.

How to Fix It (Solutions for Every Setup)

Fix 1 (Linux/WSL2): Install bubblewrap

This is the fix for the "every command needs approval" case on Linux. The workspace-write sandbox needs bwrap to enforce its boundary. Without it, commands cannot run sandboxed, so they fail and escalate.

# Debian / Ubuntu / WSL2 (Ubuntu)
sudo apt-get update && sudo apt-get install -y bubblewrap

# Fedora
sudo dnf install -y bubblewrap

# Arch
sudo pacman -S bubblewrap

command -v bwrap   # expect /usr/bin/bwrap

Restart Codex after installing. The startup warning should disappear and edits should stop prompting. If bwrap is installed but the prompt persists, your kernel may have unprivileged user namespaces disabled, or an AppArmor profile is blocking bubblewrap. Check:

cat /proc/sys/kernel/unprivileged_userns_clone   # expect 1 (or the file absent on newer kernels)

On Ubuntu 25.10 specifically (issue #17134), users hit AppArmor restrictions around bwrap. Recent Ubuntu releases ship an AppArmor policy that restricts unprivileged user namespaces, which is exactly what the bundled helper relies on. If you are on a hardened kernel, you may need to allow the relevant AppArmor profile for bubblewrap; on a normal desktop Ubuntu the apt-get install above is enough, because the system bwrap is allowed by its own profile. The order of preference is: install the system bwrap package first (it carries a working profile), and only touch AppArmor settings if the package is present but namespace creation still fails.

macOS users skip this fix entirely. macOS uses the built-in Seatbelt framework, so the sandbox works without any extra install. If a macOS run prompts on every command, you are looking at a config or version issue, not a missing sandbox binary.

Fix 2: Set approval_policy to on-request

If Codex asks before every command and bwrap is present, your approval policy is too strict. The value untrusted means "ask before running anything," which is correct only if you want to vet each step.

Edit ~/.codex/config.toml:

approval_policy = "on-request"
sandbox_mode   = "workspace-write"

With on-request, Codex runs routine reads, edits, and local commands itself and asks only when it needs to step outside the workspace or reach the network. You can also set it per-run without touching the file:

codex --ask-for-approval on-request --sandbox workspace-write

The short forms are -a for --ask-for-approval and -s for --sandbox, both documented in the Codex CLI command-line reference.

Fix 3: Move off read-only so edits are allowed

If sandbox_mode = "read-only", Codex cannot write at all, so any edit it tries either gets refused or escalates into the retry prompt. For normal coding work you want workspace-write:

sandbox_mode = "workspace-write"

read-only is useful when you want Codex to analyze a repo without changing anything. It is the wrong mode the moment you ask it to edit code, and the retry prompt is the symptom.

Fix 4: Allow network without dropping the sandbox

A frequent overreaction is jumping straight to danger-full-access because npm install or git fetch failed. You do not need to. The workspace-write sandbox blocks outbound network by default, but you can turn it on inside the sandbox:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
network_access = true

That keeps the filesystem boundary intact while letting package installs and fetches through. Reach for danger-full-access only when you genuinely need both unrestricted filesystem and network, and prefer to do that inside a container.

Fix 5: Pin past the apply_patch regression

If bubblewrap is installed, your config is clean, and ordinary edits still prompt, you are probably on a build with the regression. The reports:

Issue #16407 pinned a regression to version 0.118.0, where apply_patch entered a patch-approval loop with the retry prompt, while 0.117.0 worked. Issue #19162 reported the behavior starting around 0.115.0, affecting nearly every file edit. Issue #18079 described the prompt as misleading: bubblewrap and filesystem writes worked, yet apply_patch still asked to retry without sandbox.

If you are stuck on a bad version, pin to a known-good one or move forward to a fixed release:

# pin to a specific version
npm install -g @openai/[email protected]

# or upgrade to latest and re-test
npm install -g @openai/codex@latest
codex --version

Test with a trivial edit after changing versions. If a clean version plus bubblewrap clears it, the regression was the cause, not your config.

Fix 6 (macOS / cross-platform): Widen writable roots

On macOS the sandbox usually works out of the box, so when you do see the prompt it is often a real boundary hit: the command tried to write outside your workspace. Common cases are a build tool writing to a cache directory in your home folder, or a monorepo task touching a sibling package outside the opened directory.

Add the path to writable_roots instead of disabling the sandbox:

sandbox_mode = "workspace-write"

[sandbox_workspace_write]
writable_roots = ["/Users/you/.cache/mytool"]

The [sandbox_workspace_write] table also supports exclude_slash_tmp and exclude_tmpdir_env_var if you need to tighten /tmp and $TMPDIR handling, per the config reference.

A Note on --full-auto and --yolo

Two flags come up constantly in forum answers, and one of them is now a trap.

--full-auto is a deprecated compatibility flag. The CLI reference describes it as deprecated and says to prefer --sandbox workspace-write; Codex prints a warning when you use it. If an old blog post tells you to "just run codex --full-auto," update that habit to --sandbox workspace-write --ask-for-approval on-request, which is explicit about both controls.

--dangerously-bypass-approvals-and-sandbox (alias --yolo) removes both controls at once. It is the right tool only inside a disposable, network-isolated container or VM, because Codex can then run any command with your full permissions. For unattended runs on a machine you care about, the safer combination is:

codex --sandbox workspace-write --ask-for-approval never

That keeps the filesystem boundary while not pausing for approvals, which is usually what people actually want when they reach for --yolo.

Codex Sandbox Issues in 2026: Real Reports

These are the public issues behind the prompt, with their versions and status. All were CLOSED at the time of writing, which means fixes or workarounds landed, but the version numbers tell you which builds to avoid.

Issue	Reported version	Symptom	State
#12888	multiple	Agent edits resulting in "retry without sandbox?"	Closed
#16407	0.118.0 (0.117.0 OK)	`apply_patch` patch-approval loop	Closed
#17134	n/a (Ubuntu 25.10)	AppArmor / sandbox on Ubuntu 25.10	Closed
#18079	n/a	Misleading prompt even when bwrap + writes work	Closed
#19162	0.115.0+	"retry without sandbox" for every command	Closed

The pattern is clear: a cluster of regressions between roughly 0.115 and 0.118 where the apply_patch path over-triggered the prompt, layered on top of the evergreen Linux cause (bubblewrap not installed). If you read only one, #19162 is the canonical "every command" report, and the maintainer response points straight at the sandboxing prerequisites.

How to Confirm Your Sandbox Is Healthy

After applying a fix, verify instead of guessing. A quick loop:

codex --version                         # off the regression range
command -v bwrap                        # Linux: resolves to a path
grep -E 'approval_policy|sandbox_mode' ~/.codex/config.toml

Then start Codex and watch for a sandbox startup warning. No warning plus a trivial edit that applies without a prompt means the boundary is working. If you want Codex to surface its own view of the environment, the CLI ships a codex doctor-style diagnostic in recent builds; run codex --help to see the subcommands your version exposes, since these change between releases.

A practical pattern once you have a setup that works: capture it as a named profile so you are not re-typing flags. The config reference says profile files live next to config.toml as $CODEX_HOME/profile-name.config.toml and you select one with --profile profile-name. Keep a strict default in config.toml and a looser profile file for repos you already trust:

# ~/.codex/trusted.config.toml
approval_policy = "never"
sandbox_mode   = "workspace-write"

Launch it with codex --profile trusted. This keeps your everyday runs safe while giving you a one-flag escape hatch for trusted repos, without ever reaching for --yolo.

When the Sandbox Is the Wrong Layer: Routing Around a Flaky Model Step

Most retry-without-sandbox cases are local: bubblewrap, config, or a version regression. But sometimes the underlying command is fine and the model is the slow or failing part of the loop, and you want a faster or cheaper backend behind the same Codex workflow.

Codex CLI talks to any OpenAI-compatible endpoint, which is why it works against ofox with nothing more than an environment variable. You point Codex at the ofox base URL and key, keep your sandbox and approval settings exactly as above, and route to whichever model you want:

export OPENAI_BASE_URL="https://api.ofox.ai/v1"
export OPENAI_API_KEY="your-ofox-key"
# then run Codex normally; sandbox/approval config is unchanged
codex --sandbox workspace-write --ask-for-approval on-request

This does not change anything about the sandbox prompt; that is a local control. It just means the backend behind the loop is your choice. ofox exposes an OpenAI-compatible API at https://api.ofox.ai/v1 and lists OpenAI models (the GPT-5.4 family and GPT-5.3 Codex) alongside others, so you can keep Codex's local safety controls and swap the model independently. For the full provider setup, the Codex CLI API configuration guide walks through base URL, key, and model selection.

Alternatives When You Want a Different Execution Model

If the sandbox model itself is not the fit for your workflow, these are the realistic options:

ofox-backed Codex. Keep Codex's sandbox and approval controls, point the OpenAI-compatible base URL at https://api.ofox.ai/v1, and choose your model. Best when you like the Codex UX but want backend flexibility. Setup is one environment variable.
--sandbox workspace-write --ask-for-approval never. Same Codex, no prompts, filesystem boundary intact. Best for unattended local runs on a machine you trust.
Disposable container plus --yolo. Full bypass inside an isolated VM or container. Best for throwaway environments where nothing on the host can be harmed.
Other agentic CLIs. Claude Code and Cursor have their own permission models. If you fight the Codex sandbox constantly, a different tool's defaults may suit you better. Compare them in Claude Code vs Codex CLI vs Cursor.

The honest default for most people is the first or second option: keep the sandbox, fix the root cause, and only loosen controls deliberately.

FAQ

The questions above the fold mirror the most common searches around this prompt. The short version is: on Linux, install bubblewrap; everywhere, set approval_policy = "on-request" and sandbox_mode = "workspace-write"; if both are correct, suspect a version regression in the 0.115–0.118 range and pin to a known-good build.

Originally published on ofox.ai/blog.

Kimi K2.7 Code: Does a 30% Token Cut Lower Your Bill? (2026)

Owen — Fri, 26 Jun 2026 03:34:10 +0000

Kimi K2.7 Code: Does a 30% Token Cut Lower Your Bill? (2026)

TL;DR. Kimi K2.7 Code costs the exact same per token as K2.6 ($0.95/M in, $4.00/M out), and its cache reads are slightly worse ($0.19/M vs $0.16/M). So a lower bill rides entirely on Moonshot's claim that the model burns ~30% fewer thinking tokens. That cut is real money only where reasoning dominates your spend. On a reasoning-heavy job the bill drops about 13%, not 30. On an input-heavy job it drops under 1%. Pick K2.7 Code (moonshotai/kimi-k2.7-code) for text-only reasoning work, stay on K2.6 (moonshotai/kimi-k2.6) for images or short-output jobs. The benchmarks behind the hype are all vendor-reported and unverified, so the only number you should trust is your own bill.

TL;DR: Which One Should You Pick?

One-line verdict: if your coding traffic is text-only and reasoning-heavy, K2.7 Code shaves real dollars; everywhere else the "30% cut" mostly evaporates by the time it hits your invoice.

The trap is reading "30% fewer tokens" as "30% cheaper." It isn't. Same per-token price, same context window, marginally worse cache. The savings live in one place only, and you have to qualify for them.

Your workload	Pick	Why
Text-only, reasoning-heavy coding (long thinking traces)	K2.7 Code	Thinking tokens are most of your output spend, so the 30% cut lands hard
Agentic loops with long autonomous runs	K2.7 Code	Reasoning token reduction compounds across many turns
Vision / screenshot / image input	K2.6	K2.7 Code is text-only; an `image_url` block fails on it
Input-heavy, short outputs (RAG, summarize, classify)	K2.6	Output is a sliver of your bill, so a 30% output cut saves under 1%
Heavy cache reuse on repeated context	K2.6	K2.7 Code's cache read is $0.19/M vs K2.6's $0.16/M, so K2.6 is cheaper on cached input
You haven't measured your own thinking/output ratio yet	measure first	The whole decision turns on that ratio; the A/B loop below gives it to you in 10 lines

If you do nothing else, take that last row seriously. Every dollar figure in this post depends on the share of your output tokens that go to reasoning, and that number is specific to your traffic. Vendor benchmarks won't tell you. Your own logs will.

Quick Specs Comparison

Verified against the ofox model catalog on June 26, 2026. Prices are per million tokens.

Spec	Kimi K2.7 Code	Kimi K2.6
ofox model ID	`moonshotai/kimi-k2.7-code`	`moonshotai/kimi-k2.6`
Context window	262,144	262,144
Max output	262,144	262,144
Input $/M	$0.95	$0.95
Output $/M	$4.00	$4.00
Cache read $/M	$0.19	$0.16
Modality	text only	text + image
Architecture	1T MoE / 32B active	MoE
Built-in thinking	yes	yes (thinking / non-thinking modes)
Released	2026-06-12	2026-04-21
License	Modified MIT (open weights)	open weights

Three facts decide everything below:

Per-token price is identical. $0.95 in, $4.00 out, on both. If you priced K2.6 already, you've priced K2.7 Code's per-token rate.
Cache reads are worse on K2.7 Code. $0.19/M versus $0.16/M. If your pipeline reuses a lot of cached context, K2.7 Code is the more expensive model on that line item. Small, but it cuts against the "cheaper" framing.
K2.7 Code is text-only. The detail people miss: the Code variant on ofox does not take images. K2.6 does. There's also a moonshotai/kimi-k2.7-code-highspeed variant at the same price, still text-only.

So price parity plus a worse cache rate means there is exactly one lever that can lower your bill, and it's the thinking-token reduction. The rest of this post is about whether that lever moves your specific invoice.

Coding Benchmark: What Moonshot Reports (and What's Unverified)

Moonshot's launch numbers for K2.7 Code over K2.6 look strong. Here they are, with the caveat attached to every row.

Benchmark	K2.6	K2.7 Code	Reported gain	Verified by a third party?
Kimi Code Bench v2	50.9	62.0	+21.8%	No
Program Bench	48.3	53.6	+11.0%	No
MLS Bench Lite	26.7	35.1	+31.5%	No

Read that last column twice. All three are Moonshot's own proprietary benchmarks. There is no independent reproduction, and as of the June 12 release there were no public results on SWE-bench Verified, LiveCodeBench, or GPQA, the benchmarks the rest of the field actually compares against.

VentureBeat covered the release under the headline that practitioners say the benchmarks don't check out. Researcher Elliot Arledge ran K2.7 Code against K2.6 on KernelBench-Hard, a public GPU-kernel benchmark, and its MoE-kernel score regressed to 0.157 from K2.6's 0.222 on worse tuning. So the picture from outside Moonshot is, at best, mixed, and at worst points the other way on at least one public test.

There's a structural reason to discount these numbers beyond "they're first-party." A vendor benchmark with a narrow score spread can show a big percentage gain off a small absolute move, and a proprietary harness can be tuned, intentionally or not, to the model that ships with it. The benchmark that would actually settle the question for a routing decision is one with a wide spread across models and a public methodology, where a real capability gap shows up as a large gap in score. K2.7 Code wasn't submitted to that kind of test at launch. So you have three impressive percentages and no way to place them against the models you might route to instead.

This matters for cost work specifically. If you're switching to K2.7 Code partly because you expect better output quality (fewer retries, fewer correction rounds), the vendor benchmarks are not evidence you can bank on. Fewer retries would be a real cost saving, every failed attempt is tokens you paid for, but you can't claim that saving off numbers nobody outside Moonshot has reproduced. The honest position: treat K2.7 Code as roughly K2.6-class on quality until your own evals say otherwise, and justify the switch on the token math alone, not on the benchmark deltas.

The Token Math: Where the 30% Actually Lands

Here's the part the marketing skips. The 30% reduction is on thinking/reasoning tokens, and thinking tokens bill as output (completion) tokens. Your input tokens don't move at all.

So the structure of a Kimi bill is:

bill = input_tokens × $0.95/M  +  output_tokens × $4.00/M

where output_tokens = thinking_tokens + visible_tokens

K2.7 Code's claim cuts only the thinking_tokens piece, by ~30%. Everything else stays put. That gives a clean formula for the real saving:

bill reduction ≈ 0.30 × (thinking spend / total spend)

If thinking is your whole bill, you get close to 30%. If thinking is a sliver, you get a sliver. The variable that decides your outcome is the share of your spend that goes to reasoning, and it ranges from near-total (agentic, multi-step coding) to near-zero (long input, one-line answer).

Moonshot's own framing makes this concrete with an agentic example: a 12-hour run dropping from ~2M reasoning tokens to ~1.4M, the 30% figure. That's a vendor example, not a measured result on your traffic, but it shows the shape, reasoning-token-dominated work is exactly where the cut is designed to pay off.

The mistake is generalizing that 12-hour agent run to every job. A summarization call that reads 200K tokens and writes 200 is the opposite profile, and it will see almost nothing. The next section puts dollars on both ends.

You don't have to guess your thinking-spend share, the API tells you. Every response carries a usage object with prompt_tokens and completion_tokens. Thinking tokens are folded into completion tokens, so the share you care about is completion_tokens × $4.00/M divided by the whole bill. Log that across a representative week of real traffic and you'll know exactly where on the 1%-to-26% range you sit, before you change a single model string. That measured ratio, not Moonshot's example, is what decides whether the switch pays.

Pricing Math: Real Monthly Bill

Two worked examples, recomputed from the $0.95/$4.00 rates. No cache hits assumed, so this isolates the thinking-token effect. You can rerun the arithmetic; it's deliberately simple.

Example 1: reasoning-heavy coding job

Profile: 50,000 input tokens, 20,000 output tokens, of which 70% (14,000) is thinking and 30% (6,000) is visible answer. This is the shape of agentic coding, plan, reason, revise.

Line	K2.6	K2.7 Code
Input (50,000 × $0.95/M)	$0.0475	$0.0475
Thinking tokens	14,000	9,800 (−30%)
Visible tokens	6,000	6,000
Output tokens total	20,000	15,800
Output cost (× $4.00/M)	$0.0800	$0.0632
Per-job total	$0.1275	$0.1107

Bill reduction: ($0.1275 − $0.1107) / $0.1275 = 13.2%.

Note what happened. Thinking tokens fell 30% (14,000 → 9,800). Total output tokens fell only 21% (20,000 → 15,800), because the visible answer didn't shrink. And the bill fell only 13.2%, because input tokens, a third of the cost here, didn't move at all. The "30%" headline became 13% by the time it reached the invoice. That tracks the formula: 0.30 × (thinking spend $0.0560 / total $0.1275) = 13.2%.

Scale that to a real workload, 1,000 of these jobs a day, 30 days:

Model	Monthly bill
K2.6	$3,825.00
K2.7 Code	$3,321.00
Saving	$504.00/mo (−13.2%)

$504 a month is worth having. Just don't budget for the $1,147 a naive "30% off $3,825" would have promised.

Example 2: input-heavy job (the cut barely shows)

Profile: 200,000 input tokens, 4,000 output tokens, of which 40% (1,600) is thinking. This is RAG, long-document Q&A, or summarization, big read, short write.

Line	K2.6	K2.7 Code
Input (200,000 × $0.95/M)	$0.1900	$0.1900
Output tokens total	4,000	3,520 (thinking 1,600 → 1,120)
Output cost (× $4.00/M)	$0.0160	$0.0141
Per-job total	$0.2060	$0.2041

Bill reduction: ($0.2060 − $0.2041) / $0.2060 = 0.93%.

Under one percent. The output is a rounding error against the input, so a 30% cut on part of the output is invisible on the invoice. For this load profile, switching to K2.7 Code for cost reasons is pointless, and if you lean on cached input, K2.6's cheaper cache read ($0.16 vs $0.19) makes it the cheaper model outright.

Example 3: the 12-hour agentic run (the high end)

Moonshot's headline example is a 12-hour agentic run where reasoning tokens drop from ~2M to ~1.4M. That's their number, not mine, but it's worth costing because it's the profile that gets closest to the 30% headline. Assume the run also reads about 500K of input over its life and emits ~200K of visible output (tool calls, file edits, final summaries).

Line	K2.6	K2.7 Code
Input (500,000 × $0.95/M)	$0.475	$0.475
Reasoning tokens	2,000,000	1,400,000 (−30%)
Visible output	200,000	200,000
Output cost (× $4.00/M)	$8.800	$6.400
Per-run total	$9.275	$6.875

Bill reduction: ($9.275 − $6.875) / $9.275 = 25.9%.

This is as good as it gets. Reasoning is the overwhelming share of the bill here, so the cut almost fully passes through. Even so, it's 26%, not 30%, because the input and visible output don't move. Run 20 of these a day for a month and the gap is real:

Model	Monthly bill (20 runs/day × 30 days)
K2.6	$5,565
K2.7 Code	$4,125
Saving	$1,440/mo (−25.9%)

If your traffic genuinely looks like long autonomous agent runs, K2.7 Code earns its keep. The further your load drifts from that profile toward Example 2, the less it does.

The three examples bracket the real world. Your bill reduction lands somewhere between ~1% and ~26% depending on how reasoning-heavy your traffic is, and a typical mixed coding workload sits around the 13% middle. The closer your output is to all-thinking, the closer you get to the headline; the more your bill is input, the less you save.

The Cache Line Item Cuts Against K2.7 Code

One more number the "30% cheaper" story ignores: cache reads. K2.7 Code bills cached input at $0.19/M; K2.6 bills it at $0.16/M. That's a 19% premium on every cached token, on the one model that's supposed to be the cheaper choice.

It matters whenever you reuse context. Code-review loops over the same repo, multi-turn agent sessions that re-send a system prompt and codebase, RAG over a stable corpus, all of these hit cache on most of their input. Take a 300K-input job at 80% cache hit, output held equal between the two models so we isolate the cache effect:

Line	K2.6	K2.7 Code
Fresh input (60,000 × $0.95/M)	$0.0570	$0.0570
Cached input (240,000)	× $0.16/M = $0.0384	× $0.19/M = $0.0456
Input cost	$0.0954	$0.1026

K2.7 Code costs $0.0072 more per job on input alone. Over 1,000 cache-heavy jobs a day for a month, that's about $216/mo extra that the thinking-token savings have to overcome before you break even. On a job profile that's heavy on cached reads and light on reasoning output (the Example 2 shape with caching added), K2.7 Code can end up the more expensive model. Worth checking against your own cache-hit rate before you assume "newer = cheaper."

When to Pick K2.7 Code

Pick moonshotai/kimi-k2.7-code when all of these hold:

Your work is text-only. No images in the loop.
Your jobs are reasoning-heavy, meaning long thinking traces relative to the visible answer. Agentic coding, multi-step debugging, planning-heavy tasks.
You're not leaning hard on cache reuse (if you are, K2.7 Code's $0.19/M cache read costs more than K2.6's $0.16/M).

That's the profile where the 30% thinking-token cut translates into a double-digit bill reduction. It's a genuine win for that exact shape of work. Use moonshotai/kimi-k2.7-code-highspeed if you want more throughput at the same price; the token math is unchanged.

When to Stick with K2.6

Stay on moonshotai/kimi-k2.6 when any of these hold:

You need image input. K2.7 Code can't do it, full stop.
Your jobs are input-heavy with short outputs. The savings round to nothing (Example 2), and the cheaper cache read makes K2.6 the lower bill.
You rely on non-thinking mode for fast, direct answers. If you're not generating thinking tokens, there's nothing for the 30% cut to reduce.
You've already validated K2.6 quality in production and have no measured reason to expect K2.7 Code does the job better, since the benchmarks supporting that are unverified.

K2.6 is the conservative default. It does everything K2.7 Code does except the reasoning-token diet, plus it takes images and has the cheaper cache.

When NOT to Use Either (and What to Use Instead)

Both Kimi models sit at $0.95/$4.00. That's mid-pack, not cheap. If your driving constraint is raw cost-per-token and the task doesn't need Kimi-class reasoning, neither is the right answer.

For budget, high-volume batch work (classification, extraction, bulk summarization), route to a cheaper tier. DeepSeek V4 Flash lists at $0.14/$0.28, roughly 6x cheaper blended than Kimi.
For hard reasoning where you want a different model family's strengths, GLM-5.2 is the reasoning-tier alternative on ofox.
Mixed traffic across all of the above? Don't pick one model. Route each job class to the cheapest model that clears its quality bar; that beats any single-model choice on cost.

The point of K2.7 Code is a narrow efficiency gain on reasoning-heavy text. If that's not your bottleneck, spend your optimization effort on routing, not on this one model swap. A team paying Kimi's $4.00/M output on bulk classification work is leaving far more on the table than the 13% K2.7 Code could ever return, because the right fix there is a cheaper model entirely, not a leaner version of an expensive one. Match the model tier to the job first; optimize within a tier second.

Try Both via ofox: A/B in 10 Lines

Every number above depends on your own thinking-to-output ratio, and you can measure it directly. Both models share one OpenAI-compatible endpoint and one ofox key, so an A/B is a loop over two model strings. Run your real prompt through both, log the token counts the API returns, and compute the bill on your traffic instead of trusting an estimate.

Python, A/B both models in one loop

from openai import OpenAI

client = OpenAI(base_url="https://api.ofox.ai/v1", api_key="YOUR_OFOX_KEY")

prompt = "Refactor this 200-line module into composable functions: <paste code>"

for model in ["moonshotai/kimi-k2.6", "moonshotai/kimi-k2.7-code"]:
    r = client.chat.completions.create(
        model=model,
        messages=[{"role": "user", "content": prompt}],
    )
    u = r.usage
    bill = u.prompt_tokens * 0.95e-6 + u.completion_tokens * 4.00e-6
    print(f"{model}: in={u.prompt_tokens} out={u.completion_tokens} bill=${bill:.4f}")

Node, same shape

import OpenAI from "openai";

const client = new OpenAI({ baseURL: "https://api.ofox.ai/v1", apiKey: process.env.OFOX_KEY });

const prompt = "Refactor this 200-line module into composable functions: <paste code>";

for (const model of ["moonshotai/kimi-k2.6", "moonshotai/kimi-k2.7-code"]) {
  const r = await client.chat.completions.create({
    model,
    messages: [{ role: "user", content: prompt }],
  });
  const u = r.usage;
  const bill = u.prompt_tokens * 0.95e-6 + u.completion_tokens * 4.0e-6;
  console.log(`${model}: in=${u.prompt_tokens} out=${u.completion_tokens} bill=$${bill.toFixed(4)}`);
}

One gotcha: K2.7 Code is text-only

K2.6 takes images. K2.7 Code does not. The same image_url content block that works on moonshotai/kimi-k2.6 will fail on moonshotai/kimi-k2.7-code:

# Works on K2.6, fails on K2.7 Code (text-only)
client.chat.completions.create(
    model="moonshotai/kimi-k2.6",            # swap to kimi-k2.7-code -> error
    messages=[{
        "role": "user",
        "content": [
            {"type": "text", "text": "What's in this screenshot?"},
            {"type": "image_url", "image_url": {"url": "data:image/png;base64,<...>"}},
        ],
    }],
)

If a job in your A/B set sends an image, keep it on K2.6 and don't route it to K2.7 Code at all.

FAQ

Is Kimi K2.7 Code cheaper than K2.6? No. Per-token prices are identical ($0.95/M input, $4.00/M output). Cache reads are more expensive on K2.7 Code ($0.19/M vs $0.16/M). The only path to a lower bill is the ~30% thinking-token reduction, and only on reasoning-heavy work.

Does a 30% token cut mean a 30% lower bill? No. The cut applies to thinking tokens, which bill as output; input tokens don't change. Real reduction is about 30% times your thinking-spend share. Reasoning-heavy job: ~13%. Input-heavy job: under 1%.

What is the ofox model ID for Kimi K2.7 Code? moonshotai/kimi-k2.7-code on the endpoint https://api.ofox.ai/v1. There's also moonshotai/kimi-k2.7-code-highspeed at the same price. K2.6 is moonshotai/kimi-k2.6.

Does Kimi K2.7 Code accept images? No. The K2.7 Code variant is text-to-text only; an image_url block fails. Route vision tasks to moonshotai/kimi-k2.6, which takes text plus image.

Are Kimi K2.7 Code's benchmark numbers verified? Not independently. The +21.8% / +11.0% / +31.5% gains are all Moonshot's proprietary benchmarks with no third-party reproduction. VentureBeat reported practitioners say the benchmarks don't check out, and a public KernelBench-Hard run showed a regression. Treat them as vendor-reported.

What is the context window on Kimi K2.7 Code? 262,144 tokens (256K) for both context and max output, same as K2.6. It's a 1T-total / 32B-active MoE with built-in thinking, released June 12 2026 under a Modified MIT open-weight license.

When should I switch from K2.6 to K2.7 Code? For text-only, reasoning-heavy coding where thinking dominates output spend. Stay on K2.6 for image input or input-heavy short-output jobs, where the savings round to nothing.

Is there a faster version? Yes, moonshotai/kimi-k2.7-code-highspeed, same $0.95/$4.00 pricing, higher throughput. It doesn't change the token math here.

Originally published on ofox.ai/blog.