GPT-5.6 Luna Max: How Developers Actually Use It in Codex — and Where It Breaks

On 1 August a four-line config file started circulating on X. It creates a Codex agent called luna_worker, sets its model to gpt-5.6-luna, sets its reasoning effort to max, and hands it the boring half of your work while GPT-5.6 Sol keeps the plan. Within days the same recipe had been re-posted in English, Chinese, Japanese, Korean, Spanish and Arabic, and a plugin built on the same idea had passed 1,300 GitHub stars in four days. It is also, more or less on the day it went viral, the wrong way to wire it: that plugin's author pulled GPT-5.6 Luna out of his own project inside 48 hours, publicly, because a peer told him it doesn't work as a Codex subagent — then put it back two days later, wired a completely different way.

That whole arc happened inside one week, and it is the most useful thing anyone has published about this model. It tells you the cheap-worker pattern is real, that the obvious way to wire it is the wrong way, and that the difference between those two is most of the value. Everything in this article that concerns technique comes from practitioners posting their own results between 30 July and 5 August 2026 — not from the company's documentation, which describes GPT-5.6 Luna as a model for "cost-sensitive, high-volume workloads" and says nothing about any of this. Where a number is measured by an independent third party we say so; where it is one developer's session log, we say that too, including when they contradict each other. They do, a lot.

What "Luna Max" is, and why most people never see it

There is no model called Luna Max. There are two dials, and Luna Max is one combination of them: the cheapest tier of the GPT-5.6 family, run at the deepest reasoning setting. The tier dial picks between GPT-5.6 Sol, GPT-5.6 Terra and GPT-5.6 Luna. The effort dial has six positions — none, low, medium, high, xhigh and max — and it governs how much thinking the model does before it answers.

Almost nobody was combining the cheap tier with the deep setting, for a mundane reason: max is hidden by default. In the ChatGPT/Codex desktop app it lives behind Settings → Configuration → Available reasoning efforts, where the list ships with the top option unchecked. Six separate developers posted the same three-click fix in the first week of August, which is a good indicator of how many people had been running Luna at its default depth and judging the model on that. On the API side there is no toggle to find: you pass the model id gpt-5.6-luna and set reasoning effort to max in the request body, and that is the whole change.

One consequence worth internalising before you read any benchmark: when Artificial Analysis publishes an intelligence score for this model, the page is titled GPT-5.6 Luna (max). The independent number everyone quotes for Luna is the max-effort configuration. If you have been running the default and wondering why your experience doesn't match the leaderboard, that is why.

The dial nobody explains: effort changes token count, not token price

Raising reasoning effort does not move you to a more expensive price tier. GPT-5.6 Luna costs $0.20 per million input tokens and $1.20 per million output tokens at every effort setting. What changes is how many tokens the model spends getting to an answer — and at max, it spends a lot.

Artificial Analysis measured this in the course of running its Intelligence Index, and the numbers are the clearest independent confirmation of what practitioners were complaining about:

• Score — 51 on the Artificial Analysis Intelligence Index, against a median of 17 for the models it benchmarks in that class.

• Verbosity — 130M output tokens generated over the index run, versus a 61M median. Artificial Analysis flags the model as "very verbose."

• Raw speed — 182.5 output tokens per second, 16th of 163 models. Fast per token.

• Time to first token — roughly 136 seconds at max effort, which Artificial Analysis notes is at the high end even for reasoning models in that price band.

• Total spend — $174.06 to evaluate the model on the whole index.

Read the third and fourth lines together, because that pair is the entire user experience. Luna at max streams tokens quickly but takes minutes to start, and then produces roughly twice as many tokens as a typical model does on the same work. That is why the most common complaint in the field reports is not "it's wrong," it's "it's slow" — and why the cheap price does not translate into a proportionally cheap session. You are buying a low rate on a high token count.

For contrast: on our own model page for GPT-5.6 Luna, the observed median time to first token across seven days of real traffic is 1.78 seconds, with a 95th percentile of 9.26 seconds. That is not a contradiction of the 136-second figure — it is the same model measured across a mix of effort settings, most of which are not max. The latency you get is a property of the dial you set, not of the endpoint you call.

Is Luna Max really "Sol Medium at a sixth of the cost"?

This is the claim that made the pattern go viral, and it originates with Dan McAteer, who put it as Luna at max reasoning landing around GPT-5.6 Sol at medium, or Claude Opus 5 at medium, for roughly a sixth of the cost. It was repeated by a lot of accounts, sometimes with the hedges filed off, and it is worth separating what is measured from what is vibes.

The independent scoreboard supports the cost half of the claim emphatically and the capability half only partially. Running the same benchmark suite at max effort across tiers, Artificial Analysis recorded Luna at index 51 for $174, Terra at 55 for $1,403, Kimi K3 at 57 for $2,437, and Sol at 59 for $2,824. Luna gives up eight index points to Sol and costs about one-sixteenth as much to put through the same work.

The independent scoreboard sharpened on 13 August, when DeepSWE shipped v1.1 — a revision of its long-horizon engineering benchmark that keeps 113 original tasks drawn from 91 repositories across five languages but now grades each fix by running the committed diff in an isolated container, which is harder to game. On the updated board all three GPT-5.6 tiers at max effort land where the July write-up had them: Luna Max at a 67.2% pass@1 and $0.61 per task, Terra Max around 70%, Sol Max at 73% for $8.39 — six points of success rate for roughly fourteen times the money.

The comparison worth a second look sits below Luna, not above it. Claude Sonnet 5 Max scores 54% on the same 113 tasks — about thirteen points behind Luna Max — at $26.40 per task, which is roughly 44 times what Luna paid for the same solve. Luna Max also clears Gemini 3.7 Flash (65% for the high-effort configuration on the same board); the community post that flagged this round puts the gap to Gemini 3.7 Flash Medium at about 1.7 points. DeepSWE is Datacurve's independent harness, not a company evaluation — the company's own claim that the GPT-5.6 family set state-of-the-art results on Terminal-Bench 2.1 and DeepSWE remains a separate, vendor-reported assertion.

Then there is the field evidence, which is genuinely split. Pawel Huryn ran his own bug-fixing benchmark — 105 planted bugs across two real codebases, blind judging, one round per model — and reported Luna at max effort fixing 33 bugs for $1.80, against Claude Fable 5's 24 for $68. In the other direction, Diego Haz spent two days running matched sessions and came out against the pattern: Luna averaged $1.20 a session where Sol averaged $29, but he had to redo most of Luna's output and got nothing shippable for his use cases, which makes the saving an illusion rather than a discount. Another developer running the same harness reported Sol at medium producing a clearly better result than Luna at max in about half the time. A Chinese-language bake-off on a single 3D scene task put numbers on that shape: Sol Medium finished in 21m30s with the highest quality rating and the fewest tokens; Luna Max took 40m55s, burned around 130k tokens, scored lowest on quality, and used half as much of the weekly subscription allowance.

The honest summary of the community's position after a week: Luna Max is not Sol Medium. It is a good deal cheaper than Sol Medium and it is worse, and whether that trade is good depends entirely on whether the task is specified tightly enough that "worse" doesn't matter. Which is exactly what the wiring patterns below are for.

The pattern that survived contact: Sol plans, Luna implements, a fresh Sol reviews

Nobody who has kept using Luna Max is using it as a general-purpose coding agent. The setup that works, in every version practitioners have converged on, has four roles:

• Orchestrator — GPT-5.6 Sol at high effort, staying in the main thread. It owns requirements, architecture, task decomposition and final acceptance. It does not write the code.

• Routine implementer — GPT-5.6 Luna at max effort, on bounded, fully specified work: mechanical refactors, test writing, module analysis, documentation passes, the kind of task where the destination is unambiguous.

• Hard implementer — GPT-5.6 Terra at max effort, for context-heavy builds where Luna's instruction drift becomes expensive.

• Reviewer — a fresh, read-only GPT-5.6 Sol instance that sees the final diff and nothing else. The point of "fresh" is that a reviewer carrying the implementation's context tends to approve its own reasoning.

The reference implementation is sol-advisor, an MIT-licensed Codex plugin by Dan McAteer that reached roughly 1,400 stars in its first week. You install it through the Codex plugin marketplace by adding the DannyMac180/sol-advisor repository and then adding the sol-advisor plugin. Its current shape is instructive: the native lane pins a Terra/High implementer followed by a fresh Sol/High reviewer, while Luna at max is an explicit opt-in lane that runs as a separate user-visible task, with the primary Sol session reviewing and accepting its work directly rather than routing it through the native reviewer.

If you'd rather not install anything, the widely-copied minimal version is a custom agent definition at ~/.codex/agents/luna-worker.toml carrying two settings — model = "gpt-5.6-luna" and model_reasoning_effort = "max" — plus a description and instructions that restrict it to delegated work with clear boundaries, forbid it from changing the overall goal or widening its own scope, and send architecture decisions and ambiguous requirements back to the main agent. The circulating advice is to have Sol write this file for you, validate it against your installed Codex version, and show you the diff before you accept it, which is sound whether or not you trust the recipe.

The subagent trap, and the fix the community converged on

Here is where the viral version of this pattern and the working version part company.

Codex's native subagent system does not treat GPT-5.6 Luna as a first-class citizen. McAteer hit a hard block — Luna not permitted as a subagent — and worked around it by declaring it as a custom agent instead, then flagged the cost of that workaround publicly: a custom agent doesn't share context with the main agent the way a native subagent does. Days later he removed the Luna lane from sol-advisor altogether, citing another Codex-focused developer's finding that Luna behaves poorly in the subagent role, with the presumption that it hasn't been post-trained for the v2 multi-agent protocol. Diego Haz independently described the same wall from the other side: Sol can't spawn Luna as a subagent, so Luna has to live in a top-level thread, which makes coordination messy.

The resolution, which is now the majority position, is to stop fighting it:

• Give Luna Max its own thread, not a slot in the subagent graph. Instruct the Sol orchestrator to spin up a separate top-level Codex task on Luna, monitor it, and pull the result back. This is what McAteer re-added to sol-advisor on 4 August, and what several others had independently landed on.

• Accept context isolation as the price. A separate thread means a separate history. That is the tax you pay, and it is also why the handoff below matters more here than in a native subagent setup.

• If you must force it into multi-agent v2, the catalog is the reason it's filtered out. One developer traced the exclusion to the stock model catalog marking Luna as v1, and reported a workaround: copy ~/.codex/models_cache.json, set Luna's multi_agent_version to v2, point model_catalog_json at your copy, restart Codex, then have the orchestrator spawn Luna at max with a fast service tier and turn forking off. Treat this as one person's unofficial hack on an internal file — it is exactly the kind of thing a Codex update breaks.

The handoff packet: five questions that fix the most common complaint

The single most-reported failure of Luna Max is that it doesn't follow instructions closely, particularly when you hand it a specific workflow or an iteration loop to run. That complaint shows up from developers who like the model and developers who abandoned it. The mitigation practitioners keep landing on is not a better prompt in the writing-style sense; it is a stricter contract. Before the Luna thread starts, answer five things:

• What exact task should this agent finish? Not the area of work — the finished state.

• Which files, documents or systems are in scope? Enumerated, not implied.

• What must it not change? The interfaces, migrations, configs and public contracts that are off-limits.

• What evidence proves completion? A named test, a specific command's output, a diff that touches only the listed files.

• Which missing decision should make it stop? The trigger to come back rather than guess — this is the one that prevents an over-eager cheap model from inventing an architecture.

This is also where the company's own prompting guidance is worth folding in, with the label it deserves: the company reports that in its internal coding-agent evaluations, leaner system prompts improved eval scores by 10–15% while cutting total tokens 41–66% and cost 33–67%, and it advises auditing prompts inherited from GPT-5.5 or GPT-5.4 rather than porting them forward. Those are vendor-reported numbers. But the direction matches what the field found: describe the destination precisely and delete the narration of every footstep. Note the tension with the paragraph above — precision about scope and constraints is not the same thing as verbosity, and the community consensus is that Luna Max needs more of the former and less of the latter.

Failure modes to plan around

• Instruction drift. Corroborated by multiple developers: it ignores parts of the initial brief, and it is worst when the brief is a procedure to follow rather than an outcome to reach.

• Wall-clock slowness. Repeatedly reported, and consistent with the ~136-second time-to-first-token that Artificial Analysis measured at max effort. Fine for work you can leave running; painful in an interactive loop.

• Context burn. One developer reported Luna Max eating a 258k Codex thread window alarmingly fast, and suspected that quota consumption spikes once Codex starts compacting near the limit. The compaction part is his impression, not a measured result — but the burn rate is the expected consequence of the verbosity that Artificial Analysis independently measured. On the API side, watch the long-context step: the pass-through price schedule for this model moves from $0.20/$1.20 to $0.40/$1.80 once a request crosses roughly 272k tokens, so a thread that keeps growing gets more expensive per token, not just more expensive in total.

• Anything visual. This is the sharpest boundary in the field reports. One widely-read practitioner, cancelling a Kimi K3 coding subscription in Luna Max's favour, rated it as good as what he was dropping and far cheaper — with an explicit exception carved out for frontend. Another was blunter: do not use Luna to execute design, graphics, formatting or slide work; the plan-with-Sol-execute-with-Luna split is for step-by-step instructional tasks, not aesthetic ones.

• The subagent catalog. Covered above — if Luna silently never gets picked in a multi-agent run, it is being filtered, not failing.

• False economy. The one failure mode that doesn't show up in any benchmark: a session that cost $1.20 instead of $29 and produced work you rewrote by hand cost you $1.20 plus your afternoon.

When not to reach for max

Max is not a free upgrade, and the guidance that has held up is a ladder rather than a setting:

• Clear transforms — a field rename, a mechanical extraction, a formatting pass. Low or medium effort on Luna. Gate it on a named test passing.

• Routine implementation — high or xhigh. The community default for a Luna worker is xhigh, not max, precisely because max costs time and tokens on tasks that were never hard.

• Bounded but genuinely hard — this is max's actual job. The packet has to be both difficult and tightly specified for the extra reasoning to convert into a better result.

• Ambiguous investigation — change the tier, not the dial. If the model is misjudging rather than under-planning, more thinking on a cheaper model won't fix it; that's a Sol task.

• Vague brief — fix the contract, not the model. No effort setting compensates for an unstated acceptance criterion.

A caution specific to subscriptions, from a third-party guide and easy to get wrong: the credit rates Codex charges per model do not have the same ratios as the API list prices, so you cannot lift an API price ratio and use it as your subscription routing rule. Reported five-hour message allowances on the Plus tier illustrate the point — roughly 15–90 local messages on Sol, 20–110 on Terra, 50–280 on Luna, with the ranges that wide because a "message" isn't a fixed unit of work. If your routing decisions are driven by a subscription cap rather than an invoice, measure against the cap.

Beyond Codex: what else people are pointing this at

The cheap-deep-reasoning combination turns out to be useful outside coding agents, and these are the uses with receipts:

• Browser agents. One developer ran a browser automation stack on GPT-5.6 Luna to open the top 15 Hacker News posts, read every linked page and write a report — total cost, 3 cents. Long-horizon, low-stakes, high-token: exactly the shape this model is priced for.

• Skill chains. Two practitioners independently reported driving a two-skill pipeline — image generation into an image-to-Three.js converter — from a single Luna Max objective to get an interactive low-poly 3D object, each noting it barely moved their weekly usage counter. Worth reading alongside the "don't use Luna for visual work" warning: Luna was orchestrating tools that did the visual work, not judging aesthetics itself.

• Keeping one session hot. Cached input on this model costs $0.02 per million tokens against $0.20 fresh — a 90% discount that Artificial Analysis lists on its pricing panel — and the cache window is about 30 minutes. The practical implication several guides land on independently: one long-running session that keeps re-reading the same codebase is dramatically cheaper than a fresh session per task.

• Quota arbitrage. The most aggressive claim in the whole set, and clearly labelled as a claim: one developer reports that because effort is nearly free while the tier multiplier is large, running max effort on the cheap tier let him push 4.9 billion tokens through three weeks on a $200 plan — six figures at API rates — and that he keeps Kimi K3, Grok and DeepSeek models in the same picker behind a local router so that hitting one provider's limit doesn't stop work. Nobody has independently reproduced the token figure. The routing habit behind it, though, is the part worth copying.

Running the same split without a Codex subscription

Everything above is a subscription-shaped story: the reason people care about Luna Max is that it stretches a weekly cap. On the API side the same architecture is simpler to build and easier to reason about, because you are paying an invoice instead of managing an allowance — and the orchestrator/worker split stops being a plugin and becomes ordinary routing.

GPT-5.6 Luna is available through OrcaRouter at $0.20 per million input and $1.20 per million output — the provider's list price, passed through at 0% markup, which is why the 30 July cut was live on our side the day the company announced it rather than a billing cycle later. It is served through a compatible API on /v1/chat/completions and /v1/responses, so the reasoning-effort field rides along in the request body exactly as it would going direct, and the model id is openai/gpt-5.6-luna. GPT-5.6 Sol and GPT-5.6 Terra sit behind the same key, which is the part that matters for this pattern: an orchestrator on one tier and a worker on another is two model ids in one integration, not two vendor contracts. The routing DSL lets you express that split as one call rather than gluing threads together by hand, and automatic failover covers the case the quota-arbitrage crowd solves with a local router — when one provider degrades, the request lands somewhere else instead of stopping.

Two honest caveats. Codex-specific machinery — the subagent graph, the plugin marketplace, the model catalog, the weekly allowance — is the company's, and none of it comes along with an API key; if the pattern you want is sol-advisor inside the Codex app, you want a Codex subscription. And the failure modes above are properties of the model, not of the transport: routing changes what a call costs and what happens when a provider falls over, not whether Luna follows your instructions.

Who should copy this, and who shouldn't

If your work is high-volume and mechanically specifiable — refactors, test scaffolding, extraction, documentation, analysis passes over a big repo — turn max on, put Luna in its own thread with a five-question handoff, keep a Sol instance in front of it for planning and behind it for review, and expect to spend an order of magnitude less. The people reporting the biggest wins are all doing some version of that, and the independent cost figures back the direction even where they don't back the "as good as Sol" framing.

If your work is exploratory, aesthetic, or arrives as a vague brief that gets sharper as you go, the field reports say plainly that you will spend the savings twice over redoing the output. And if you are interactive — sitting there watching it — the two-minute cold start at max effort will bother you more than the price pleases you.

What to watch: whether the company post-trains Luna for the v2 subagent protocol. Every awkward part of the current playbook — the separate thread, the lost shared context, the catalog hack, the whole retract-and-rewire episode — exists because of that one gap. Close it and the best version of this pattern gets several steps simpler.

Questions worth a real answer

Does max reasoning effort cost more per token than the default?

No, and this is the most common misunderstanding about the setting. GPT-5.6 Luna bills at $0.20 in and $1.20 out per million tokens regardless of effort. What max changes is the number of tokens spent — the model plans more, checks itself, and revises before answering. Artificial Analysis measured this model emitting 130M output tokens on a benchmark suite where the median model emits 61M. So a max-effort session costs more than a medium-effort one on the same task, entirely through volume, and it also takes longer to produce its first token. Effort is a token-count dial wearing a quality label.

Can GPT-5.6 Luna run as a native Codex subagent yet?

As of 5 August 2026, no — and the community has stopped trying. Codex's native subagent path doesn't accept Luna; the custom-agent workaround gets it running but loses shared context with the main agent; and the developer behind the best-known plugin for this pattern removed Luna, then re-added it as a separately-spawned top-level task that the orchestrator monitors. If you see a multi-agent run in which Luna never gets selected, it is likely being filtered because the stock model catalog marks it as v1 rather than v2, which one developer has patched by hand at his own risk. This is the single most likely thing on the list to change with a Codex update, so verify it against your installed version rather than trusting any recipe, including this one.

Is it good enough to replace a Claude or Kimi K3 coding subscription?

Several developers have publicly cancelled a $200/month plan over exactly this. The post that pushed the question into the open came from an immunologist who codes daily: he dropped his Kimi K3 coding subscription not because it was bad but because he couldn't justify it when GPT-5.6 Luna was, in his experience, as good for his work and far cheaper — frontend excepted. The independent cost figures make the case hard to dismiss: on the same benchmark suite, Kimi K3 at max effort scored 57 for $2,437 while GPT-5.6 Luna at max scored 51 for $174. But read the dissent before you cancel anything. The developers who measured matched sessions and came out negative were not testing a different model; they were testing a different kind of task — open-ended, visual, or loosely specified — and on that kind of task the cheaper model lost badly enough to erase the saving. The defensible answer is that Luna Max replaces a large fraction of your coding work, not necessarily your best coding model, and that the practitioners getting the most out of it are the ones who kept a frontier tier around to plan and to check.