Think light
Five agent skills that cut your coding agent's token weight: weigh in, read the bill, slim the replies, cap the thinking, cut bloated sessions. Claude Code, Codex, Cursor, any SKILL.md agent.
npx -y skills add brenbuilds1/cutweight --skill think-lightAssembled from the repository path, not quoted from the project. Check it against their README if it does not work.
2 things to look at
- 26 days oldThe repository was created 26 days ago. New is not bad, but a brand new repository carrying a familiar-sounding name is the shape a typosquat arrives in, and there has been no time for anyone else to find a problem with it.
- 2 stars2 stars. Stars are a popularity signal and not a quality one, but at this level it is likely that nobody has read this closely except its author, and you would be relying on your own review.
What its author says it does
Copied from the file, not written here
Cut reasoning-token weight. Use when thinking or reasoning tokens dominate the bill, when asked to cap a thinking budget, lower effort, or stop simple tasks from burning extended thinking. Light tasks get light thinking: matches thinking budget to task weight, then verifies accuracy held before keeping any cap. Never caps blind.
SKILL.md
1.9 KB, as published. Nobody here has run it
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.