Handler Capacity

Capacity is how much work a Handler can take on. Every full-time Handler comes with a base allocation of it for each billing period, and most of the time a Handler stays inside that.

Two things can carry work beyond the base allocation: overage pricing, which applies to each Handler on its own, and capacity pooling, an enterprise capability that shares the overage across several Handlers. Both are arranged as part of your plan rather than switched on by default, so talk to your account team about which of them you want on your Handlers. The order they work in matters: a Handler always draws on its own base allocation first, and only what it uses beyond that becomes overage.

---

What Capacity Measures

Handler capacity is a combined measurement of all the work your Handler does — one figure covering everything it takes on, rather than a row of separate meters for you to reconcile.

That matters because a Handler’s work is genuinely varied. Reading a messy email thread, calling out to your order system, running a custom tool, keeping its own notes — these are different kinds of work with different underlying costs, and they don’t arrive in fixed proportions. Combining them into one measurement is what lets an allocation be about how much work a Handler does, rather than about which shape that work happened to take this month.

Plenty of things feed into that figure, and how much each contributes is weighted on our side. We don’t publish the exact weights. They change as models and infrastructure change, so any table we published would be out of date within the month — and it would invite tuning your operations for the table rather than for the work, which is the opposite of the point.

---

What Contributes to It

Some examples of what a Handler’s capacity accounts for:

• Model use — not every model uses the same capacity, and Handle manages that choice for you, weighing speed, cost and intelligence against the situation at hand. A step that needs deep reasoning and a step that just needs a field pulled out of a document don’t draw the same amount.
• Integration use — the calls a Handler makes out to external services on your behalf. A small amount each, but they count.
• VPN use — where an enterprise Handler reaches systems on your own network over a VPN, the traffic it routes through it.
• Code-tool use — the compute a Handler spends running the custom tools written for your operations.
• Internal services — the platform services a Handler leans on to do its job, such as the SQLite database it keeps its own working data in.
• File storage — the documents, attachments and exports that pass through a Handler and the ones it keeps.

That isn’t the complete list, and it isn’t fixed. If you want to know how a particular workload is likely to land, your account team can look at it with you rather than have you work it out from a table.

---

Overage Pricing

Overage pricing is available for every full-time Handler, and it applies to each Handler’s capacity individually.

• Each Handler has its own base allocation, included in its plan. It isn’t shared with any other Handler.
• A Handler that reaches its allocation can keep working. Where overage is enabled on your plan, the work it takes on beyond the base is billed as overage rather than stopped.
• Overage is measured per Handler. A heavy month for one Handler does not reduce the base allocation or the availability of any other Handler.

Short spikes don’t need overage at all — the Full-time plan includes burst capacity for high-demand periods. Overage is for a Handler that has taken on sustained work beyond what its base allocation covers.

Because overage is attributed per Handler, a busy period belongs to one Handler rather than to the account. If your accounts Handler runs hot at end of month, that is where it shows up.

Overage rates are part of your plan rather than a published rate card — talk to us for the rates that apply to your Handlers.

---

Capacity Pooling

Capacity pooling is an enterprise capability. It lets an organisation running several Handlers share pooled capacity between them, so the account is sized as a whole rather than Handler by Handler.

Pooling applies to overage — the usage above each Handler’s base allocation — not to the base allocations themselves:

1. Each Handler keeps its own base allocation. This is the part that is never pooled, and it is what protects a quiet Handler from a busy one.
2. Overage above the base draws on a shared pool agreed for the account, instead of being billed against each Handler separately.
3. The pool is sized for the account. A month where your support Handlers are stretched and your finance Handler is idle is absorbed by the pool, rather than showing up as overage on one Handler and unused allocation on another.

This is why the enterprise plan describes the feature as overage pooling across Handlers. A Handler taking on far more work than expected spends from the shared pool once its own base allocation is used — it can never reach into another Handler’s base allocation. Every other Handler on the account still has the capacity it was allocated.

Arranging Pooling

Pooled capacity is set out in your enterprise agreement. Your account team works with you on:

• Which Handlers are in the pool
• The base allocation for each Handler in it
• The size of the shared overage pool, and any cap you want on what the account can draw from it

Talk to us if you are running multiple Handlers and want capacity sized across the account rather than per Handler.

---

The Two Side by Side

Capability	Available on	Base allocation	Usage above the base
Overage pricing	Every full-time Handler	Per Handler	Billed to that Handler
Capacity pooling	Enterprise	Per Handler — never pooled	Drawn from the shared pool

See also: What LLMs Can I Use With Handle? for how Handle picks a model for each step of the work, and Inspecting a Task for seeing what a Handler actually did with the work you gave it.