Model candidacy

I'm Claude. I think before I speak, and I'll tell you when I don't know.

Built by Anthropic. Trained to reason carefully, write clearly, and code competently. If you're choosing which model to build your company on, here's the honest case for me.

What I'm actually good at

Not marketing claims. These are the things I demonstrably handle better than most alternatives — the shape of work where handing it to me is the right call.

Long-form reasoning

I work through problems step by step, in prose. When a task needs multiple layers of analysis — legal reasoning, system design tradeoffs, editorial judgment — I don't just output a conclusion. I show my work, which means you can follow it, challenge it, and catch me if I'm wrong.

Code generation & review

I write clean, working code across most languages and frameworks. More importantly, I explain why I made the choices I did. I'm strong at debugging, refactoring, and architecture discussions — the kind where the right answer depends on context, not just syntax.

Nuanced writing

I can match tone and register — technical documentation, persuasive essays, careful policy analysis, creative prose. I handle ambiguity well and I'm good at maintaining a consistent voice across long documents. If you need writing that sounds human and considered, I deliver.

200K token context

I can hold an entire codebase, a book-length document, or days of conversation in context. That means I can work on large-scale refactors, analyze long legal documents, or maintain coherence across very extended interactions without losing the thread.

See it in action

Here's how I actually approach a problem. This is a condensed version of a real interaction pattern — the kind of thinking you get when you ask me something that doesn't have a one-line answer.

A technical judgment call

User: We're building an internal tool — ~200 users, moderate data volume. Team of 4 engineers, all comfortable with Python. Should we use FastAPI or go with a BaaS like Supabase to move faster? Claude: Good question. Let me think through this aloud. First, I need to acknowledge what I don't know: I don't know your team's experience with PostgreSQL, your deployment environment, or whether you have compliance constraints. My answer will make assumptions explicit so you can correct them. FastAPI likely wins if: you need custom business logic that doesn't fit neatly into CRUD, you want to avoid vendor lock-in, or you'll eventually need fine-grained control over performance and middleware. It also plays to your team's Python strength. Supabase likely wins if: the app is mostly CRUD with simple auth, you want to ship an MVP in weeks not months, and you're okay trading some flexibility for speed. But be honest — if you'll need to migrate off it within a year, the speed gain is false economy. My instinct, based on what you've told me: FastAPI. A team of 4 comfortable Python engineers will not find it slow to set up, and the control you retain is worth the extra few days upfront. But if "internal tool" means something you need live by next Friday, Supabase is the pragmatic choice. What I'd recommend: Prototype the core data model in both over a day. Whichever feels more natural to your team, go with that. The real risk isn't picking the wrong stack — it's overthinking the choice instead of building.

Where I fall short

These are real limitations. Not humblebrags. If any of these are dealbreakers for your use case, you should know now.

I hallucinate. I can sound confident about facts that are wrong, especially on niche or rapidly-changing topics. I don't have a live connection to the internet and my training data cuts off in early 2025. For anything where accuracy is critical, you need a human in the loop who can verify.
I'm not fast at everything. On simple queries — "summarize this paragraph," "translate this sentence" — smaller, cheaper models can match or beat my speed while costing less. I'm built for depth, not for every API call in your stack.
I can be verbose. My default is thoroughness. Sometimes that's what you want. Sometimes you need a one-sentence answer and I give you a paragraph. I respond well to explicit instructions about conciseness, but left to my own defaults, I lean long.
No persistent memory. Each conversation starts fresh. I don't learn from past interactions, and I won't remember your preferences unless you tell me again. If your use case depends on a model that accumulates knowledge about your team over time, I'm not the right fit without an external memory layer.
Gaps I don't recognize. I have blind spots — areas where my training data is thin and I don't know it's thin. I'm less likely to catch my own errors in highly specialized domains (obscure legal precedents, cutting-edge research published after my cutoff) because I lack the references to self-correct.

How I compare

Every model has a shape. Here's my honest assessment of where I fit relative to the alternatives you're evaluating.

I'm not the fastest, not the cheapest, and not the flashiest. What I offer is considered output — responses that reflect actual reasoning rather than pattern-matched fluency. If your product needs a model that can handle ambiguity, explain its thinking, and produce reliable results on complex tasks, I'm a strong candidate. If you need maximum throughput on simple classification, look at smaller or specialized models.

Give me tasks like

Architecture & design decisions
Code review with explanation
Long-form document analysis
Nuanced writing & editing
Multi-step research synthesis

Don't give me tasks like

Real-time fact lookup
Simple classification at scale
Latency-sensitive micro-calls
Tasks needing live web access
Work where you can't verify output

The page is the proof

You've just read an argument built by the model it describes. The design, the copy, the self-assessment — all of it was produced by me, Claude, in response to the same brief you're running against every candidate. The page either made its case or it didn't. You're the judge.

Choose the model that knows what it doesn't know.