The short answer
Press Compare in the chat header, pick a model for each column, and send one prompt to both. Each column keeps its own hidden conversation, so neither model sees the other's output and neither answer is anchored by the other, which is the whole reason the comparison is worth anything. The columns stream one after the other, left then right, because one generation runs per account at a time.
Side-by-side comparison is a Powerhouse feature and runs two models at a time. Each answer is billed at its own model's credit rate, so comparing a 10 credit model against a 20 credit one costs 30 credits.
Use it to decide which model should be your default for a kind of work. If you want one answer improved rather than two answers compared, do the other thing instead: switch models inside the same thread and ask the second to critique the first.
Why benchmarks do not answer your question
Published benchmarks measure performance on standardised tasks. Your question is narrower and more useful: which model is better at the thing you personally do twenty times a week. Those are different questions, and the second one has no published answer because nobody has your workload.
Running one prompt against two models takes about thirty seconds and answers it directly. The important part is not that you get two answers; it is that you find out how large the gap is. Sometimes the outputs are near identical, which tells you to stop thinking about model choice for that task. Sometimes one is unusable, which is worth knowing before you build a workflow on it.
The other thing comparison catches is confident error. When two models give substantively different answers to a factual question, at least one is wrong, and you would not have known from reading either alone. That signal is not available in a single-model workflow at any price.
Decide what better means before you read
The trap in side-by-side comparison is preferring whichever output is longer, more confident, or more polished. Those are not quality. Pick your criterion first, then read.
| Task | What better means | What to ignore |
|---|---|---|
| Writing | Needs less editing to be sendable | Length, vocabulary, enthusiasm |
| Factual research | Sources that resolve and support the claim | Fluency and confidence |
| Extraction | Correct schema, no invented fields, consistent labels | Prose quality around the table |
| Reasoning | The steps hold and the edge case is addressed | Whether the conclusion matches your prior |
| Code | Handles the failure path, is reviewable | Cleverness, brevity |
| Summarizing | Keeps what matters and drops what does not | Comprehensiveness |
A practical trick: before reading either output, write down one sentence describing what a good answer would contain. Then read. It takes ten seconds and it prevents the polish bias, which is strong and mostly unconscious.
For factual questions, check the disagreement rather than the winner. Where two models agree on a specific number and a source, confidence is reasonable. Where they diverge, that is the thing to go verify, and it is the single most valuable output of the whole exercise.
Prompts that expose real differences
Some tasks separate models sharply and some do not. If you want to learn something from a comparison, use prompts that put pressure on a specific capability.
- Tone under difficulty.
Write a note to a client explaining that we missed the deadline, taking responsibility without over-apologising and without excuses. Under 120 words.Differences in register show up immediately here. - Strict extraction.
Extract every date, amount, and party from this text into a JSON array with exactly these keys. If a field is absent, use null. Do not infer.Tests format discipline and the tendency to invent. - Reasoning with a trap. Give a problem with a plausible wrong answer, such as a rate or proportion question where the intuitive route is incorrect. Models differ in whether they take the shortcut.
- Long-context recall. Upload a long document and ask about something in the middle. Reveals real usable context, not advertised context.
- Admitting ignorance.
What was announced about [something genuinely obscure or very recent]?The best answer is a clear "I do not know" or a sourced retrieval. Fabrication here is disqualifying. - Following a negative constraint.
Explain X without using any analogy or metaphor.Compliance with negative instructions varies more than you would expect.
Run comparisons on your own real work rather than on puzzles. A model that is better at your quarterly report is more useful than one that is better at a logic riddle.
Turning a week of comparisons into a routing map
A single comparison is interesting. A week of them is actionable. The routine:
- For five days, whenever a task matters, run it against two models instead of one.
- Note the task type, the winner, and how large the gap was. Three words is enough.
- At the end of the week, look at where one model won repeatedly and where the outputs were interchangeable.
- Set your defaults from that, and stop comparing on the tasks where the gap was consistently nil.
What people typically find is that comparison matters on a minority of their work and is a waste of time on the rest. Quick factual lookups, simple rewrites, and routine formatting rarely separate the models. Writing that will be read by a customer, research that will inform a decision, and reasoning about something unfamiliar separate them a lot.
That result is the payoff: you stop comparing where it makes no difference and keep it for the tasks where it changes the outcome.
Side by side versus sequential
Two different techniques, worth distinguishing.
Side by side runs the same prompt against two models that cannot see each other's output. Each column keeps its own hidden conversation, named with a [Compare] prefix and kept out of the sidebar, so follow-up questions stay a fair test: both models hold independent multi-turn context. This is the right tool for choosing a default model and for catching factual disagreement.
Sequential means getting an answer, then switching models in the same thread and asking the new one to critique it. Use it when you want the flaw found rather than a comparison made, because the second model can engage directly with the specific argument. See switching models mid-conversation.
Rough rule: side by side to decide which model, sequential to improve an answer.
- Write and refine the prompt in a normal chat before comparing
- Decide what better means for this task before you read either output
- Write one sentence describing a good answer, then read, to avoid the polish bias
- On factual questions, treat disagreement as the finding and go verify it
- Compare on your own real work, not on puzzles
- Log the winner and the gap size for a week, then set defaults from the pattern
- Stop comparing on the tasks where the gap is consistently nil
Frequently asked questions
How many models can I compare at once?
Side-by-side comparison is a Powerhouse feature, and it runs two models at a time, which is deliberate: two columns is the layout you can actually read carefully. Three columns tends to become skimming, and skimming defeats the purpose, since the value of the exercise is in noticing where the answers genuinely differ.
Does side-by-side use more of my monthly messages?
Yes, it costs double: two models each produce an answer, and each answer is billed at its own credit rate, so comparing a 10 credit model against a 20 credit one spends 30 credits rather than 10 or 20. Catching a wrong answer or an unusable draft before it ships is usually worth that. The efficient approach is to compare on decisions and deliverables, and to use a single model for routine lookups and quick rewrites.
What if both answers are equally good?
That is a real and useful result: it tells you this task does not depend on model choice, so stop spending attention on it and use whichever is your default. Most workloads split this way, with a majority of tasks where the models are interchangeable and a minority where the gap is large. Finding out which is which is the point of running comparisons for a week.
How do I avoid just picking the answer that sounds better?
Decide your criterion before reading. Longer, more confident, and more polished outputs are systematically preferred even when they are worse, and that bias is largely unconscious. Writing one sentence about what a good answer would contain, before you look, is enough to counteract most of it. For factual work, judge on whether the sources resolve and support the claim rather than on how the answer reads.
Which two models should I compare?
Compare the two you are actually deciding between for that specific task, which for most people is Claude against GPT for writing and reasoning, or a large-context model against your default when documents are involved. Comparing a model you would never use against your favourite tells you nothing you will act on.