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.

These profiles describe tendencies I've observed in coding sessions, not fixed traits. 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.

Gemini: 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.

GPT-5.6 Luna: the fast operator

OpenAI · Fast · Best for: Narrow, verifiable work

Luna is the cheapest and fastest GPT-5.6 tier: $1 / $6 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 new daily-driver GPT: competitive with GPT-5.5 at roughly half the token price, $2.50 / $15. 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 is the strongest GPT-5.6 tier and OpenAI's current flagship for complex coding, computer use, science, research, and security work. It leads Terminal-Bench 2.1, can use Max reasoning for difficult problems, and can coordinate subagents in Ultra mode. 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.

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 introductory API pricing of $2 / $10 per million tokens through August 31 before returning to the usual Sonnet rate of $3 / $15.

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 Fable 5: the marathon thinker

Anthropic · Maximum depth · Best for: Architecture and multi-day projects

Fable is what comes after Opus 4.8 when the problem is not just hard but long. Anthropic positions it for ambitious migrations, complex implementations, and asynchronous projects that can run for days. It plans across stages, delegates to subagents, writes tests, challenges its own assumptions, and checks the output against the goal.

It is the best fit when understanding the system is the task: a migration with mixed-version compatibility, a subtle architecture decision, or a project where the rollback plan matters as much as the happy path. At $10 / $50 per million tokens, it should create leverage, not boilerplate.

Fable also has deliberate safety boundaries. Flagged cybersecurity and biology requests can route to Opus 4.8, so it is not simply an unrestricted replacement for every old Opus workflow.

Where it falls short: ordinary implementation. Once Fable has made a decision-complete plan, Terra, Sonnet, or Composer can often execute it for much less.

Claude Opus 5: the rigorous reviewer

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

Opus 5 belongs alongside Fable, not in place of it. Reach for it 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.

Where Fable is the better fit for an expansive, multi-day agent workflow, Opus 5 is the tighter choice for a high-stakes review or a difficult decision that benefits from focused scrutiny. Keep Opus 4.8 available for established workflows and comparisons; the two versions are separate options in the model tools.

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

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 sits near the balanced frontier tier; 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.

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.5, rather than the separate Other Models pool.

Cursor's May 2026 launch results reported 79.8% on SWE-Bench Multilingual and 63.2% on CursorBench v3.1. A later Cursor audit measured 79.15% raw on SWE-Bench Multilingual and 71.60% after correcting reward-hacking contamination, a useful reminder that benchmark claims need scrutiny even when the vendor publishes them. Behaviorally, users on the forum describe it as more willing to collaborate than Composer 2. The lingering gripe is inconsistent thinking depth — sometimes a "please think harder" nudge is needed before it commits to a deep answer.

Where it falls short: autonomy still has a cost, and GPT-5.6 Sol now leads the long autonomous-loop tier. Composer remains the value choice inside Cursor; use Sol when the task must cross more tools and sustain the hardest loop. 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 with Gemini — it won't infer intent. 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.