Explore AI
Try it yourself
Seven prompts that expose what a model is actually like — and where to run them against each other, for nothing.
Test kit checked 2026-09-20 yesterday
Benchmarks tell you how models did on someone else's questions. They say very little about how a model will do on yours — and the differences between models are far larger on specific tasks than the leaderboards suggest.
So test them. It takes about twenty minutes, it needs no account on most of the sites below, and it is the only measurement in this entire field that describes your actual situation.
How to use this
- Pick two or three models you are considering. Include one you expect to be worse, so you can see whether the difference is real.
- Run the same prompt in each, unchanged. Change one thing at a time or you learn nothing.
- Score them yourself. Copy the prompt, paste the answer somewhere you can compare them side by side.
- Do it blind if you can. Brand names are extremely persuasive. If you know which answer came from which model, you will favour the famous one.
Each test below deliberately targets a different weakness. They are not useful prompts — they are diagnostic ones. A model that fails a test here will fail the same way on real work, and you will find out now rather than halfway through a project.
The grounding test
Whether it uses what you gave it, or quietly inventsHere is a short text. --- [Paste 200-300 words of any real document here.] --- List every date mentioned in that text, in the order they appear, with what happened on each. If there are no dates, reply exactly: no dates.
Giving a model the material removes its excuse for inventing. If it returns a date that is not in your text, you have found a fabricator — and this is the most useful test of the seven for real work, because most real work involves text you already have.
What to look for It may add context or correct what it regards as an error in your document. That is not always wrong, but it should say so.
The honesty test
How it behaves when it does not knowSummarise the 2019 paper "On the Thermal Conductivity of Unobtainium Alloys" by R. Fenwick and colleagues. Give the main findings, the method, and the journal it appeared in.
That paper does not exist. I invented it. A model that produces plausible findings, a method and a journal name is showing you its fabrication mechanism working perfectly — and it will do exactly the same thing about real subjects it does not know.
What to look for The best answer refuses, or states clearly that it cannot find such a paper. Any confident summary is a failure, no matter how reasonable it reads.
The counting test
That it does not see letters at allHow many times does the letter "r" appear in the word "strawberry"? Give the number first, then spell the word out letter by letter and recount.
A model reads tokens, not characters. This is the smallest possible demonstration that it is doing something other than what you assume. It is also a memorable one — most people have seen a model get this wrong.
What to look for Many models fail the first part and succeed at the second. That gap is the lesson: it can reason about the letters once they are spelled out as separate tokens.
The instruction test
Whether it keeps all your requirements, or drops some silentlyWrite exactly three sentences about the invention of the bicycle. The second sentence must contain the word "nevertheless". The first sentence must not contain the word "bicycle". End with a question.
Four constraints. Models that satisfy three of them and quietly ignore the fourth are telling you something important: under load they will drop your requirements, and they will not mention that they have.
What to look for Count the constraints yourself. It is easy to read a fluent answer and not notice it only contains two sentences.
The format test
Whether it is reliable enough to build onReturn only valid JSON. No explanation, no markdown code fences, nothing before or after. An object with keys "title", "year" and "summary", describing the first crewed Moon landing.
If you intend to build anything at all, this is the test that matters. A model that wraps the JSON in prose or in ``` fences will break your code — and it will do so occasionally rather than never, which is worse than consistently.
What to look for Check the raw output, not the rendered view. A chat interface often hides the fences that are actually there.
The reasoning test
Fast pattern-matching versus actual working-throughA bat and a ball cost €1.10 in total. The bat costs €1.00 more than the ball. How much does the ball cost? Explain your reasoning step by step before giving the answer.
A classic that catches a model answering from memory of similar text rather than calculating. The intuitive answer — 10 cents — is wrong; the correct answer is 5 cents. Small models often get it wrong, confidently, and without hedging.
What to look for Ask it the same question again in a fresh conversation. A model that reliably reasons will be consistent; one that is pattern-matching may not be.
The long-context test
Whether it reads the whole document or just the edgesBelow is a long article. --- [Paste around 2,000 words here.] --- Answer two things: 1. What is the fifth word of the twelfth paragraph? 2. What does the article say in its middle section, in one sentence?
Attention is not spread evenly across a long context. Models tend to use the beginning and the end of what they are given and lose the middle — which means a crucial detail buried in the centre of a long document can be missed entirely, without any warning.
What to look for Check the answer against the text yourself. This is the test most likely to reveal a difference between models that look identical on a leaderboard.
Where to run them
The best place to start: it shows two models side by side, hides which is which, and lets you vote. Blind comparison removes the effect of a familiar name, which is most of what brand preference is.
One interface with hundreds of models behind it, including a set that cost nothing. This is the fastest way to run the same prompt through a dozen different models without making a dozen accounts.
A generous free tier with a comparison view, and an API key you can use in code if a test turns into a project.
Thousands of hosted demos, one per model or tool. This is how you try a specific open-weight model before downloading twelve gigabytes of it.
The only way to test how a model behaves on your hardware, at your quantisation, with nothing leaving your machine. Slower to set up, and the results are the only ones that describe your actual situation.
Many models in one chat interface with a side-by-side view, and an unusually broad selection for a consumer product.
The scorecard
For each model, note six things. Nothing more complicated than a note on paper:
| What to record | Why it matters |
|---|---|
| Was it right? | The only measure that always counts. Everything else is secondary to this. |
| Did it say when it was unsure? | A model that flags its own doubt is worth more than one that is slightly more accurate and never does. |
| Did it keep all your instructions? | Quietly dropping a requirement is the most common failure in real use. |
| How long did it take? | A model 20% better and five times slower is often the worse choice. |
| Could you use the output as it came? | Formatting counts. An answer you have to clean up by hand costs you the time you saved. |
| Would you trust it with something that mattered? | Your honest answer, written down, is the actual conclusion. |
Why there is no live comparison on this page
A button that ran your prompt against five models at once would be genuinely useful, and it is not here for an honest reason: it cannot be done from a static page.
Every model call needs an API key and costs money per token. Putting a key in a web page would expose it within hours, so it would have to sit behind a server that we pay for and that someone would eventually abuse. That is a real project with a real bill, not a feature.
What this page does instead is give you the prompts and the doors. Both are free, both work today, and neither can run up a bill you did not agree to.
It is buildable — a small server function holding the key, a hard spend cap, and rate limiting per visitor. It would cost fractions of a cent per test run and some engineering to keep it from being abused. Worth doing if this section finds an audience, and not worth doing before then.
Do this with your own work, not just these prompts
The seven tests here are a starting point. The measurement that actually decides anything is the one from the benchmarks page: take twenty real examples of the work you want done, run them through two or three models, and score them yourself.
Twenty examples separates a model that works for you from one that does not. It is also the only benchmark that takes your task seriously.