With the release of 5.6, picking models is now more confusing than ever - we now have 17+ combinations of reasoning and model. People often ask me what to do now, so here’s the intuitive approach to the question “which model/reasoning do I use?” that I use. For some reason people expect a table with exact numbers, but in reality it’s much simpler if you stop thinking of models as black boxes and start thinking of them as people with limited attention.
In short, a model has to manage its attention throughout your session, and there’s a limited amount of it. It’s literally like human attention. You can’t spread your attention across 20 TikTok videos at once while talking to two people in parallel. It’s silly to expect this from a model too - especially a small one.
After that, everything you need to understand breaks down into two independent axes: how many rules the model can hold in its head and how much it needs to think about the task. These are different things, and mixing them up is the main mistake.
Axis one: how many rules the model holds in its head
Let’s start with the fact that among today’s relevant GPT-5.6-level models, neither is going to seriously hallucinate. Not even Luna. But “doesn’t hallucinate” doesn’t mean “will adhere to everything you throw at it.”
Think of Luna as if it has an IQ of 90, one that can hold at most around 5 - 10 simple things/tasks/rules in its head at once. Imagine: you’ve opened a codebase for the first time, you’re handed a checklist of rules, and you sit down to a task. Luna will handle a dozen simple rules from your AGENTS.md plus the task itself. Anything more than that - it’ll start forgetting, skipping, hallucinating and lying. Luna is good for codebase research, template-based QA, mechanical editing of files and documents, reports, finding files/APIs/lines of code. You shouldn’t give it code review, let it write code in situations where decisions need to be made, planning, discussing complex specs with the user.
Terra - this is roughly GPT-5.5 level. Pretty much the same model we’re used to - it can follow rules, but still forgets stuff. By my estimates it holds about three times more in its head than Luna - roughly around 30 rules. It closes out tasks that fit into one or two sessions great, or, given good criteria, 5 to 7. But not across 20 compactions in a row: that’s where it starts to lose information, forget rules, and gets a genuine case of brainrot.
That’s why you can’t trust Terra with a critically important reconciliation. If you’ve got a huge feature and a spec w/ hundreds and hundreds of rules - it won’t be able to check compliance with the spec. Not because it’s dumb, but because it physically can’t hold that much in its head. Terra can be trusted with, for example, code review when there isn’t too much complex architecture in it, executing tasks that are well spelled out and fit into ~5 sessions, analyzing pretty much anything in the codebase, fixing bugs that don’t require major code restructuring, laying out UI.
Sol: It’s obvious you should trust it with planning, design, system design, database architecture - everything where you need to weigh a huge number of different rules and criteria from various angles.
Imagine a teams call: the team lead and developers are collectively thinking about how to implement a new feature for the client - meeting all the requirements while not breaking the legacy. That’s the kind of task you can only entrust Sol with. Terra and Luna will crash into hallucinations here and start making shit up. Bigger models work better under uncertainty, when you’re vibecoding specs at 3 AM and have to correlate them with the current codebase with 20 contradictions for every sentence in your audio prompt.
But the line is thin. It’s all about taste, about making complex decisions, and about following rules under a large number of constraints. Try not to load even Sol with tasks that require following a huge set of complex rules, or very unclear situations where you have to lean heavily on guidelines and work under great uncertainty - for that it’s better to do orchestration through e.g. Kent workflows or subagents/several sessions in a row.
Axis two: how much the model needs to think
The reasoning level is NOT about taste/judgement. What matters here is how complex the task is specifically in terms of dry analysis.
When models don’t have enough tokens for thinking, they degrade heavily in quality and drop to a level worse than a weaker model at a high reasoning level. So I strongly do not recommend ever using Sol low when you can use Terra high. Clearly shown on the graph:
Sol low (45%, $1.02) < Terra high (54%, $1.13).
The result will be worse than a small model’s: it’ll ignore something, forget something, skip or leave something unfinished. The result is the same, but the cause is different - here it wasn’t “attention on rules” that ran out, but the ability to distribute that attention properly across the reasoning space.
Why? A model must not only distribute attention across the tokens in the context - it also has to generate new tokens, so it can then redistribute attention onto those and pick out what’s important (I’m greatly simplifying, but I’m trying to help you get an intuitive understanding). If you just dump a huge context in with no thinking, you get exactly the classic “how many R’s are in the word strawberry”. But even with minimal thinking the model gets a chance to privately break the word down letter by letter, pay attention to each R and answer correctly. It’s the same with real tasks.
So genuinely think from the model’s point of view: Do I need to think about this task, or is it all mechanical here?
- A 10-line plan? There’s not much to think about. Low reasoning is enough.
- “Whip me up a screen based on figma”? Also nothing to ponder, medium.
- A huge algorithm with dozens of edge cases and tests? A database architecture with 100 tables? 24-hour
/goalrun? Here you need both Sol for following rules, and xhigh reasoning, so it has enough tokens to think through and consolidate everything within the reasoning.
I strongly do not recommend turning off thinking completely - it lobotomizes the model (5.5-instant - looking at you). That’s why they’re moving away from this now and enable adaptive reasoning modes by default (but I don’t recommend using that either). Set at least Low, and better yet, as I said above, a smaller model but on high/xhigh.
A separate point is data structure. If the plan is already written out explicitly, indicating which files to change and which functions to add, thinking can safely be dropped to medium or low. That’s what I did in Kent for most default agents: the implementation agent’s reasoning is never higher than medium, because it has nothing to think about. By the way, too high reasoning on a task “just in case” is also harmful.
- First, you burn tokens faster and fill up the context with them, which pushes you faster into the so-called dumb zone of the agent (when the model gets dumber on a large context).
- Second, you waste money and limits for nothing.
- And third, you force the model to ruminate to fully use its thinking budget where there’s not much to think about. The result is the same as with anxious people - they’re scared of everything and everything falls apart in their hands. Look, for example, at GLM 5.2, which has the severe case of overthinking.
My default as of the post date: GPT-5.6 Sol Medium as Project Manager / Product Owner + a workflow in Kent for further planning and implementation. Low, ultra, Max, xHigh I barely use on Sol. Code review is done by Terra High, QA is handled by Terra Medium, the quick agent for finding files and answering questions about the codebase is Luna Medium, and the main planner and architect is Sol High.
And one last thing. There’s no point using 5.5 and older models at all anymore. They just don’t give anything extra, cost more and produce worse results. Always take the newest models.