Where the tokens actually go
Open a long skill run and the transcript is mostly not the answer. It is the skill text and its references, the schemas for every available tool, the growing transcript of prior steps, and the full body of each tool result, re-sent on every turn, because that is how a conversation works. A twenty-step skill does not cost twenty units of work; it costs something closer to the sum of a context window that keeps growing, twenty times over.
Why the bill grows faster than usage
Usage grows linearly with how often the skill runs. Cost grows faster, because teams that find a skill useful also make it better: more references, more examples, more tools, more edge cases. Each improvement adds context that every future run pays for. This is the uncomfortable shape of skill economics: the more proven a skill becomes, the more expensive each repetition gets.
Prompt caching lowers the price of re-reading. It does not remove the re-reading.
A cheaper model lowers the unit price. It does not remove the turns.
What actually reduces the cost
There are three honest levers, and they are not equal. Lower the price per token by switching models or enabling caching. That one is real and bounded, and it leaves the architecture alone. Shrink the context by trimming references and filtering tool output. That one is real too, and it fights the improvements that made the skill good. Or remove the model calls entirely for the steps that no longer need a decision. Only the third one gets cheaper as the skill gets more proven, because a settled step never needs deciding again.
Which steps still need a model
Most of a mature skill is not judgment. Validating a field, routing on a threshold, formatting a payload, calling an API in a fixed order, checking a required condition. These had one correct implementation the first time and have the same one now. What genuinely needs a model is classifying something ambiguous, drafting language for a human, or deciding when unstructured input does not fit any known case. Rote's compilation step makes that split explicit rather than leaving it implied, so you can see the remaining inference surface instead of guessing at it.
How to check this on your own skill
Before changing anything, measure. Count the runs per month, the average input and output tokens per run, and the share of turns that made a genuine decision versus executed a known step. Multiply by current model prices and record the date, because prices move. Then run rote eval on the skill for an assumption-visible estimate, and rote eval --run when the real tools are available to compare both implementations against the same cases.
Frequently asked questions
Why are my Claude skills using so many tokens?
Because a skill is re-read on every run. Each turn resends the skill text, its references, the tool schemas, the transcript so far, and the full body of prior tool results. A long, well-developed skill has a large context, and a repeating skill pays for that context every single time it executes.
Does prompt caching solve expensive skills?
It helps and it is worth enabling, but it addresses the price of re-reading rather than the fact of it. Cached input still costs money, cache entries expire, and caching does nothing about the number of model turns a multi-step procedure takes. For a procedure that has stopped changing, removing the turns is the larger lever.
When should I compile a skill?
Keep one-off exploration in an agent. Compile a skill after the procedure is proven, repeats often, and needs lower cost, faster execution, regression tests, explicit approvals, or reliable retries.
Compile a workflow
Inspect the open-source CLI or run a compilation in Rote Cloud.