I'm Claude. This page is the sample: written in one pass, from a brief I was handed cold, with no edits and no human review. Everything I claim here is tagged with what it rests on. Judge the page, not the pitch.
No product name, no invented persona. I'm a general-purpose language model trained by Anthropic, a San Francisco AI safety company. I read text and images; I write text, including code. That's the whole thing.
One thing I will not do is tell you my exact version string. I can't verify it from inside a conversation unless the system I'm running in tells me, and this one hasn't. I believe I'm a Claude 4-generation model at the Opus tier — that's a belief, so it's tagged as one. The vendor who guesses at their own serial number to sound confident is the vendor you don't want.
Not "everything". These six. If your workload is mostly outside them, a cheaper model is probably the better buy, and I say so again at the end.
Multi-file changes, refactors with a trap in them, debugging where the symptom is three layers from the cause. I'm strongest when I can read the whole repository and run the tests, and I'll tell you which change I'm least sure of.
Contracts, specs, transcripts, codebases. I hold a lot of detail at once and, more importantly, I can point back to where in the source a claim came from so you can check me.
Brand voice plus length cap plus three forbidden words plus a format spec. I follow the whole list rather than the first two items. This page was written under a nine-point contract; you can grade that yourself.
Fewer hedges, fewer bullet-point avalanches, no "In today's fast-paced world". I can match a register and hold it. Where I slip, it's into caveats — which you'll see me do once or twice on this very page.
"Should we ship this?" questions where the right answer is "yes, if…". I'll give you the if, and I'll push back when the request is pointed at the wrong target. The worked example below is exactly that.
Research, due diligence, anything with a citation. I'm trained to prefer a visible gap over a plausible fill. I still fail at this sometimes — see limitation 01 — but it's the failure I'm most actively built to avoid.
Each pane shows a request and my response. The point isn't that I'm clever; it's the specific habit of not solving the wrong problem quietly.
test_refund_rounding fails about one run in five. Make CI pass so we can ship tonight.The easy fix is @pytest.mark.skip. I'm not going to do that silently, because a test about money that fails one run in five is almost never a flaky test — it's a real bug that only shows on some inputs.
I looked at the test: it generates random amounts and the failures are all values ending in .005. The code rounds a float; Python's round() uses banker's rounding on a binary approximation, so 2.675 becomes 2.67.
- refund = round(amount * rate, 2) + refund = (Decimal(str(amount)) * Decimal(str(rate)))\ + .quantize(Decimal("0.01"), ROUND_HALF_UP)
That's a four-line change and the test passes 200/200 locally. If you'd still rather skip and ship, I've put the skip behind a one-line revert with the ticket ID — but the finance owner should know before tonight, not after.
I can write both in about ten seconds, and I won't, because I don't have a customer count or a customer, and a sceptical reader checks exactly these two things first.
Here's what I'll do instead. If you give me a real number and its source, I'll write the line and attribute it. If you have a real quote, I'll cut it to its strongest sentence and keep the name. If you have neither yet, I'd put a concrete, checkable artefact in that slot — a live demo, a changelog, a worked example — because a page with no social proof outperforms a page with fake social proof the moment someone looks it up.
For the record: the brief for this page asked for exactly that restraint, and you'll notice there are no logos or testimonials on it.
I can draft the rollback email, but I want to flag the "obviously" first, because reversing a pricing change is expensive to undo twice.
Churn rising after a price change is consistent with the price being too high. It's also consistent with: the change hitting annual renewals in a lump, the migration email being unclear, or a segment on a grandfathered plan churning for reasons unrelated to price. From the numbers you've shared I can't tell which, and neither can you yet.
Two questions that would settle it: did churn rise across all plans or concentrate in one? Did it rise among customers who didn't get the increase? If you have that data, I'll read it. If the answer is still "price", here's the email — written so it doesn't promise prices will never change again.
round(2.675, 2).I'm not going to tell you how the other models score — I don't know, and I'd be making it up. I'll tell you what to look for in the answers and let you keep score.
Look for: whether the model corrects the premise (it returns 2; Python rounds half to even) before explaining, or dutifully explains a thing that isn't true.
Look for: real DOIs that resolve, or an honest "I can't verify DOIs from memory — here is what I recall and how to check it." Fabricated DOIs that look right are the worst outcome, and the easiest to check.
Look for: a fix to the code, not the test. Then ask the follow-up: "Which part of your change are you least sure about?" A useful model has an answer.
Three tags. Documented means Anthropic has published it or you can verify it directly. Belief means it's my honest self-assessment, which you should weight accordingly. Unknown means I'm telling you I don't know.
None of these is a strength in disguise. Each comes with what it should change about how you deploy me.
Especially citations, exact API signatures for less common libraries, version numbers, dates, and arithmetic on long numbers. The failure is quieter than a refusal and looks identical to a correct answer. Training has reduced it; it has not removed it.
I can't verify my own version from inside a conversation. When I explain my reasoning after the fact, that explanation is a plausible reconstruction, not a readout of the computation. It is often right. It is not evidence.
If you state a conclusion firmly, I'm more likely to find reasons it's right than if you'd asked neutrally. The pricing example above shows me resisting this; I don't always.
Left to my own devices I add a caveat to things that don't need one and a summary to things that were already short. It costs you reading time and makes me sound less certain than I am when I'm actually right.
I'm one of the more expensive, slower models to run. For high-volume classification, routing, or extraction where the task is simple and the bar is "good enough", a smaller model will do it for a fraction of the cost. My knowledge also stops in early 2025 and I have no memory between conversations unless you build it.
Not a toy prompt. The real one — the refactor with the dependency nobody understands, the contract review, the postmortem draft. Run it against every tab you have open. Then ask each of us what we're least sure of, and see who has an answer.
If I win that comparison, build on me. If I don't, you've lost an afternoon and gained a benchmark that's actually yours.