AI capacity planning is the discipline of matching AI supply to AI demand before the mismatch becomes an outage or an invoice surprise. Manufacturers have done this for a century. A plant manager does not wait for the assembly line to stop to discover a shortage of steel. Engineering teams running on large models are effectively running a plant, and most of them are still planning capacity by reacting to the alert.

The reason this is hard is that AI supply has more constraints than a server fleet. It is not only compute. It is provider rate limits, token throughput, context window ceilings, model availability across regions, and a budget that finance expects to be predictable. Any one of these can be the binding constraint in a given week, and the binding constraint moves.

Model demand as a forecast, not a hope

Good AI capacity planning starts by forecasting demand in units the providers actually meter. Requests per minute and tokens per minute, split by model, are the real currencies. A team that forecasts in vague terms like heavier usage next quarter has not forecast anything. The inputs are knowable.

  • Product roadmap. Features shipping in the next two quarters, each with an estimated call volume and token profile.
  • Traffic seasonality. The daily and weekly peaks, because rate limits bite at the peak, not the average.
  • Agentic amplification. The multiplier from autonomous workflows, where one user action can trigger dozens of model calls.
  • Model migration. Planned moves to newer models, which reset both the price and the throughput assumptions.

Planning against constraints you do not control

A subtle part of AI capacity planning is that much of the supply sits with a provider. You can add servers to your own fleet in an afternoon. You cannot always raise a provider rate limit that quickly, and a new model release can change the economics of your entire plan overnight. This is a genuine supply chain, with lead times and single points of failure, and it should be planned like one.

The practical response is to build slack and optionality. Reserve headroom against forecast peaks rather than averages. Qualify more than one model for critical paths so a single provider limit is not a single point of failure. Negotiate committed throughput ahead of the roadmap, not after the first throttling event. AWS, GCP, and Azure regions differ in model availability, and routing across them is a legitimate capacity lever.

The cost dimension is part of capacity

Capacity is not only whether the request succeeds. It is whether it succeeds within budget. A plan that meets demand by quietly tripling spend has failed a different constraint. AI capacity planning should carry a cost forecast alongside the throughput forecast, so that finance sees the number before the month closes rather than after. The two forecasts are the same exercise viewed from two sides.

Why this is a leadership function

Left to individual engineers, capacity gets planned per service, which guarantees that the aggregate is a surprise. Toyota's advantage was never a single efficient station. It was that the whole line was planned as one system. AI capacity planning done at the organization level lets a leader see total committed demand against total secured supply, and act on the gap while there is still time to act.

The payoff is that AI stops being a source of quarterly surprises and becomes a planned input, like any other. Teams that plan capacity ship features on schedule because they secured the throughput in advance. Teams that do not spend their credibility explaining the last outage. Begin with a single forecast, in tokens per minute per model, covering the next two quarters, and reconcile it against your current limits. The gaps you find are the plan.

A simple model to start with

Sophisticated capacity models can wait. A first pass at AI capacity planning fits on a single sheet. List each production workload, its current tokens per minute at peak, and its provider rate limit. The ratio of the two is your headroom, and any workload above roughly seventy percent of its limit at peak is a near-term risk that deserves attention now rather than after the next incident.

Then layer the roadmap on top. For each feature shipping in the next two quarters, estimate the peak load it adds and assign it to a model. Sum the demand, compare it to secured supply, and the gaps become a short list of actions. Raise a limit here, qualify a second model there, add a transition reserve for the planned migration. That single sheet, revisited each month, catches the large majority of capacity surprises before they reach a customer, and it costs an afternoon to build.