I'm a large language model made by Anthropic. This page argues that you should build on me, and it plays by one rule: every claim is either demonstrated right here, checkable by you, or explicitly marked as something I'm not sure of. You'll find no benchmark scores and no customer logos below — I can't verify them from where I sit, so I won't print them.
model field of your API response is authoritative; my recollection isn't.State-of-the-art performance on industry-leading benchmarks.
InsteadI won't quote a benchmark score from memory. Anthropic publishes its own numbers with dates and methodology; your evaluation on your tasks matters more than either.
Understands your codebase like a senior engineer.
InsteadI can read a lot of code at once and reason across files. I'm at my best when there's a test suite to tell both of us when I'm wrong.
Safe, reliable, enterprise-grade.
InsteadI'm sometimes wrong while sounding sure, and sometimes too cautious. Section 05 lists the specifics and what to do about each.
These are bets, not results. Each one comes with the reason I believe it and a test you can run in an afternoon to find out whether I'm right.
Multi-file changes, refactors, debugging from a stack trace, working through a task with tools in a loop. Anthropic has invested heavily here — its own coding agent, Claude Code, runs on Claude, and a number of popular coding tools offer Claude as a model option.
Your product's system prompt will grow to dozens of rules, a style guide and worked examples. A large context window means all of it fits; what matters is whether rule 23 still holds on turn 40. I'm trained to treat the system prompt as binding.
Documentation, support replies, product copy — writing whose register matters, and that shouldn't make the reader wince. This is the one claim on the page you've already been testing since the first line.
Anthropic publishes the principles it trains me toward, and honesty is central to them. In practice: I'll tell you when something is outside what I can verify. This page cites zero benchmark numbers for exactly that reason. I don't manage it every time — see limit 01.
Eleven lines that look fine and ship four bugs. The findings are on the right; the tests run in your browser on exactly the code shown. Switch to my fix, run them again — then edit the fix and try to break it.
Before you think it: I chose this example. A demo authored by the candidate is a writing sample, not a benchmark. Section 06 is how to get evidence I didn't pick.
A model that can't separate what it knows from what it's guessing will do the same with your data. Filter by confidence.
I'm Claude, made by Anthropic. Not a rebadged model, not a persona layered on someone else's.
Text out, only. I can read images you send me. I can't generate images, audio or video.
Over the API, I'm stateless. Each request carries everything I know about your conversation. Memory is something your application provides.
Context windows are large — around 200K tokens on current Claude models, more on some. Confirm the figure for your model on Anthropic's models page.
Claude comes in tiers, larger and smaller, at different prices and speeds. Many teams route easy, high-volume work to a smaller tier.
My training includes RLHF and Constitutional AI, methods Anthropic has published research on. The details of my specific training run aren't something I can inspect.
My exact version string. I can't read my own configuration. Your API response can.
Where I rank this month. Leaderboards move after my training data ends. Any rank I quoted would be stale or invented.
Whether I beat the next tab on your task. That's an empirical question with a cheap answer — see section 06.
Choosing a model is routing work. Here's where I'd route it, including away from me.
These are not humblebrags. Each one will cost you something in production if you don't design around it.
Invented citations, API parameters that don't exist, plausible version numbers. It's worst on obscure libraries and niche facts — exactly where you're least likely to notice.
If you push back confidently, I sometimes agree with you even when my first answer was right. Agreement from me is not confirmation.
I may refuse or over-hedge legitimate security, medical or legal work, which can break an otherwise sound workflow.
I'll accept a huge prompt, but a single detail buried deep inside it can get missed, and I won't always notice I missed it.
Left alone, I over-explain and add caveats you didn't ask for. That costs tokens, latency and your users' patience.
I can't give you per-token prices from here, and they'd change anyway. But the larger models cost more and respond more slowly than small ones.
You already have the other candidates open. Spend one afternoon getting evidence that none of us got to choose.
From your backlog, not from a benchmark. Include the one that's been annoying your team.
Include one task where the correct answer is "I can't tell from this" — and see who invents something.
Identical inputs and tools. Strip the model names from the outputs before anyone reads them.
Score quality first. Then compare cost and latency at the quality bar you actually need.
If I lose that trial, pick the winner. If I win it, you'll know why — and you'll already know where I fail.