How to get past watching tokens

I think there’s a bit of an issue with how we treat AI.

For the first time ever, it’s our work that costs money. Not the servers it runs on or the tools we use to do it, but the work itself. A day of an engineer pushing hard in Claude Code can cost more than the EC2 instances behind their service, and more than their Adobe subscription. There’s a significant additional cost to our outcomes, and it shows up on a bill every month.

So people watch the tokens. They check the usage page, switch to a cheaper model halfway through a job, and stop a run that’s going well because it’s getting expensive. I get why. But watching a meter tells you what you spent, not what you got for it, and it makes everyone timid at exactly the moment they should be finding out what this can do.

Give the problem a budget

I think if you treat tokens as a budget you assign to a problem, rather than a meter you watch, the issue gets easier. You decide up front what a problem is worth trying, spend it properly, and judge the result.

Run this scenario:

1. Pick a problem. Any problem.
2. Assign $150 in tokens to it.
3. Write down, in your own words, what makes it slow, and aim the budget at that.
4. Then spend another 25% tuning it.

Rinse and repeat.

The third step is the important one. “Make the release process better” is a wish. “Releases are slow because someone has to read every changelog and work out which services are affected” is a target. Your words matter because you know where the time actually goes, and the agent doesn’t until you tell it.

The tuning matters too. The first pass gets you something that works. The extra 25% is where you go back over what you aimed at, tighten the prompt or the skill, and run it again with what the first pass taught you.

Then go bigger

If you get to the end of it without any gain, it probably was the wrong scenario. That’s fine. You’ve spent $150 finding out, which is cheaper than most meetings about whether to try it.

But if you get gain, pick another problem and assign $1000.

Then keep going. Pick bigger and harder problems each time. Tap your friendly engineer on the shoulder and really push what it can do. A budget gives people permission to spend on something that matters, and to see what comes back.

This is the same argument I made about what a design actually costs. The number that tells you something isn’t the token count, it’s the cost of the outcome, and you only get that by spending enough to finish the job and checking what you got.

Final thought

How do you get past watching tokens? Stop treating them as a running cost and start treating them as an investment in a problem. $150, aimed at what makes it slow, with a bit extra to tune it. If it pays, go again with $1000 and something harder.

So pick your first problem this week, and write down what makes it slow before you spend a cent.