DEV Community: amdmsz

GPT-5.6 Sol vs Terra vs Luna: which tier should you actually use?

amdmsz — Sat, 11 Jul 2026 22:01:53 +0000

When GPT-5.6 landed as three models instead of one, my first reaction was mild annoyance. Sol, Terra, Luna — great names, zero help when I'm staring at a config file deciding which string to paste into model. So I did the boring thing: I wired all three into the same app, ran a week of real traffic through them, watched the token meter, and wrote down what I learned. This is that write-up — the decision tree I wish someone had handed me on day one.

The 30-second version

Three tiers, same API shape, same features. The only thing that changes is depth vs. cost vs. latency. Official OpenAI list prices, per million tokens:

Tier	Model string	List price (in / out)	My one-liner
Sol	`gpt-5.6-sol`	$5 / $30	The flagship. Reach for it when a wrong answer is expensive.
Terra	`gpt-5.6-terra`	$2.50 / $15	The default that surprised me.
Luna	`gpt-5.6-luna`	$1 / $6	The volume workhorse.

Note the shape of that output column: $30, $15, $6. Output tokens are where the money goes, and they scale 5:1 against input across all three. Keep that ratio in your head — it makes tier choice mostly a question of how much the model talks, not how much you feed it.

Terra is the plot twist

I expected to run Sol everywhere and grumble about the bill. Then I A/B'd Sol against Terra on my actual coding-assistant traffic — diffs, refactors, "why is this test flaky" spelunking. OpenAI's own line is that Terra hits about 97% of Sol's benchmark performance, and honestly? On day-to-day dev work I couldn't feel the missing 3%. Same fixes, same explanations, half the list price.

That reframed the whole exercise for me. The question stopped being "can I afford Sol?" and became "do I have a specific reason to escalate off Terra?" For most requests the answer is no. Terra became my baseline and Sol became the exception I reach for deliberately — not the reverse.

Where Sol still earns its keep for me: genuinely hard reasoning where the cost of being wrong dwarfs the token bill. Architecture reviews, gnarly migrations, research synthesis across a big pile of context. And ultra mode — the 5.6 family can orchestrate parallel sub-agents on complex tasks, and that coordination is exactly the kind of work where the deepest tier pays for itself.

Luna is not a downgrade, it's a different job

Luna is the one people mis-read. It's not "watered-down Sol," it's the tier you point at work where per-token cost dominates and the quality ceiling basically never binds: bulk classification, tagging, extraction, summarizing a firehose of records. When you're doing the same small operation ten thousand times, a dollar of input vs. five dollars of input is the entire P&L. Luna is also the fastest of the three, so it's my pick for anything latency-sensitive — autocomplete, a streaming chat UI — paired with stream: true.

The cache math nobody puts on the slide

Here's the part that actually changed my routing, and it's the reason I'd tell you not to just default to the smallest tier.

GPT-5.6 ships with predictable caching: a prompt prefix is guaranteed to stay cached for at least 30 minutes, and you can drop your own cache breakpoints. Cache reads bill at 10% of the input price. That number quietly rewrites the arithmetic for any prefix-heavy workload.

Think about a RAG setup where every request re-sends the same fat corpus prefix. Without caching you pay full input rate on that prefix every single call. Pin it behind a breakpoint and you pay full rate once per 30-minute window, then 10% on every hit after. Run the numbers on a realistic prefix-to-suffix ratio and Terra-with-cache can land below Luna-uncached on effective per-request cost — while giving you Terra-grade answers. I stopped reaching for the smallest tier reflexively and started modeling the prefix ratio first. Sometimes the "more expensive" tier is the lower-cost system.

My actual routing rules

After all that, here's the decision tree I run in production:

Deep reasoning / high-stakes (architecture, tricky migrations, ultra-mode agent pipelines) → Sol. Output quality wins when a mistake is expensive.
Everyday work (coding assistant, general chat, most product features) → Terra. ~97% of Sol at half the list price; escalate specific request types to Sol only when your evals show the gap is real.
High-frequency / bulk (classification, extraction, summarization, latency-critical UX) → Luna, with stream on where it helps.

The meta-rule: start on Terra, promote to Sol by request-type when evals justify it, route the bulk lane to Luna. Match the workload, not the badge.

Trying all three behind one key (no OpenAI account)

The nice part is that testing this costs almost nothing in effort. I ran all three tiers through byesu — an AI API gateway that speaks the OpenAI-compatible Chat Completions API (and an Anthropic-native /v1/messages endpoint from the same host, same token). One sk- key covers all three GPT-5.6 tiers, so comparing them is a one-string change in a loop, and billing is pay-as-you-go per token — no subscription, no separate OpenAI account to provision.

If you already have OpenAI SDK code, it's a base_url swap:

from openai import OpenAI

client = OpenAI(
    api_key="sk-YOUR_TOKEN",
    base_url="https://byesu.com/v1",
)

prompt = "Refactor this function and explain the trade-offs."

for tier in ("gpt-5.6-sol", "gpt-5.6-terra", "gpt-5.6-luna"):
    r = client.chat.completions.create(
        model=tier,
        messages=[{"role": "user", "content": prompt}],
    )
    u = r.usage
    print(f"{tier:16} in={u.prompt_tokens:5}  out={u.completion_tokens:5}")
    print(r.choices[0].message.content[:200], "\n")

Log usage on every call — that in/out split is the whole game. Once you can see input vs. output tokens per tier on your prompts, the pricing table above stops being abstract and the right tier basically picks itself.

One gotcha worth flagging: when you create the token, put it in the OpenAI GPT group. Wrong group is the usual cause of a "no available channel" error, and the model string has to be exactly gpt-5.6-sol / -terra / -luna.

Bottom line

Default to Terra. Escalate to Sol for the handful of requests where being right is worth $30-per-million output. Push bulk and latency-sensitive lanes to Luna. And before you assume the smallest tier is the lowest-cost one, do the cache math — predictable caching plus 10% reads can flip the ranking entirely. Wire all three behind one key, log your token usage, and let your own traffic settle the argument.

I ran Claude Code on Grok 4.5 — here's the 3-line setup

amdmsz — Sat, 11 Jul 2026 21:27:11 +0000

I've basically lived inside Claude Code for the last few months. Opus 4.8 is my daily driver and I'm not looking to leave it. But when xAI dropped Grok 4.5 on July 8, two things nagged at me enough that I wanted it in the exact same terminal I already had open.

This is the write-up of that afternoon — what pulled me in, the three lines that actually did the job, and where I landed on Grok vs Opus after living with both for a week.

Why I even bothered

Two reasons, and neither of them is "it's the smartest model in the world," because it isn't.

One: it's built for coding. Grok 4.5 is the first xAI model explicitly aimed at coding and agentic work — xAI says it was trained on real developer sessions from Cursor, so the pitch is "long stretches of work inside an actual repo," which is exactly what Claude Code does all day.

Two: the token efficiency number stuck with me. In the third-party write-ups going around, Grok 4.5 finished the same agentic indexing task in roughly 14k output tokens where a frontier flagship burned closer to 67k. When you run an agent that loops and re-reads files for twenty minutes, output tokens are the bill. A model that says the same thing in a quarter of the tokens is interesting even before you look at the per-token rate.

Official rate, for the record: xAI lists Grok 4.5 at $2 / $6 per million input/output, and claims it comes in 60%+ under the current flagship tier. Fewer tokens and a lower rate stacks. That was enough to make me curious.

The thing I kept forgetting

Here's the part that took me embarrassingly long to internalize: Claude Code doesn't actually care what model is on the other end. It's a CLI that speaks Anthropic's /v1/messages protocol to whatever ANTHROPIC_BASE_URL points at. If something answers in that shape, Claude Code will happily drive it.

So I didn't need a Grok-specific client. I needed an endpoint that (a) speaks Anthropic-native and (b) has grok-4.5 sitting behind it. I already had an account on byesu, an API gateway that exposes both an OpenAI-compatible and an Anthropic-native endpoint over a pile of models — pay-as-you-go, and Grok 4.5 was already listed. That's the whole trick: the gateway translates, Claude Code never knows the difference.

The three lines

That's it. Literally three environment variables:

export ANTHROPIC_BASE_URL=https://byesu.com
export ANTHROPIC_API_KEY=sk-your-own-key
export ANTHROPIC_MODEL=grok-4.5

Then, in any project directory:

claude

ANTHROPIC_MODEL=grok-4.5 is the line doing the interesting work — it pins every request to Grok instead of the default Claude model, so you don't have to remember to switch each session. If you'd rather flip between models mid-session, drop that third line and use /model inside the REPL instead.

Two gotchas so you skip my afternoon

No /v1 on the base URL. The Anthropic-native endpoint is the bare root — https://byesu.com, not https://byesu.com/v1. I pasted in a /v1 out of muscle memory from OpenAI-style setups and got a wall of connection errors. Strip it.

If auth won't take, swap the key variable. On one machine my first call kept bouncing on auth. The fix was replacing ANTHROPIC_API_KEY with ANTHROPIC_AUTH_TOKEN (same value) — some Claude Code versions prefer one over the other. Thirty seconds once you know; a genuinely confusing ten minutes if you don't.

Sanity check before you trust it: run claude, ask it something trivial, and confirm the model line in the status bar reads grok-4.5. If it still says a Claude model, your ANTHROPIC_MODEL export didn't make it into that shell — re-source it or reopen the terminal.

The one-line vibe check

It's fast, and it's terse in a way I ended up liking. Grok 4.5 doesn't pad. It reads the files, makes the edit, and moves on with noticeably less "let me explain my reasoning at length" preamble — which, combined with the token-efficiency thing, means the agent loop just feels tighter. For mechanical work — wiring up a route, refactoring a module, chasing a stack trace across a few files — it kept pace with what I'd normally reach for.

Where I actually landed: Grok vs Opus 4.8

I'm not going to tell you Grok 4.5 replaces Opus 4.8, because after a week it clearly doesn't — for me they split by task, not by "better/worse."

Opus 4.8 is still where I go for the gnarly stuff: ambiguous architecture calls, "read this whole subsystem and tell me what's actually wrong," the reasoning-heavy work where I want the model to sit and think. It's the frontier flagship and it feels like it.

Grok 4.5 is where I go for volume. The high-frequency, well-specified, mechanical passes where I know roughly what needs to happen and I just want it done in fewer tokens and fewer words. On independent coding benchmarks it lands in the same neighborhood as the top-tier models at a fraction of the per-task cost, and Artificial Analysis had it at #4 on their intelligence index at launch — which is a lot of "good enough" for the kind of work that eats most of my day.

So it's complementary, not a swap. The nice part of the gateway setup is I don't have to commit: same three env vars, change the model line (or /model), and I'm on whichever one fits the task. Opus for the thinking, Grok for the grinding.

If you want the reference version of the setup — supported models, endpoints, the OpenAI-compatible side — it's documented over at docs.byesu.com. But honestly, the three lines above are the whole story. Export, claude, go.