# Skill: Match any task to the correct AI model weight class, context size, and privacy tier

> Lets an AI coding/design agent make a systematic, defensible model selection decision for any sub-task in a project, avoiding both over-spending and under-powering; applies at the start of any feature that calls a model.

Source: sodigi·learn — models/vybor-pod-zadachu · https://sodigi.io/learn/models/vybor-pod-zadachu

## When to use
- Starting a new feature or automation that will call a language model.
- Reviewing an existing pipeline for cost or quality problems.
- Advising a user who says "the AI is too expensive" or "the AI is dumb."
- A project mixes several distinct task types (e.g., classify + generate + analyze a document).

## Core rules
- Take the smallest model that does the job. Start low; dial up only when you hit a proven ceiling.
- Three weight classes: cheap/fast (classification, extraction, routing, bulk volume), mid-tier workhorse (default for writing, explanations, simple code, chat), heavy reasoning (complex code, debugging, multi-step logic, math, architectural decisions).
- Context window is a separate axis: long documents (contracts, codebases, books) need a model that fits the whole document at once.
- Privacy is a binary gate: if data legally or contractually cannot leave your hardware, the answer is always a local model, regardless of cost.
- Model names and versions change constantly; memorize categories, not names.
- A heavy model "overthinking" a trivial task can produce worse results than the mid-tier, not just a more expensive result.
- Do not chop a long document into pieces when a big-context model can hold it whole -- chopping causes the model to lose coherence across chunks.

## Procedure
1. For each task in the project, ask: "Does this actually require reasoning, or is it pattern-matching and extraction?"
   - Pattern-matching/extraction/classification -> cheap/fast.
   - Writing, explaining, simple scripting, chat reply -> mid-tier.
   - Complex logic, debugging, multi-step math, architecture -> heavy reasoning.
2. Check document length: does the full document need to fit in one call? If yes, confirm the chosen model's context window is large enough.
3. Check data sensitivity: can this data leave the building? If no -> local model, end of decision.
4. Apply the cheat sheet:
   - Classification, spam detection, tone analysis, field extraction -> cheap/fast.
   - Email, article, explanation, simple script, chat reply -> mid-tier.
   - Complex code, debugging, multi-step logic, math -> heavy reasoning.
   - Full contract, entire codebase, long book -> big context window model.
   - Medical, legal, client secrets, personal data protected by law -> local on own hardware.
   - Not sure -> start with mid-tier and move from there.
5. If using multiple models in one project, document which tier handles which task -- this is normal and recommended.

## Ready-to-use prompt
```
I am building an automated pipeline. Below is a list of tasks it needs to perform.
For each task, recommend the correct model category (cheap-and-fast / mid-tier-workhorse / heavy-reasoning / big-context-window / local-on-premises) and give one sentence explaining the choice.

Tasks:
[list each task, one per line]

Return a table: Task | Category | Reason.
```

## Pitfalls
- Routing everything to the top/most expensive model "just in case" -- overpays several times for tasks that do not need it.
- Skimping on genuinely complex logic to save money -- a cheap model produces plausible nonsense; verifying it costs more time than the savings.
- Sending private or legally restricted data to a cloud API -- this is a compliance failure, not a cost trade-off.
- Chopping a long document into sequential queries instead of using a model with a sufficient context window -- the model loses coherence across chunks.
- Loading a massive context "just in case" when only a subset is relevant -- pricier and the model is weakest at retrieving information from the middle of a large window.
- Memorizing specific model version names -- they rotate monthly; the category stays stable.