Which AI model for which task

Every AI task has a shape. A translation, a summary, a plan with ten parts and a piece of code that has to compile are not the same job, and they do not deserve the same model or the same spend. This article explains how Cortex66 chooses, and why the choice is always written down before anything runs.

The receipt comes before the answer

Describe a task. Before anything runs you see the model we would pick, the most it can cost, who checks the result, and the reason. That is the receipt, and it is the first thing you see, not the last. On the public picker the receipt is an example computed in your browser from a small, versioned rule set: no model is called and nothing is sent. In a workspace the same receipt is real, and the reason on it is the reason the system used.

The cheapest tier that passes its check

Cortex66 does not start from the strongest model. It starts from the cheapest tier that has a fair chance at the task, and a check decides whether the answer is good enough to keep. When the check fails, the task climbs one tier and runs again, inside the cap you already accepted. The result is that routine work stays cheap and hard work gets the model it needs, without you having to know the catalogue by heart.

Three things shape the choice in a workspace:

• Your own keys. The models on the keys you connected come first. A task that needs a model you did not add is shown as blocked, with the reason, instead of silently going somewhere else.
• Your budget. The cap on the receipt is reserved before any paid call. If a price is unknown, the task does not run.
• What each model has done well for you. The choice uses what worked before in your workspace, and the receipt says so.

You can override it

The picker is a starting point, not a verdict. In a workspace you can choose another model for a task, and the receipt shows the new cap. The system remembers what you picked and why, so the next receipt starts closer to what you wanted.

When a provider goes down

Providers have bad hours. Each lane (a model on one of your keys) has a health score built from its errors, slow answers and the provider's own rate-limit signals. A lane that keeps failing is switched off until it recovers. If your first choice is down before anything is sent, the task goes to your next key; the receipt shows the switch and the cap does not change. A call that already left is never sent twice: if its outcome is unknown, it is checked first, so you never pay twice for one answer. The long version is the guide on provider outages.

What this means in practice

• Short, well-defined tasks (translate, rewrite, extract) go to a cheap model and usually stay there.
• Tasks with a check that can be written down (code that must compile, a format that must match) climb only when the check fails.
• Open-ended work (a plan, a long argument) starts higher, because a cheap first attempt would cost more in retries.
• Private work can stay on a local model while the rest uses a cloud model; each receipt says which one ran.

Try the picker with a sentence of your own, then read how your own keys and the cost cap fit in.