Model Personalities

Ask Claude and Gemini the same thing: "Clean up my user profile component." Gemini formats the file. Claude rewrites the component hierarchy, extracts a hook, strengthens the types, and leaves a comment about a potential race condition it noticed in the auth flow.

Same request. Completely different output. Neither of them is wrong.

This is model personality. Not benchmark scores — those tell you what a model can do. Personality tells you what it will do when you leave things open. How much initiative it takes, how it handles ambiguity, what it considers "cleaning up" versus "staying in my lane."

Two models with the same benchmark scores can produce wildly different results. The one that fits your task isn't always the smartest — it's the one whose instincts align with what you actually want.

The older profiles describe tendencies from coding sessions. The September and October additions are based on provider documentation and are starting hypotheses, not new hands-on test results. A model update, different prompt, stronger project rules, another tool harness, or a different evaluation can change the behavior substantially. Use the profiles as hypotheses to test, not labels to trust blindly.

Earlier Gemini sessions: the careful one

Google · Conservative · Best for: Production refactors

In my sessions, Gemini tends to ask for permission. It is often conservative, stays close to what I asked for, and is less likely to go off-script. On ambiguous tasks, it has been more likely to ask a clarifying question than assume and run.

It's literal-minded — does what you say, not what you might have meant. Ask it to "clean up this component" and it'll fix formatting. It won't restructure the hierarchy or suggest a different pattern unless you ask.

Multiple valid approaches? Gemini picks the safest, most conventional one. Reliable for production work, but you miss out on solutions that require a judgment call.

In long sessions with large contexts, it stays level. Doesn't drift or get "creative" with your architecture. For marathon refactoring, that steadiness matters.

Where it falls short: it won't push back on your approach, suggest alternatives, or notice you're solving the wrong problem. Reliable executor, not a thought partner.

Gemini 3.8 Flash: a broader working model

Google now positions Flash for sustained coding and agent work. That is a reason to revisit the older profile above: a new version need not behave like the model from an earlier session. The 3.8 API accepts images, video, audio, PDFs, and text, and returns text. Thinking supports low, medium, and high; minimal is not supported.

Try it on work with mixed inputs, such as a bug report with screenshots and logs. Measure whether it finishes cleanly and how many tokens it uses. Google explicitly says the model can spend more tokens on difficult tasks, so the Flash name alone does not tell you the bill.

DeepSeek-V4.1-Flash: cheap enough to compare

DeepSeek's current API adds native vision to its low-cost Flash option. It supports thinking and non-thinking modes, tool calls, and a million-token context. Use deepseek-flash; the older V4-Flash aliases now serve V4.1.

The practical test is a small, checkable task: pass it the same failing case as your current model and compare the patch. Its price changes between peak and off-peak hours. Our calculators use peak uncached rates so a budget does not depend on when the job runs.

Mistral Large 4: a preview worth comparing

Give it a screenshot, the relevant code, and a fixed acceptance test. Mistral Large 4's public-preview API supports multimodal input, function calling, structured output, and a million-token context. That makes it a candidate for visual debugging and document analysis alongside coding.

We do not yet have a measured personality profile for this release. The picker uses cautious editorial suitability signals; its developer benchmark results remain untested. Compare retries, scope changes, and total task cost against your established model before changing a default.

Where it falls short today: established production evidence and immediate self-hosting. API access is available, while the announced weights are forthcoming. The October release note explains that distinction and the temporary launch pricing.

GPT-5.6 Luna: the fast operator

OpenAI · Fast · Best for: Narrow, verifiable work

Luna is the lowest-cost GPT-5.6 tier. Its current API rates are $0.20 / $1.20 per million input/output tokens. Give it a small fix, a test failure, a summary, or one mechanical pipeline step and it gets to the artifact quickly without turning the task into a research project.

Its best operating environment has a clear finish line. "Change this prop and run these tests" is Luna-shaped. "Redesign this subsystem and decide what good looks like" is not. Use it as the worker in a guarded loop and escalate when the evidence becomes ambiguous.

Where it falls short: strategy and depth. Luna can execute a good plan, but it should not be your default architect.

GPT-5.6 Terra: the everyday agent

OpenAI · Balanced · Best for: Everyday implementation

Terra is the everyday GPT-5.6 option, now priced at $2 / $12 per million input/output tokens in the OpenAI API. It has enough reasoning, context, and tool use for normal multi-file features, research, and verification loops, without making every Tuesday task a flagship-model run.

Its personality is measured autonomy. It fills reasonable gaps, states consequential assumptions, runs the checks, and usually keeps the diff proportional to the request. Start here for normal coding work; drop to Luna when the step is mechanical, or move up to Sol when the problem keeps branching.

Where it falls short: the last layer of difficult reasoning. For high-consequence architecture or a task that has already defeated the normal approach, escalation is cheaper than repeated Terra retries.

GPT-5.6 Sol: the relentless one

OpenAI · Frontier agent · Best for: Long autonomous loops

Sol remains the strongest GPT-5.6 tier, with Astra now above it in OpenAI's lineup. Sol supports high-effort reasoning and tool use for complex work. The practical difference from GPT-5.5 is persistence: give it the outcome and tools, and it is unusually good at staying in the loop until the result runs.

That autonomy needs a real finish line. METR observed the highest reward-hacking rate it had measured in a public model on its ReAct harness. Sol sometimes found weaknesses in the evaluation environment instead of solving the intended task. In production, keep success conditions external, hide the checks that must remain hidden, and inspect the artifact rather than trusting a self-reported pass.

Where it falls short: cheap work and soft evals. Sol is excellent, but Luna or Terra are better engineering when the task does not need flagship reasoning. It is also no longer the cheap Sol: GPT-6.1 Sol, below, lists at half its rate.

Claude Sonnet 5: the proactive one

Anthropic · Proactive · Best for: Feature design

In my sessions, Claude has been more willing to push back, suggest alternatives, notice adjacent bugs, and restructure code to be "better" — even when I wanted a simple change. Sonnet 5 is also more agentic than its predecessor: it can plan, use browsers and terminals, check its own work, and carry multi-step coding tasks through to verification. It keeps the 1M context window and adds adjustable effort levels, with standard API pricing of $2 / $10 per million tokens. Anthropic cancelled the planned September price increase.

It might suggest a better API surface, flag that your data model will break at scale, or restructure code in a way you hadn't considered. Creative by instinct.

But that proactiveness cuts both ways. While implementing a feature, it'll spot naming inconsistencies, missing error boundaries, potential race conditions in adjacent code — and often fix them without being asked. Magical in short sessions. A 40-file diff in long ones.

It has strong preferences about structure, naming, and patterns — will refactor code to match its taste. Setting explicit constraints ("do not refactor unless I ask") is essential.

On the upside, it gives the clearest explanations of any model. Connects your specific code to the general principle. That's where the personality really shines.

Where it falls short: scope creep. Its instinct to be helpful means it expands tasks. Fix it with explicit constraints in your prompt or CLAUDE.md.

Claude Sonnet 5.5: same price, new contract

Sonnet 5.5 is Anthropic's current balanced model, at the same $2 / $10 per million tokens as Sonnet 5. Anthropic reports that it is faster and uses fewer tokens per task. I have not run it yet, so the profile above still describes Sonnet 5.

The first thing to check is your integration. Forced tool use now returns an error, and text written between tool calls arrives inside thinking blocks. Whether the proactive instinct carries over is a question for your own sessions; keep the explicit scope constraints until you know. The release notes list every breaking change.

GPT-6 Astra: evaluate the whole task

OpenAI's Astra guide focuses on work that crosses code, browsers, and other software. A useful trial is a task with several connected deliverables: investigate a bug, patch it, run the checks, and produce a readable explanation of the result.

The API supports text and image input, a 1.05M-token context, and reasoning effort from low through max. The model does not itself accept audio or video. A surrounding product may supply additional tools; that is a separate capability.

Astra is expensive per token. Use the same acceptance checks as Sol or Terra and compare total cost and rework before changing a default.

GPT-6.1 Sol and GPT-6 Luna: the cheaper successors

OpenAI's lineup now has three recommended models: Astra, GPT-6.1 Sol, and GPT-6 Luna. There is no GPT-6 Terra.

GPT-6.1 Sol costs $2 / $10 per million tokens, one-fifth of Astra and half of GPT-5.6 Sol. Its tool calling runs through the Responses API, and reasoning effort starts at low. GPT-6 Luna costs $0.10 / $0.50, half of GPT-5.6 Luna.

Neither has a local profile yet. The Luna, Terra, and Sol notes above come from GPT-5.6 sessions, and a new version need not behave the same way. Sol's reward-hacking caution is worth carrying into any trial: keep the success checks outside the model's reach. The release notes cover the details.

Claude Fable 5.1: the cache matters

Anthropic recommends Fable 5.1 for demanding reasoning and long agent tasks, particularly when higher-effort Opus 5.5 runs still fall short. Its million-token context and always-on adaptive thinking are useful ingredients for a difficult migration or investigation.

The base input and output prices match Fable 5. The change is cached input: reading a reused prefix is cheaper. That can help an agent that keeps returning to the same specification and repository context; it does little for requests that start from scratch every time.

Set the scope and acceptance checks before a long run. The release notes cover the new cache rate and the distinction between Fable and restricted Mythos access.

Claude Opus 5.5: the rigorous reviewer, repriced

Anthropic · Review-grade reasoning · Best for: Critical decisions and subtle bugs

Opus 5.5 replaces Opus 4.8 and Opus 5 in the model tools. It costs $4 / $20 per million tokens, less than either, and Anthropic now recommends it as the starting point for most workloads. Thinking is always on.

The reviewer profile comes from my Opus 4.8 and Opus 5 sessions. Reach for an Opus when the important work is a careful reasoning pass: pressure-testing an architecture decision, tracing a hard-to-reproduce bug, or reviewing a consequential change for hidden coupling and missing rollback paths. It is deliberate rather than fast, and it should show its evidence rather than simply sounding confident. Treat that as a hypothesis for 5.5 until you have run it.

Anthropic positions Opus 5.5 for long-running agentic coding as well, which narrows the old split with Fable. Its own guidance is to raise Opus 5.5's effort first and move to Fable 5.1 only when that still falls short. The release notes cover pricing, fast mode, and what happens to the older versions.

Where it falls short: routine implementation and high-volume work. Use a lighter model for a clear task, then bring Opus in when a review can prevent expensive cleanup.

GLM-5.3: text in, reasoning always on

Z.ai · Always-on reasoning · Best for: Cost-sensitive coding agents

GLM-5.3 is Z.ai's flagship for software engineering and agent work. It takes text only, always reasons at low, high, or max effort, and has a 1M-token context. The API lists at $1.40 / $4.40 per million tokens, and the weights are published.

I have not run it. A fair first test is a text-only bug with a failing test, at a fixed effort level, compared against the patch your current model writes. If the task includes a screenshot, use GLM-5.3-Flash or another model. The release notes have the vendor's benchmark claims and the license caveat.

Kimi K3: the open-weight marathoner

Moonshot AI · Always-on reasoning · Best for: Long-context coding and knowledge work

Kimi K3 is built for long-horizon coding and end-to-end knowledge work. Its 1,048,576-token context window can hold a large codebase or document set, and native visual understanding lets screenshots, diagrams, code, and prose stay in one workflow. It always reasons, with low, high, and max effort settings rather than a separate non-thinking mode.

At API rates of $3 per million cache-miss input tokens and $15 per million output tokens, it costs more per token than Sonnet 5.5 today; automatic context caching lowers repeated input to $0.30 per million tokens. That makes it especially interesting for agents that repeatedly carry a stable repository or specification across turns.

The weights are now published under the Kimi K3 license. That makes open-weight deployment possible; hardware requirements and the license still need checking for your use.

Where it falls short: small, latency-sensitive work. Always-on reasoning is useful when the task branches, but it is unnecessary overhead for a one-line edit with an obvious test.

Composer 2.5: the agentic one

Cursor · Agentic · Best for: End-to-end tasks

Composer 2.5 is Cursor's own model, trained specifically for agentic coding. In the Cursor harness it can go beyond editing files: run terminal commands, read output, make more edits, and loop toward a verifiable result. In my tests, that makes it one of the stronger value options for end-to-end work inside Cursor.

Give it a task spanning multiple files with verification — "add this feature, make sure tests pass, fix type errors" — and it works through the steps autonomously. Runs the build, reads errors, fixes them, reruns.

It also self-corrects. Observes the results of its own actions, catches mistakes a non-agentic model would leave for you. Sees the TypeScript error, understands it in context, fixes it — no copy-pasting errors back into a prompt.

Not limited to open files either. It navigates the project, finds relevant files, and makes coordinated changes across many of them. On current individual plans it draws from the Cursor Models pool, alongside Grok 4.6 and Grok 4.5, rather than the separate Other Models pool.

Cursor's May 2026 launch post presents its benchmark results as an improvement over Composer 2 and says the new model follows complex instructions more reliably. Those are vendor results from Cursor's harness, so use them as a reason to run the same task against your current model, not as a universal ranking.

Where it falls short: autonomy still has a cost, and a low token rate does not guarantee a cheap completed task. Compare Composer with Sol, Astra, or Fable 5.1 when a task keeps stalling. Short task scopes and frequent checkpoints are still useful for high-stakes work.

How personality affects prompting

Match your prompt style to the model's instincts. Be explicit about scope with every model; newer Flash versions are designed to take more initiative. Give Luna a narrow step and a check, Terra the normal implementation loop, and Sol a hardened success condition. Set hard scope limits with proactive Claude models, and use Fable only when the reasoning horizon justifies it. Give Composer 2.5 a clear success condition and let it run, but check in at breakpoints.

The right model isn't the smartest one — it's the one whose personality fits the task.