The comparison page puts two to five models in one table and highlights the best number in each numeric row. The highlight is local. It means "largest or cheapest in this row among the models you ticked," not "best model." This guide is how to turn that table into a decision you can explain to someone else. The page also writes a short conclusion from the same fields. Read the conclusion as a narration of the table, then do the steps below. Search engines are asked not to crawl the comparison URL itself, because every combination of ids would be a near-duplicate page. You can still use the tool. The durable explanation lives here.
Throw rows out before you rank them
Start with columns you can reject outright.
License. If you cannot accept the license, cross the model off. A green cell for context window does not resurrect it. The open versus proprietary guide is the longer version of this cut.
Context window. Add up a realistic prompt: the system text, the files you refuse to summarize away, and the answer you expect back. If the window is smaller than that sum, cross the model off or plan to chunk the work. Chunking is a different product. Do not pretend a short window "usually works" for a job that is one long file.
Hosting. If you must self-host and the model is proprietary with no weights, cross it off. If you cannot operate a GPU and the model is weights-only, cross it off or budget the time to learn the runtime. VRAM, when the row exists, makes this concrete.
After those cuts you often have one or two models left. The rest of the table is a tie-breaker, not a beauty contest.
Read highlights in this priority
- Context window, only if the job is long. If every remaining model can hold the prompt, stop looking at this row.
- Price, if you will call the model thousands of times. Compare input and output separately. A cheap input price with an expensive output price loses on long answers.
- VRAM, if you self-host. Lower is easier until the quality on your prompt falls apart.
- Parameter count, only as a sanity check that you are not comparing a tiny distilled model with a flagship by accident. Do not pick the bigger number for its own sake.
- Benchmarks whose names you recognize and that resemble your task. Ignore a benchmark you cannot define.
- Directory score, last. It ordered the picker. It has done its job.
The written conclusion under the table follows a similar order and will say when every selected model is open or every one is closed. If it says a field is missing, believe it. Filling the blank from memory is how stale prices get into a design doc.
Run one prompt that can fail
Pick a prompt from last week that you still remember the right answer to. Include a trap: a file that should not be edited, a number that must be copied exactly, a question the model should refuse. Run it once on each survivor with the same settings you intend to ship. Temperature and system prompt matter more than a one-point score gap.
Write down three lines: what it got right, what it invented, and what it cost or how long it took. That note is your evaluation. The table was only how you chose which two invoices to open.
Do not compare aliases with the thing they alias
Rows named "Latest" or "Fast" or "batch" are variants. A fast mode at higher price is not a different intelligence, and a batch endpoint is not a better model. Compare the variant you will actually call. If you put both the standard row and the fast row in the table, the highlight on price will favor the standard row and the highlight on nothing else may tie. That is a pricing choice, not a quality result. Say so in your note.
When the table cannot decide
If two models survive and your prompt does not separate them, pick the one with the simpler operational story: the vendor you already have a contract with, or the weight file you already know how to serve. Switching costs are real. A directory is not obligated to produce a unique winner.
Come back when the vendor changes the price or the window, not when the directory score moves by a point. Scores move because we re-sort listings. Your prompt did not get worse overnight. How to read a model listing defines each field if a row header is unclear, and how ranking works explains why the picker was sorted the way it was.
Writing the decision down
After you cross models off, the note you keep should fit in a short message to a teammate. Name the models you rejected and the single field that rejected them: license, window, or hosting. Name the model you kept and the prompt you ran. Name the cost or the hardware in one clause. Attach nothing else. A paste of the whole table invites someone to re-open a row you already killed because a benchmark cell was green.
If the written conclusion on the comparison page disagrees with your note, either you misread a field or the conclusion is narrating a field you chose to ignore for policy reasons. Both are allowed. The conclusion does not know your policy. Your note does. Do not edit the note to match the paragraph if the paragraph recommends a model you are not allowed to call.
Revisit the note when the vendor posts a new price or a new window, or when your prompt grows past the window you counted. Do not revisit it because a different model climbed the directory score. That climb is explained in how ranking works and it is not a change in your task. If a field on our page is simply wrong compared with the vendor, send the page URL through the contact form and cite the vendor in your note until we fix the row. The corrections guide says what to include in that message.
A comparison that ends with "we need more models in the table" is usually a comparison that skipped the rejection step. Add a model only when it differs in a way your rejection criteria would allow. Five similar hosted flagships will highlight five different cells and teach you nothing about the constraint that actually binds you. If you are stuck, remove models until only two remain and run the prompt. The table's job ended when it showed you which field to reject on. Staying inside the table after that is a way to postpone calling the API or loading the weights. Either call it or write down why you are not allowed to. Both are decisions. A larger shortlist is not. Two models and a prompt you can score by hand will finish the afternoon. Five models and another column will not. Close the picker when the rejection rules have run, even if the highlighted cells still look interesting.