You can now estimate a monthly bill and compare workflows by cost per useful result. This final lesson in the Models tab turns both skills into protection: a small set of spending guardrails and a one-page policy you keep with your project.

Agents are powerful precisely because they keep going — reading, trying, retrying. That persistence is also what makes an unattended loop the most expensive object in this entire course. A guardrail is simply a decision you make before the loop starts about when it must stop and ask.

Three kinds of work need three levels of freedom

Not every AI call deserves the same budget:

A research experiment. You are comparing models, testing prompts, learning. Spend is for information. Keep it small, time-boxed, and logged — the point is the lesson, not the output.

A production feature. Real users trigger it. The formula from Lesson 12.1 governs: cost per request × requests × users. This needs a per-task budget and a monthly cap, reviewed like any other operating cost.

An unattended agent loop. An agent working through the night with tool access, no human watching. This is where bills (and mistakes) compound. It needs the tightest limits: an allow-list of models, a maximum output size, a stop condition, and explicit approval before long runs.

Name which kind of work you are doing before you start. Most spending surprises come from running an experiment with production freedom, or a loop with experiment discipline.

Six guardrails that actually work

These connect directly to the OpenRouter credits, routing choices, and approval boundaries you met in Class 06 and Class 10.

No single guardrail is enough. The per-task budget stops one runaway loop; the monthly cap stops a thousand small ones. The allow-list controls price per token; the output limit controls tokens per task. Approval handles judgment; logging makes the next estimate honest.

A practical note on setup: most providers and routing layers (including OpenRouter credits) let you set credit limits and view per-request usage. Use them — but treat the dashboard as the enforcement of a policy you wrote, not a substitute for one.

Your personal model policy card

Keep this in your project context files — beside CONTEXT.md — so every future session (and every agent) inherits it. One page, no essays.

# Model Policy — [project name] — [date]

## Defaults
- Default model: [name + provider/route]
- Inexpensive model: [for routine drafts, triage, summaries]
- Hard-problem model: [for reasoning, final code, public output]

## Boundaries
- Privacy-sensitive workflow: [what stays local, what needs approval before sending]
- Never send: [secrets, credentials, customer data, unreleased material]

## Spending
- Per-task budget: [e.g. $0.50 research, $2.00 production task]
- Monthly cap: [e.g. $40] + alert at [e.g. $30]
- Max output / steps per task: [e.g. 2,000 tokens, 8 tool steps]
- Approval required before: [long loops, full-repo changes, bulk jobs]

## Evaluation habit
- Acceptance test for this project: [tests pass + browser check + short review]
- Log on important work: [model, tokens, cost, attempts, correction minutes]
- Review date: [revisit prices and defaults monthly — prices change]

Write it once, date it, and revisit it. Model prices move fast enough that a default chosen this quarter can be wrong next quarter. The review date is part of the policy.

Practical exercise: write your first AI-usage policy

Finish line: a filled-in policy card saved as MODEL-POLICY.md in your project.

1. Copy the card above into MODEL-POLICY.md. 2. Fill in your three models (default, inexpensive, hard-problem). If you have not run a fair test yet, pick provisional answers from the Class 08 selection card and mark them provisional. 3. Set a per-task budget and a monthly cap in real dollars. Add the privacy line: what must never leave your machine without approval. 4. Define your acceptance test in one sentence — what “done and accepted” means for your project. 5. Show it to one real or imagined teammate and ask: “Could you run an agent task inside these limits without asking me anything?” If not, simplify.

Verify: run one small agent task inside the policy. Did the agent stay within the step and output limits? Did you log model and cost? Common failure mode: limits so tight nothing finishes, or so loose they never trigger. Adjust the numbers after one real run.

Check your understanding

1. What is the difference in spending risk between an experiment, a production feature, and an unattended loop? 2. Which two guardrails stop a single runaway task, and which stop slow overspending across a month? 3. Why does an allow-list matter even when you trust the agent? 4. What should you log after important AI work, and why? 5. Where should your model policy live, and how often should you revisit it?

Completing the Models tab

You started this tab asking what sits inside an AI system. You can now trace a request from your words through the agent, the routing layer, and the selected model to files, tests, and a live product — and you can say which layer failed when something breaks.

You can choose a model by task fit instead of hype, read a leaderboard and a model card without being fooled, keep context deliberate and compact, route across providers with fallbacks and privacy boundaries, evaluate open-weight and Chinese model families on evidence, and — from this class — estimate the bill, compare by cost per useful result, and hold an agent inside limits you set.

That is the complete Models skill set: what the model does, which model fits, and what it costs to run.

From here the course turns outward — to the tools, data, infrastructure, and agents you will operate around these models. Keep your MODEL-POLICY.md. Every tab after this one spends something, and you now know how to count it.