Estimating AI token usage from scratch is hopeless — nobody can predict an exact token count for a ticket they have not built yet. The fix is the same trick that makes story points work: stop estimating absolute numbers and vote on relative tiers instead. Here is a simple five-tier deck your team can adopt today, and how to anchor it to tickets you have already shipped.
Why tiers beat exact numbers
Story points succeeded because they are relative and fast. A team that argues over “is this 13 or 21 hours?” will never finish planning, but the same team can agree a ticket is “a 5” in seconds. Token estimation works the same way. You do not need to predict that a ticket will burn 1.7 million tokens — you need a shared signal that it lands in the “this one is expensive” bucket. For the background on why this sits next to effort rather than replacing it, see story points vs token estimates.
The five tiers
These are the default tiers Token Poker ships with. Treat them as a starting deck and rename them to fit how your team talks.
- Tiny prompt / quick chat. A focused, well-scoped change the model nails in one or two prompts. Renaming a variable, a small bug fix, a config tweak. Minimal context, minimal back-and-forth.
- Normal ticket. A standard feature with some iteration — a few files, a couple of correction rounds. This is your everyday work and a good middle anchor for the rest of the deck.
- “Let it cook.” Meaningful context and real back-and-forth. The model needs to read several files, you refine the approach a few times, and the conversation gets long before it lands.
- Repo archaeology. Agent exploration across a large or unfamiliar codebase. Lots of file reads, search, and context gathering before any code is written. Token usage climbs fast here.
- Call finance. The ticket nobody wants on the invoice — sprawling, ambiguous, and context-hungry. Flag these early so the team can scope them down or pick a cheaper approach.
Anchor the tiers to real tickets
A deck only works if everyone pictures the same thing for each tier. Spend five minutes before your first session picking one recently shipped ticket for each tier — ideally ones where you have a rough sense of how much AI usage they took. Those become your reference points. New work then gets estimated against the anchors (“this feels like a let-it-cook, similar to the auth refactor”) instead of from a blank slate.
What to do when estimates split
Disagreement is the useful part. If half the team votes “normal ticket” and half votes “repo archaeology,” people are assuming different amounts of context or a different implementation path. Talk through why, align on the approach, then lock the tier. That conversation is often worth more than the estimate itself.
From tiers to decisions
Once tickets carry a tier, use it. Re-prioritize low-effort, high-token work, pick a cheaper model for expensive tickets where quality allows, and roll the tiers up into a rough AI budget for the sprint. For the full workflow, read how to estimate AI coding costs during sprint planning — and when you are ready to run a live session, see how to run your first AI-aware planning session.