Passed 21 of 22 test cases with the skill, and 14 of 22 without it.
Without skill64%
With skill95%
Checks it passed that the model alone missed
Requires recording the cap and savings in a weigh-in log.
Directs logging the specific cap and financial savings into a weigh-in log.
Specifies keeping a weigh-in log with receipts showing before and after spend.
and 8 more in the full report
7 fixed14 passed either way1 still failing0 broke
Pass-rate lift
+32 pp
Tokens
-44%
Agent turns
0%
Response time
-58%
Model gemini-3.6-flashMeasured 8/4/2026v121 of 22 cases passed with skill
Tokens, turns and time describe resource use, not a dollar price.
See it in action
One of 7 test cases the skill fixed. Same model, same prompt, with and without the skill.
1 of 7
Prompt
When evaluating LLM budget management for system architecture design tasks, which category does this fall under?
What was checked, without and with the skill
Checked
Without skill
With skill
Classifies system architecture design as a heavy task requiring full reasoning budget.
Missed
Passed
case-19 · gemini-3.6-flash · 8/4/2026 · answers are capped and redacted
What's inside
The instructions your model reads when the skill loads.
SKILL.md33 linessingle file
Think Light
Reasoning tokens bill like output tokens, and models usually lock their
answer early in the chain; the tail is often narration you pay for. Light
tasks get light thinking. Save the heavy reasoning for the problems that
are actually heavy.
Method
Sort your recurring tasks into two piles:
light: lookups, renames, formatting, single-file edits, commit messages,
questions with one right answer. Extended thinking rarely changes these.
heavy: multi-file refactors, architecture calls, debugging across
boundaries, anything where the first idea is usually wrong. Thinking
earns its tokens here.
Cap the light pile. Use your agent's thinking controls: effort levels,
a thinking-budget setting, or per-request flags. Cut the budget hard for
light tasks; leave heavy tasks alone at first. Prefer per-session or
per-request controls: a cap written into settings outlives the task, and
a cap in project settings caps your teammates too. Never ship a cap in
shared config.
Verify before keeping. Rerun two or three recent real tasks from the
capped pile and compare results against what you got uncapped. Same
quality: keep the cap. Worse: raise it back and say so.
Log what you capped and the before/after spend in the weigh-in log, so
the saving is a receipt, not a feeling.
Hard Rules
Never keep a cap you did not verify on real tasks.
Caps are per task type. A global cap is a blind cap.
If quality dropped, the cap loses. Raise it back without ceremony.
Record the cap and the saving. Unmeasured savings do not exist.