How to Size AI Credits per User

Don't start from a session-cost guess. Anchor everything on one atomic unit — the tokens a single task consumes — so the estimate stays explainable and you can re-price it by swapping models without redoing the whole thing.

What moves each term — why two “identical” tasks can burn wildly different amounts:

• Breadth → context tokens. Large, tightly coupled codebases force the AI to load more context just to make one safe change. Architecture matters more than raw line count.
• Depth → turns + reasoning. Ambiguous requirements, gnarly logic, and missing tests create more iterations and dead ends — that is what inflates turns and reasoning overhead.
• Code health → tool overhead. Good docs, types, and tests let the AI land changes fast. Legacy code with none of that multiplies exploration and can become the biggest swing factor.

You price the unit last: multiply tokens by the model's rate, then convert to credits at $0.01 each. Every paid license already includes a monthly credit baseline to net against:

Replace assumed numbers with observed ones before you extrapolate. Run a 1–2 week pilot with a representative slice of the team and pull actual per-task token counts from admin telemetry — the GitHub Copilot usage dashboard (and the equivalent Console / admin usage reports for any other tools in the mix).

• Pick a representative slice — a few people from each kind of work, not just the power users, so the sample mirrors the real team.
• Pull per-task token counts straight from the admin usage telemetry instead of estimating them by hand.
• Use the median, not the mean. A handful of giant runs skew the average; the observed P50 is the figure that holds up when you scale out.
• Swap your assumptions out — every placeholder figure below gets replaced by a median measured in your own pilot.

Don't fill a sparse grid. A handful of task archetypes drive roughly 80% of consumption. Estimate those few well and let the long tail average out. Carry each one with both a P50 (typical) and a P90 (heavy) token figure, so you capture the spread instead of a single misleading point estimate.

Illustrative spreads — replace each P50 / P90 with the percentiles you observe in your pilot (Step 2).

The token spread tracks the underlying feature. Use this intensity map to sanity-check which archetypes will land at the high end:

Your calibrated per-task tokens are a clean-room number — real bills are bigger and lumpier. Take the archetype tokens from Step 3 and run them through the adjustments below, then budget on the high (P90) scenario, not the mean.

• Retries & abandoned runs (+20–40%). Dead ends, re-prompts, and runs nobody keeps still burn tokens. Add a flat uplift on top of the base estimate.
• Month-over-month ramp (× growth). Adoption isn't a flat line — apply a ramp multiplier as more people lean in, instead of assuming month 1 equals month 6.
• Model mix (× blended rate). A frontier-heavy mix costs multiples of a lightweight one. Weight by the share of tasks each model actually handles.

• Prompt caching (− cache savings). Repeated context — system prompts, pinned files, shared Spaces — is billed at a reduced cached rate. Subtract it instead of paying full freight every turn.
• Auto / lightweight routing (− rate). Routing simple work to cheaper models pulls the blended rate down further.

Don't ship a single number — ship a range, name the lever that moves it most, and correct it against actuals every week until it converges.

• Low / expected / high. Build the low end from P50 archetypes, the high end from P90 plus the full inflators, and the expected case from your real archetype mix.
• Flag the single biggest lever. It's almost always heavy-user count × tasks per day — a few power users running many agent tasks dominate the total. Call it out explicitly so stakeholders know what to watch.
• Reconcile weekly. Each week, compare forecast vs. actual in the usage dashboard, then nudge your archetype medians and mix. It's a living forecast, not a one-shot estimate.
• Convert to a pool. Take expected tokens/user → credits, multiply by licenses, and net against the included allowance to land the pool size and any top-up.

Budgets can be set at four levels to keep spend predictable:

Common patterns:

• Conservative — disallow overage; rely solely on the included pool.
• Balanced — allow overage with an enterprise budget set 20–30% above included.
• Power-user friendly — high enterprise budget + tight per-user caps on outliers.

Sizing isn't only math — it's also habits. Encourage developers to:

• Use Auto model selection. Let Copilot pick the right model for each request — it routes simple Q&A to lightweight models and only reaches for frontier models when the task genuinely needs them, keeping costs in check without you having to think about it.
• Trim context. Close irrelevant files; curate Spaces deliberately.
• Prefer Chat over Agent for narrow questions — agent mode is far more credit-intensive.
• Start a fresh chat for new topics. Long-running conversations carry their full history into every request, which grows the credit cost. When you switch tasks, open a new chat instead of piling onto the old one.

Tell us your team's composition and roughly how many interactions each persona has per day — we'll work out the AI credits and what you'll need to top up beyond the Copilot Business included allowance. Aligned with GitHub's usage-based billing model launching June 1, 2026.

Baseline assumption: ~3 credits per chat question and ~80 credits per agent run (Auto model selection, average task complexity).

• 1 · Anchor on tokens / task — (context × turns) + output + overhead; price it last so you can re-model by swapping models.
• 2 · Calibrate on a 1–2 week pilot — pull real per-task tokens from admin telemetry and use observed medians, not assumptions.
• 3 · Collapse to 3–5 archetypes — the ones driving ~80%, each carried as a P50 and a P90.
• 4 · Inflate, then deflate — +20–40% retries, a ramp multiplier, and model mix; subtract prompt-cache; budget on P90.
• 5 · Ship a low / expected / high range — flag the biggest lever (heavy users × tasks / day) and reconcile weekly.