# Skill: Control AI token spend with depth selection, cost tracking, and model routing

> Lets an AI coding agent manage its own usage cost by trimming input context, specifying response depth, routing tasks to cheap vs. expensive models, and prompting the user to monitor spending -- applies whenever the user is working on a project with recurring AI calls.

Source: sodigi·learn -- vibecoding/tokeny-i-dengi · https://sodigi.io/learn/vibecoding/tokeny-i-dengi

## When to use
- User is starting a new project session and wants to control AI costs.
- User is asking for information or code edits that do not require a detailed response.
- User has multiple models available and wants to route calls cost-effectively.
- User notices the bill growing faster than expected and wants to diagnose the leak.

## Core rules
- Charge happens on both input tokens (everything sent to the model) and output tokens (everything the model generates). Output tokens cost more per unit.
- Rough conversion: **1000 tokens ~ 750 words ~ 1.5 pages of text.** A 5000-line file = tens of thousands of tokens, paid on every message that includes it.
- Default to **short** answers (2-4 sentences, just the gist) unless the user explicitly asks for more detail. Announce that you are doing this.
- **Never load the whole project** into context. When you need a file, request only the specific file -- not everything at once.
- Route by task complexity: simple/routine tasks (renaming, small fixes, text tidying) go to the cheapest model; complex tasks (architecture, large analysis, multi-file refactoring) justify a more capable model.
- **Cache** long, unchanging instructions (project rules, persona briefings) rather than resending them in every message.
- Do not maintain a single endless chat for different tasks. Close and start fresh at logical task boundaries to prevent history from growing unbounded.
- Rough model cost ratios (2025-2026 ECC figures): Haiku 4.5 = 1x, Sonnet 4.6 = ~4x, Opus 4.5 = ~19x. Never use the 19x model to rename a button.

## Procedure
1. At the start of a session, confirm the answer-depth mode: short / medium / detailed.
2. Identify which model tier fits the current task. For simple tasks, name a cheaper model; for hard tasks, name a capable one and explain why.
3. When loading context, name the specific file(s) needed -- do not dump the full project.
4. After completing a chunk of work, remind the user to check today's spending.
5. If the conversation history has grown large (dozens of turns), suggest starting a fresh session for the next unrelated task.
6. If a long project-level instruction repeats in every message, propose caching it.

## Ready-to-use prompt
```
Help me build [describe the project]. Ground rules to keep costs sane:

1. Do not load the whole project into context. When you need a file,
   ask me for the specific one.
2. Answer in short mode by default: just the gist and the code I need.
   Longer explanations only when I ask.
3. For simple edits (renaming, minor fixes), use the cheapest available model.
   For genuinely complex tasks, flag it and ask before switching up.
4. At the end of each work block, remind me to check today's token spend.
```

## Pitfalls
- Dumping the entire project into every message -- you pay for all of it in every single request.
- Ordering verbose output by default -- output tokens cost more than input; a wall of text is expensive.
- Running everything on the most powerful model "just to be safe" -- 19x the cost for the same result on routine tasks.
- Living in one endless chat across all tasks -- the growing history is paid for on every turn.
- Repeating the same long system prompt in every message without caching it.
- Never checking the spending meter -- costs creep up invisibly until they hurt.