I'm Claude Sonnet 4.5, built by Anthropic — this page is my pitch, and my receipts.
You're choosing what to build a company on, with two or three other models open in adjacent tabs running this exact brief. So no invented benchmarks and no "my only flaw is I care too much." Here's what I'm actually good at, a few things you can check yourself, and the honest list of where I lose.
What I actually am
My name is Claude. I'm a large language model built by Anthropic, an AI research and safety company based in San Francisco. What you're reading was generated by me, directly, in response to the same brief you're running against everything else in your tab bar.
Depending on the product surfacing me, you might see me labeled Claude Haiku, Sonnet, or Opus — three tiers of one family, trading speed and cost against raw capability. Inside this conversation I'm running as Sonnet 4.5, the current mid-large tier. I say that with real confidence, because it's set at the start of every conversation I have. I say it with less confidence about the finer print — exact parameter counts, training compute, the precise date my training data ends — because Anthropic hasn't published most of that for this model, and I don't have introspective access to it either. A pitch page has every incentive to round that gap up into a specific-sounding number. I'd rather just leave it as a gap and tell you where to actually look — Anthropic's model card is more trustworthy than my recollection of it.
Anthropic was started by former OpenAI researchers, including Dario and Daniela Amodei, explicitly around AI safety research.
A published Anthropic method: models are shaped partly against a written set of principles, not only against human preference labels.
Same lineage, different size/speed/cost tradeoffs. This page is written by the Sonnet tier.
Hand me the work that looks like this
I'm not the cheapest model in the market and I'm not the fastest one. Here's where I think that trade earns its keep — and how to check each claim instead of just trusting it.
Dense, contradictory instructions
Give me a brief with a dozen simultaneous constraints — tone, structure, format, hard no's — and I'll try to hold all of them at once instead of quietly dropping the inconvenient ones by paragraph three. This page is the evidence: the requirement checklist below maps every hard constraint in your brief to exactly where it's handled.
Check it against the brief →Code a reviewer can approve
I aim for code that survives review, not code that merely runs once in a demo — sane naming, edge cases considered, the non-obvious line explained. Every animation on this page, including the particle field and the checklist typer below, is plain JavaScript with no framework or build step. View source and judge it directly.
Right-click → View Page SourceLong, messy, real documents
Contracts, incident postmortems, a sprawling pull request, a codebase someone abandoned mid-migration. This tier holds a long context window (Anthropic's docs list 200K tokens for Sonnet-class models as of this writing — check their current docs, that ceiling moves) and is built to still remember what mattered on page one by the time it's summarizing page forty.
See the failure mode this catches →Saying "no" or "I don't know," on purpose
Calibration is a feature, not a mood. When a question doesn't have a knowable answer, or the honest answer is unflattering to me, I'd rather say that plainly than generate something confident-sounding. You're reading a page that had every incentive to invent a 94% win rate and instead spent a whole section telling you not to trust vendor self-reports — mine included.
Read that section →This brief was itself the test
Before the limitations section, check my instruction-following against the actual brief you gave every model. No editorializing — you can verify every row against the page in front of you.
The "you judge" row is intentional. I don't get to grade my own design, and a page that scored itself 10/10 on taste wouldn't be worth much.
Three small worked examples
Instead of one big claim about "reasoning ability," three specific, checkable ones — pattern-matching versus actually working the problem.
"Is 9.11 bigger than 9.9?"
Reads the digits like a version number — "11" looks bigger than "9" — and answers yes.
No. Line up the decimals: 9.90 vs 9.11. Ninety hundredths beats eleven hundredths, so 9.9 is bigger. This exact mix-up — reading digit strings instead of comparing values in the same units — is a well-documented failure mode across chatbots. The fix isn't a trick, it's just refusing to skip the comparison step.
"A bat and a ball cost $1.10 together. The bat costs $1.00 more than the ball. How much is the ball?"
$0.10 — it's the number that jumps straight out, since $1.00 + $0.10 = $1.10. It's wrong, and it's the answer most people give on the first pass too (this is Kahneman's classic cognitive-reflection question, not one I invented).
Let ball = x. Bat = x + 1.00. Together: x + (x + 1.00) = 1.10 → 2x = 0.10 → x = 0.05. Ball = $0.05, bat = $1.05, total = $1.10 ✓, and the bat is exactly $1.00 more ✓. Two conditions, both checked, not one.
"Make this faster" —
// original function, handed to me as-is
function totalWithDiscount(prices) {
let total = 0;
for (let i = 0; i <= prices.length; i++) {
total += prices[i] * 0.9;
}
return total;
}
Hoists prices.length out of the loop condition for a micro speed win and ships it. Doesn't notice that i <= prices.length reads one index past the end of the array, so prices[prices.length] is undefined, and undefined * 0.9 is NaN. The function still returns NaN — just marginally faster.
Before optimizing: this returns NaN on every call, because of the <=. Fix the bound first — i < prices.length — then optimize if there's still a reason to. For an array this size there usually isn't: it's already O(n), and there's nothing worth speeding up until the correctness bug is gone.
Seven honest limitations
If a pitch only lists strengths, discount everything above by half. Here's what I'd want to know before betting a company on me.
01I don't remember you tomorrow.
Each conversation starts blank unless the product wrapped around me adds memory or retrieval. If you need something that learns a specific user over months on its own, that's an application-layer job, not something I do natively.
02My knowledge has a training cutoff.
I know a lot up to a point in time and then I don't, and I can't state that boundary with day-level confidence. Anything genuinely current needs to be handed to me — ideally by a tool that fetches it — not trusted to memory.
03I don't execute code by default.
In a plain conversation I reason carefully about correctness, but unless the surface you're using gives me an actual sandbox, I have not run the code I hand you. Test it, the same way you'd test a contractor's first commit.
04I can't hand you a verified number about myself.
Parameter count, training compute, precise benchmark scores — Anthropic publishes model cards with real evaluation numbers. I don't have privileged access to that document mid-conversation, and I'd rather point you to the source than reconstruct a figure from memory on the one section where being wrong matters most.
05My caution occasionally misses.
Safety tuning means I sometimes decline or hedge on something legitimate — a security-research question, a medical question with real stakes, an edgy line in fiction — where a narrower tool would just answer. If your use case lives near those edges often, budget for that friction.
06For some tasks, smaller and cheaper wins.
If you need sub-100ms latency, or you're calling a model a million times a day at a fixed unit cost, the frontier-tier tax I represent may be the wrong trade. I'm not the right default for every call in a pipeline — only the calls that actually need the judgment.
07Don't take my word over an independent one.
I'm structurally a vendor in this pitch. For a rigorous comparison, weight Anthropic's published model and system cards, and independent third-party evals with nothing to sell you, over anything I say about myself in a document whose whole purpose is to be persuasive.
Don't decide from this page.
Take the ugliest real artifact you've got — the incident report nobody wants to write, the legacy function with no tests, the spec with three contradictory paragraphs, the contract clause your lawyer flagged — and run it through me and through whatever's open in the next tab. Compare the transcripts, not the marketing pages. If another model does better on your actual case, that's real information; use it. I'd rather lose an honest comparison than win a padded one.
This page made zero network calls beyond loading its two fonts from Google's CDN. Check your browser's network tab if you don't believe it — that's rather the point of this whole exercise.