In Class 07 you learned what sits inside an AI system: you give a brief, a coding agent does the operating, and a model does the reasoning. That raises the obvious next question: which model should do the reasoning?

If you ask the internet, you will get a confident answer. It changes every few weeks. That should tell you something. The question "what is the best model?" is the wrong question. The right question is "what is the best model *for this job*?"

Start with the job, not the ranking

Think about hiring for ByeBuy. You would not ask "who is the best person?" You would ask "who is the best person for product photography, for bookkeeping, for negotiating a lease?" Models work the same way. Each one is tuned, priced, and packaged for different work.

A model that writes beautiful long-form reasoning may be slow and expensive. A model that answers in under a second may stumble on a tricky architecture decision. A model that reads screenshots brilliantly may know nothing about your codebase. None of that makes any of them bad. It makes them specialized.

So before you compare models, describe the job in plain language:

• What goes in? (a document, a codebase, a screenshot, an audio clip)
• What should come out? (a summary, a decision, edited code, a voiceover)
• What matters most? (speed, accuracy, cost, privacy, tool use)
• What would failure look like? (a wrong refund, a broken build, a leaked file)

Once you can answer those four, model choice gets much simpler.

The categories you will actually encounter

You do not need to memorize every model name. Names change monthly. Learn the categories instead — they are durable.

A single product often combines several rows. ByeBuy might use a fast model to summarize supplier notes, a reasoning model to decide the database shape, a vision-capable model to read a screenshot of a broken layout, and a speech model to transcribe a supplier call. That is normal. One project, several brains.

The jobFast general modelReasoning modelCoding model + agentVision-capable modelSpeech / audio modelOpen-weight / local option

The tradeoffs that actually matter

When two models both "can do" your task, compare them on these seven axes:

1. Quality on this task. Not quality in general. Quality on *your* kind of input. 2. Speed. How long do you wait? For interactive work, seconds matter. 3. Cost. What does one request cost — and what does a hundred cost? (Full costing comes in Class 12.) 4. Context size. How much material can it consider at once? A whole repo versus one file is a different league. (Full treatment in Class 09.) 5. Tool use. Can it reliably call tools — read files, run tests, browse — inside an agent? Some models reason well but operate tools poorly. 6. Privacy and data boundary. Does your prompt leave your machine? Where is it processed and retained? (Full treatment in Class 10.) 7. Hardware requirements. If you run it yourself, can your machine actually hold it? (See Lesson 8.3.)

The pattern to internalize: "stronger" usually means slower, more expensive, or more demanding. A reasoning model that thinks for two minutes is wonderful for a decision you will live with for a year. It is absurd for renaming ten files.

Five jobs, five assignments

Let us make it concrete.

1. Summarize a 20-page supplier document. Input: text. Output: half-page brief. What matters: speed and cost. Assign a fast general model. There is no reason to burn reasoning tokens on competent summarization.

2. Reason through an architecture decision. "Should ByeBuy store product variants as separate rows or as JSON inside one row, given filtering, inventory, and future search?" That needs tradeoff analysis, not autocomplete. Assign a reasoning model, then verify the answer against your actual constraints.

3. Inspect a screenshot of a broken checkout page. A text-only model cannot see it. Assign a vision-capable model — and give it a good screenshot. (Class 06's appendix on screenshots as context applies directly: crop tight, show the error state, include the URL and viewport.)

4. Generate a voiceover for a 60-second product demo. No text model, however clever, speaks aloud. Assign a speech/audio generation model with a chosen voice, then listen to the whole take before publishing.

5. Work inside a codebase: rename, refactor, add tests. This is agent work, not chat work. Assign a coding-capable model inside a coding agent (the harness from Class 07), with a bounded brief, the files to read, and tests as proof.

6. Draft product copy and blog rewrites. This is where brand loyalty wastes money. A flagship ChatGPT or Claude model will do it beautifully — and bill you flagship rates for work a Meta Llama 3.1 70B, Llama 4 Maverick, or Muse Spark 1.3 can do just as well for a fraction of the price. Assign a cost-effective general model (Meta, Qwen, DeepSeek, or GLM class) for drafts and variations, then reserve the expensive model for the final polish if you need it.

Notice what happened: nobody asked "which model is smartest?" Everyone asked "what does this job demand?"

A decision table you can reuse

Keep this table. Lesson 8.2 will add public evidence (leaderboards) to it, and Class 12 will add cost math. The table does not change; the candidate names inside it do.

Practical exercise: five tasks, five choices

Take five real tasks from your own work — or use these if you prefer:

1. Summarize meeting notes into three action items. 2. Choose between two database designs for a small store. 3. Explain why a mobile screenshot looks broken. 4. Turn a paragraph of product copy into a spoken demo line. 5. Rename a component across a small repo and update its imports.

For each one, write two sentences: which category you would start with, and which tradeoff drove the choice (speed, reasoning depth, tool use, image input, audio output, privacy, hardware, or cost).

Finish line: you have a five-row table — task, chosen category, reason — saved in your project notes. If someone asks "why not just use the biggest model for all five?" you can answer from your table, not from hype.

Quick verification: for at least one task, ask: could a cheaper or faster category do it acceptably? If yes, you just saved money. If no, you know exactly what you are paying extra for.

Common failure mode: picking the famous model for everything, then blaming the model when a screenshot task fails on a text-only model or a routine task costs ten times what it should. The failure was in the assignment, not the intelligence.

Check your understanding

1. Why is "what is the best model?" the wrong question? 2. Which category fits a screenshot, and why can a text-only model not do that job? 3. Why does coding work need a model *plus* an agent harness, not just a clever model? 4. Name three of the seven tradeoff axes and explain when each one decides the choice. 5. Why might a "stronger" model be the wrong choice for a simple task?

Next, in Lesson 8.2, you will learn to read a public leaderboard — Arena's WebDev and Data & Analytics boards — without being fooled by it, and you will build your first ByeBuy model-selection card.