SideNote ProHow to choose the right AI model for each task
The habit that costs people the most money and the most time is using one heavyweight model for everything. This is a method for deciding, per task, what you actually need, and it does not depend on which models exist this month.
Why there is no best model here
You will not find a ranked list of models on this page. Any such list is wrong within months: models are released, deprecated, repriced and quietly improved, and a website that told you the answer in August is misleading you by December.
What does not go stale is the method. If you can classify a task, you can pick a model for it from whatever your provider offers today, and you will still be able to a year from now.
Classify the task first
Almost every request falls into one of three shapes. The question to ask is: *what would make an answer to this wrong?*
Fluency tasks
The answer is wrong if it reads badly. Rewriting, tone changes, summarizing short text, translating ordinary prose, generating title options. There is no hidden structure to work out. Prioritise speed.
Comprehension tasks
The answer is wrong if it misreads the material. Explaining code, extracting commitments from a document, comparing two options on stated criteria. Prioritise a balanced model.
Reasoning tasks
The answer is wrong if a chain of inference breaks. Debugging from evidence, finding failure modes in a design, spotting an unstated assumption that makes two requirements contradictory. Prioritise capability.
| Task | Typical priority |
|---|---|
| Rewrite one paragraph | Speed |
| Summarize short text | Speed |
| Translate ordinary text | Speed |
| Generate headline alternatives | Speed |
| Explain straightforward code | Balanced |
| Extract action items from a report | Balanced |
| Compare several options | Balanced |
| Analyze an architecture | Reasoning |
| Debug a complex failure | Reasoning |
| Evaluate contradictory requirements | Reasoning |
The interesting cases are the ones that look like one shape and are another. *Summarize this contract* looks like a fluency task and is usually a comprehension task, because being wrong about an obligation matters more than reading smoothly.
Mapping shapes onto what your provider offers
Providers generally offer a tiered family: smaller and faster variants, mid-range general models, and larger or reasoning-focused models. The names change; the tiering rarely does.
- Fluency tasks go to the smallest model that produces text you would not rewrite. This is usually much smaller than people assume.
- Comprehension tasks go to a mid-range general model. Most everyday work lands here.
- Reasoning tasks go to the most capable model available, with reasoning effort raised where supported.
A new OpenAI profile in SideNote Pro starts on gpt-5-mini, which sits in the fast-and-capable-enough band and is a reasonable default for the first two shapes. Use model discovery in Settings, AI providers to see what else your account can reach.
Make switching cheap
A method you cannot act on quickly is a method you will not use. The trick is to make the switch a click, not a settings expedition.
- Create one profile per shapeDuplicate an existing profile and change only the model. Name them for what they are for: *Fast*, *Everyday*, *Deep*.
- Set reasoning effort per profileLeave the fast profile on Provider default, and raise it on the deep profile if the model supports it.
- Switch from the composerThe picker names the profile and model that will receive your next message, so switching is one interaction before you send.
Test on your own work
General benchmarks tell you very little about whether a model handles *your* documents, *your* codebase and *your* prompts well. Your own comparison is worth more than any leaderboard.
Take five tasks you actually do. Run each on the smaller model. Regenerate on the larger one. Ask whether the difference would have changed what you did next. Most people find the honest answer is *no* for a large fraction of their work, and that fraction is the one to move down a tier permanently.
SideNote Pro records tokens, provider and model per response, so local usage tracking tells you what the experiment actually cost.
Two specific cases people ask about
For coding
Split by whether you are asking about code or reasoning about it. *What does this function do*, *write a regex for this*, *what is the syntax for* are comprehension tasks and rarely need a heavyweight model. *Why does this deadlock under load*, *is this migration safe with concurrent writes* are reasoning tasks, and there the better model earns its cost. Pair the second kind with local folder context so the model sees the actual code.
For writing
Drafting and rewriting are fluency tasks, and small models are strikingly good at them. Where a stronger model shows up is in structure rather than sentences: organising a long argument, spotting that a piece contradicts itself, or telling you which section is doing no work. Draft fast and cheap; escalate when the problem is the shape rather than the prose.