Seats that bring their own credits

Shipped today: when a company has more people than its plan includes, each of those additional seats now adds credits to the company's AI allowance. Growing the team raises the AI budget rather than spreading the same budget thinner across more people.

The problem this fixes was quiet but real. A plan's AI allowance used to be a fixed number regardless of how many people were in the account, so a company of seven and a company of fourteen on the same plan drew from an identical pool. That is exactly the wrong incentive. It made every new colleague a small tax on everyone else's ability to use the assistant, and the natural response to that is to ration access — which is the behaviour we built per-company pricing to get rid of in the first place.

The formula is simple enough to state in one line. The enforced pool is the plan's own allowance, plus the number of seats above your plan's included headcount multiplied by that plan's per-seat credit rate. On the paid plans that rate is currently 5,000 credits per additional seat. It is a field on the plan rather than a constant in the code, so an operator can change it and the enforced pool moves with it — the number that gets enforced is the number that is configured, with nothing hardcoded in between.

Two details are worth knowing. Only seats above your included headcount count toward this, because the included ones are already paid for inside the base allowance. And the credits land in every allowance window your plan uses, not only the monthly one, so an extra seat also raises the shorter-window limit that stops a single busy afternoon from consuming the month.

There is one case we deliberately excluded, and it is the sort of thing that only ever surfaces as a customer being refused for the first time. If a plan leaves one of its allowance windows switched off, seat credits are not added to it. Adding a number to “no limit set here” would have silently converted an absent limit into a real one, and the person who found out would have found out the hard way.

Now the part that is not a win, and it matters more than the feature. Nothing charges for a seat today. The seat price is designed, it is configured per plan, and the product can tell you what a seat would cost, but no invoice includes it — an invoice today is the plan price and nothing else. So “paid seats grant credits” describes an entitlement rule that is live in the code and a price that is not yet billed. We would rather write that sentence than let you infer a bill that does not exist.

The credit meter is now on. The allowances are published, the arithmetic is live and tested, and the usage panel draws a bar for each active window because there is a real counter to draw from. A request that runs out of credits is refused with a plain message naming which shield tripped and when it refills, and a chat turn refused for credits carries a Retry that only actually fires once the window has rolled or a top-up has landed — a button that would be refused again isn't help. The older per-plan token limits still exist as a belt-and-braces backstop underneath.

That is an unusual amount of hedging for a release note, and it is on purpose. The interesting claim here is not “we shipped a feature.” It is the shape of the rule: capacity should scale with the size of the team that uses it, and the pool a customer is measured against should be the pool the code actually computes. Both of those are now true. The billing that sits on top of them is a separate thing, and we will say so until it isn't.