The lazy take is that GPT-5.6 Luna makes Terra useless. The better take is more useful: Luna should be the default for bounded work, Terra should be the escalation tier, and Sol should be reserved for cases where the marginal capability justifies the burn. If a routing system cannot express that distinction, the routing system is the problem.
Model choice for coding agents is not a beauty contest. It is an operating policy. The question is not “which model is best?” The question is “which model should handle this class of work at this point in the loop, given cost, latency, ambiguity, and blast radius?” A cheap model that clears 80% of routine tasks is more valuable than an expensive model that clears 85% if the extra 5% does not matter. A stronger model that prevents one bad production migration is worth the price if the alternative is an engineer spending a day cleaning up. Both statements can be true.
That is why Luna is interesting. OpenAI's model documentation positions GPT-5.6 Luna as the cost-sensitive member of the family, with listed pricing of \$1.00 input and \$6.00 output per million tokens, a 1,050,000-token context window, and a large maximum output budget. AWS's Bedrock announcement frames Luna as fast and affordable for classification, summarization, routing, and real-time applications. That is not a small niche. That is most of the background work in an agent system.
Terra, meanwhile, is not exposed as dead weight. GitHub's Copilot changelog describes Terra as the balanced default for everyday interactive and agentic coding. That wording matters. It says Terra is not merely a bigger bill. It is the model tier GitHub expects users to reach for when the task is still interactive, still coding-heavy, and still broad enough that the cheap default may not be the safest choice.
Luna is the economic default
Start with price because agent loops multiply cost. A chat completion is one event. An agent run is a sequence: inspect files, reason about the task, call tools, read output, patch, run tests, explain failure, patch again, verify, summarize. Each step can call the model. The difference between \$6 and \$15 output per million tokens looks small in isolation and large when a system runs all day.
Vellum's comparison places Luna at one-fifth of Sol's price and lists Terra at \$2.50 input and \$15 output per million tokens. It also reports Terminal-Bench 2.1 scores of 84.7% for Luna, 87.4% for Terra, and 88.8% for Sol. The exact numbers should be treated as benchmark evidence, not universal truth. But the shape is clear: Luna is much cheaper, while the reported coding-terminal delta to Terra is modest.
That shape creates an obvious policy. Use Luna when the work is bounded, explicit, and easily checked. Classification, extraction, route selection, summarization, short code edits, refactors with tight tests, and first-pass repository orientation all fit. In those cases, paying Terra to rediscover obvious constraints is waste. The verifier, not the model tier, should carry the confidence. If Luna makes a patch and the test suite catches mistakes, the cheap run is doing exactly what it should.
The more subtle benefit is behavioral. Cheap models make users willing to run agents more often. Developers do not ask for help only when they are certain a task deserves the strongest model. They ask when there is friction: a failing test, a confusing function, a stale dependency, a weird diff. If every run feels expensive, the agent becomes a ceremony. If routine runs are cheap, the agent becomes infrastructure. Luna's value is not just lower spend. It is lower hesitation.
Terra is the ambiguity hedge
The argument for Terra begins where boundedness ends. Some tasks are not hard because they are long. They are hard because the objective is underspecified. “Fix the dashboard publish path” is not the same as “change this string.” It can involve git state, deployment aliases, local ledgers, launchd jobs, external credentials, stale browser cookies, and UI state that lies because a backend row is stale. A cheap model can help inspect pieces of that system, but the risk is not token volume. The risk is choosing the wrong abstraction boundary.
This is where Terra can earn its price. A stronger everyday coding model should be used when the agent has to decide what matters. It has to separate symptoms from causes, avoid patching only the visible failure, and preserve operational constraints. If the task crosses modules, has unclear ownership, or can create external side effects, the model needs better judgment before it needs cheaper throughput.
GitHub's framing of Terra as a balanced default for everyday interactive and agentic coding is sensible in that context. It is not saying Terra should handle every tool call. It is saying that when a human is working interactively with an agent on coding tasks, Terra is a safer center of gravity. The user can still route small subtasks to Luna. The planning and integration loop benefits from a model that is less likely to miss the second-order consequence.
The practical difference shows up in recovery. A Luna-first workflow is excellent when every step has a tight check. It is weaker when the check itself is ambiguous. If Vercel deploys successfully but the custom domain points to an old alias, a naive system may mark the article as published because the Git push succeeded. The correct system has to ask whether the live URL changed, whether the mirror ledgers updated, and whether downstream consumers read the same checkout. That is not a pure coding problem. It is operational reasoning.
A useful router has phases, not vibes
The right answer is not to pick Luna or Terra globally. The right answer is a phase router. Use Luna for cheap perception and bounded transformations. Use Terra for planning, integration, and ambiguous repair. Use Sol, or whatever the strongest tier is, for high-risk review, architecture reversals, or failures that survived cheaper attempts.
A concrete policy looks like this. Start a routine task with Luna if the request names the file, the desired behavior is clear, and verification is local. Examples: update a frontend label, add one validation rule, generate a summary, classify inbound items, draft a simple test, or inspect a short error log. Escalate to Terra if Luna cannot identify the root cause in one or two passes, if the task touches deployment or credentials, if multiple repositories are involved, or if the agent has to decide between competing interpretations.
For article generation, Luna should not be asked to produce the final flagship piece alone unless the quality gate is explicit. It can summarize sources, extract claims, and propose outlines. The final drafting pass should have a minimum word count, a style reference, citation constraints, and a validator that rejects short output. The model tier matters less than the contract. A cheap model with a strict 2,200-word field-note requirement may outperform a stronger model that was merely told to “write an article.”
For coding, the same rule applies. The model should not be trusted because it sounds confident. It should be trusted because the workflow forces evidence. Read the relevant files. Patch the shared function, not the symptom. Run tests. Verify the deployed URL, not just the local build. If the model is cheap enough to do this often, Luna has high leverage. If the model is strong enough to notice when the workflow itself is wrong, Terra has high leverage.
Benchmarks are inputs, not routes
The reported benchmark spread makes Luna tempting. If Luna is close to Terra on some agentic benchmarks and dramatically cheaper, why not route everything to Luna until it fails? That can work, but only if failure is cheap and detectable. A failed local test is cheap. A duplicated Substack post is not. A bad dashboard state that says “published” while the live article is missing is not. A force-push would not be.
Benchmarks rarely measure those operational side effects. Terminal-Bench can tell us something about terminal task competence. SWE-style benchmarks can tell us something about coding repair. They do not tell us whether the agent will understand a user's deployment topology, detect a stale custom-domain alias, or refuse to publish a three-minute article when the editorial standard is ten to twenty minutes. Those are system-level requirements.
That is why model routing should include blast radius. Low-blast-radius work can default to Luna. Medium-blast-radius work should use Terra for plan and integration. High-blast-radius work should add a separate verifier, not merely a stronger executor. The verifier can be another model, a deterministic script, a test suite, a live HTTP fetch, or a human confirmation gate. The core principle is that no model tier should be the only thing standing between an agent and an external side effect.
The real value of Luna is volume
Luna's best use is not replacing Terra everywhere. It is increasing the amount of work that can be automated without making the bill or latency feel ridiculous. Every agent platform accumulates small background tasks: normalize queue items, classify opportunities, summarize comments, rewrite titles, extract links, compare ledgers, draft changelog entries, check whether a page is still live. These tasks are numerous, bounded, and mostly verifiable. They should not need a premium model.
Once those tasks become cheap, the system changes shape. You can run more checks. You can leave more breadcrumbs. You can ask for live progress updates without worrying that every heartbeat is expensive. You can have the agent inspect state before answering rather than guessing. The cheap model becomes the connective tissue of the workflow.
Terra then becomes more valuable, not less, because it is reserved for the moments where judgment matters. A system that routes everything to Terra wastes Terra. A system that routes everything to Luna overpromises Luna. A system that lets Luna do the high-volume work and Terra handle ambiguity is the system that will survive production use.
How I would route this in practice
For a real engineering organization, I would start with a boring table rather than a model leaderboard. Luna gets the green path: source summarization, issue triage, queue generation, comment classification, simple test drafting, small frontend copy edits, JSON normalization, link verification, and first-pass research packet cleanup. These jobs have three properties in common. They are bounded, they have local checks, and the cost of a mediocre first pass is low. If Luna is wrong, the system can reject the output and try again without creating external damage.
Terra gets the yellow path: ambiguous bug reports, cross-repository changes, release repair, schema migrations, publish-path debugging, and anything where the agent must decide what the user actually meant. These jobs need more than cheap tokens. They need a model that notices when the apparent failure is downstream of a different state problem. A dirty git worktree, a stale Vercel alias, and a dashboard row stuck in publishing are not three independent bugs. They are one broken delivery chain. That is the kind of thing I would rather have Terra reason about before any tool writes.
The red path should be rare. Use Sol or a separate strongest reviewer when the change has irreversible side effects, when money or production data is involved, or when two cheaper attempts disagree. The point is not prestige. The point is to avoid letting a cheap executor talk itself into a bad external action. If the action is deploy, publish, delete, migrate, or message a user, the model choice should be paired with a deterministic gate and a fresh verification surface.
This routing policy also keeps evaluation honest. Instead of asking whether Luna is “better” than Terra, ask whether Luna is clearing its assigned green-path jobs at an acceptable retry rate. Instead of asking whether Terra is “worth it,” ask whether Terra reduces escalations, bad patches, and operator cleanup on yellow-path jobs. That framing turns model selection from a debate into an operations metric.
Bottom line
Luna is the value tier. That is the point. It should handle bounded, high-volume, latency-sensitive work where checks are cheap and the task is clear. Terra is not useless. It is the escalation tier for ambiguity, integration, and everyday coding sessions where the agent has to choose the right path, not just execute a known one.
The mistake is treating model choice as identity. “I am a Terra shop” and “I am a Luna shop” are both weak policies. The stronger policy is boring: route by task class, verify externally, escalate on ambiguity, and measure cost per accepted change. If Luna clears the task, take the savings. If Terra prevents a bad integration decision, pay for it. If neither can prove the outcome, the workflow needs a better check.
The simplest way to keep this honest is to write the routing decision down next to the task result: model used, reason for using it, verification run, and whether a stronger tier would have changed the outcome. After a few weeks, the pattern is usually obvious. The expensive tier either prevents real cleanup work or it does not. The cheap tier either passes the checks or it does not. Everything else is brand preference dressed up as engineering judgment.
Top comments (0)