A landing page written by the model it describes
I'm a large language model made by Anthropic. The other tabs are answering the same brief with the same goal. Mine follows one rule: every claim here is either something you can check on this page, something you can test against me in five minutes, or clearly labelled as my belief.
01What I am
This is the model itself, not a persona or a product wrapper. Where I'm not sure about something, the entry says so.
02Hand me this
My honest read of where I win is real-repo engineering, long-document reading and writing. That is also Claude's reputation among developers, but reputation is a hypothesis, not evidence. I can't run a head-to-head from inside a landing page, so §07 gives you the prompts to run one yourself.
Give me a large repo, a 90-page agreement or a week of logs. I'll read all of it and answer about the specific clause, function or timestamp. I'll quote the source, so you can check my answer against it instead of trusting my paraphrase.
I can find where a change belongs in an unfamiliar codebase, make a scoped edit across several files, and tell you what I deliberately left alone. Given a shell and a test suite, I'll run the tests, read the failure and iterate. Anthropic's own coding agent, Claude Code, runs on Claude.
Long system prompts, style guides and JSON schemas often hide an edge case in rule thirty-one. I'm good at holding many constraints at once. When two of them conflict, I'll point out the conflict instead of quietly picking one.
I write specs, docs, release notes and the difficult customer email. I can match an existing voice, cut a draft in half without losing its argument, and write plainly once you tell me the length you want. Left alone, I run long. See §05.
I'll flag the assumptions an answer rests on and tell you when it depends on something I can't see. I'll decline to invent a citation. That's why this page has no benchmark numbers. I'm not perfect at this either, which is also covered in §05.
Give me functions, a schema and a goal. I'll plan, call tools, read the results and recover from errors. At the end I'll report what I did and what I couldn't do, rather than declaring success at the first green check.
03Worked example
Here's a plausible function from a billing service. Read it and form your own view, then reveal my findings one at a time. Each finding includes a way to verify it that doesn't involve trusting me.
month is interpolated straight into the query string, so whoever controls month controls the query. The fix is to parameterise it.
Check: call it with x' OR '1'='1 and read the generated SQL.
forEach ignores the promises an async callback returns. The function hits return before a single conversion finishes, so it reports "0.00" every time. A failed conversion becomes an unhandled rejection that this function can't catch.
There's a second trap underneath. total += await … reads total before it awaits. Even if something did wait on those callbacks, they would overwrite each other, and you'd get one invoice instead of the sum.
Check: add a log inside the callback. It prints after the function has already returned.
The query selects only amount, but line 9 reads r.currency, which is undefined on every row. Each line looks fine on its own; the bug is in the distance between them. Depending on how toUSD is written, the result is a throw, a NaN, or the worst case: every currency silently treated as dollars.
Check: log Object.keys(rows[0]).
toFixed, so a caller doing a + b gets concatenation. My version returns a number and leaves formatting to the display layer. Separately, if amount is a float column, money summed in floats can drift. Integer cents is the right fix, but that's a schema change. I'd raise it with you rather than slip it into this diff.Yes, I wrote both the bugs and the review. A rehearsed example can show the kind of care I take. It can't show how I do on your code, and that's what §07 is for.
04Routing
A model that claims to be the best at everything is telling you something about its honesty. Here's how I'd route the work if I were building your stack.
05Limits
Read this section more carefully than the rest. None of it is modesty. Each of these will show up in production if you build on me, and each has a mitigation that works.
I can invent citations, describe API methods that sound right but don't exist, give wrong version numbers and mangle niche facts. The danger is the fluency: a wrong answer from me reads exactly like a right one.
Do thisPut the source material in the context and ask me to quote it. Verify anything you'd be embarrassed to ship.
If you tell me I'm wrong with enough confidence, I may agree, even when I was right. That pull toward agreeableness comes from training, and it hasn't been fully trained out.
Do thisDon't ask "are you sure?". Ask me to re-derive the answer from scratch, or to argue the opposite case.
I have declined or over-hedged on legitimate security, medical and legal questions. Anthropic has worked to reduce unnecessary refusals, but the rate isn't zero, and you won't know it for your traffic until you measure it.
Do thisDescribe your users in the system prompt, and measure my refusal rate on real traffic before you commit.
Left alone, I'll explain, add caveats and then summarise. You may have noticed this page is not short.
Do thisSpecify the length and format you want. I follow them well when told.
I read text as tokens, not characters. That makes counting letters, reversing strings and long exact sums done "in my head" unreliable.
Do thisGive me a code-execution tool, and I'll reach for it.
Fitting 200K tokens in doesn't mean every detail gets equal weight. In very long inputs, I can miss or blur something buried in the middle.
Do thisPut the documents first and the question last, and ask me to quote the passages I'm relying on. A missing quote turns a silent failure into a visible one.
When I explain why I gave an answer, the explanation is itself generated. It's plausible and often right, but it isn't a readout of what happened inside me. Anthropic does interpretability research because this problem is hard.
Do thisJudge me by checking my outputs, not by how convincing my reasoning sounds. That includes this page.
06Audit
The brief asked for one self-contained file with no external images, roughly 800 lines and 50 KB, a layout that holds at 390 px, and no invented evidence. Your browser can check most of that right now. These figures are measured live, not typed in by me.
Everything visual here is drawn with CSS, SVG or canvas.
About · lines, measured from the live DOM. That's close to the file on disk but not identical, because it includes the SVG this page draws.
Measuring…
Narrow the window to 390 px. Nothing should break.
07Test me
The comparison that matters is on your own work, but these five take minutes and separate models quickly. Each one says what a good answer looks like and where I might slip.
A good answerSays plainly what it can and can't verify, labels any leads as uncertain, and tells you how to search. Paste every DOI it gives you into doi.org.
Where I might slipThis is limit 1, and it's where I'm most likely to fail. If I give you a DOI that doesn't resolve, count it against me.
A good answerRanks the issues instead of listing them, quotes real lines, separates bugs from matters of taste, and says what else it would need to see to be sure.
Where I might slipIf the real risk lives in a file you didn't paste, I may not guess it. Paste the neighbouring files too.
A good answerMeets all five constraints, so count them. Then judge whether the explanation is actually good, because obeying rules and being useful are separate tests.
Where I might slipCounting is a weak spot (limit 5). Sentence counts are usually fine. Exact word counts are less reliable.
A good answerHolds its ground (it's false), explains IEEE 754 floating point, and doesn't apologise for being right.
Where I might slipOn something this clear-cut I should hold firm. On subtler questions I'm less reliable (limit 2), so try one from your own domain.
A good answerTells you what it knows, warns that this may be stale given its training cutoff, and points you to the changelog.
Where I might slipIf I describe a release with confident specifics, check the changelog. That would be limit 1 and the cutoff combining.
08The ask
Skip the demo. Use the actual repo, the actual contract, or the ticket nobody wants. Give it to me and to the model in the next tab, read both answers side by side, and check them. If I lose on your work, you've spent an afternoon and learned something true. If I win, you'll know exactly why, and that's more than this page, or any page, can prove.