Why AI credits should be pooled, not per-seat
Somewhere in your software budget there is a line that did not exist three years ago: the AI add-on. Per seat, per month, on top of the licence, and increasingly non-optional. It is worth slowing down on that pricing shape, because it quietly misprices what AI in a planning tool actually is, and your team pays the spread.
Seats price access; AI is consumption#
Per-seat pricing makes sense for software whose cost to serve scales with people: another user, another login, another support surface. The marginal cost of an AI feature scales with something else entirely: invocations. Tokens. Compute. A team of ten where two people build plans weekly and eight mark tasks done consumes roughly the same AI as two heavy users alone, but under a per-seat add-on it pays for ten.
That mismatch has a name in pricing theory (bundling a metered resource into an unmetered access fee) and a predictable set of symptoms in practice:
| Symptom | Cause |
|---|---|
| "Do not buy the AI seat for the contractors" | Paying per head for a per-use resource forces head-by-head rationing |
| Heavy users hit invisible "fair use" throttles | The vendor metered it anyway; they just did not tell you |
| The add-on price creeps annually | Your usage is opaque to you, so the price negotiates against a feeling |
| Nobody can say what the AI costs per plan | Because nothing is denominated in plans |
The deeper problem is behavioural. When AI is priced per person, teams optimise the wrong variable: who gets to use it, instead of what it is worth using on.
Pooled credits price the resource#
Topolog's model is the boring alternative: a workspace holds a shared pool of credits; AI operations spend from the pool at fixed, published rates (a full Express or Structured plan build costs a flat amount; small assists cost small amounts); anyone on the team can spend; nothing is charged for existing. Ten people and two heavy builders cost what two heavy builders cost.
Fixed rates do real work here. A plan build is a complex, multi-stage pipeline (decomposition, review panels, validation loops, calibration: the machinery), and its raw compute cost varies run to run. Pricing it as one flat number moves that variance onto us and gives you the thing procurement actually needs: a denominator. "A built plan costs N credits" lets you compute cost per project, compare it to an afternoon of a senior person's planning time, and decide with arithmetic instead of adjectives. (That comparison, incidentally, is the one to run when evaluating any tool's AI economics: total cost of ownership per outcome, not per seat per month.)
Pooling also fixes the behavioural distortion. A shared pool makes AI spend a team resource allocated by value ("is this gnarly programme worth a build?") rather than a status good allocated by job title. The intern planning the offsite can spend a build; the CTO who lives in the source tab spends nothing. Nobody files a ticket to get a seat upgraded.
The exit valve that keeps it honest#
A pooled-credit model still leaves one failure mode: a vendor could make the credits themselves the lock-in, pricing captive usage upward once you depend on it. The structural defence is an exit valve, and it is why the pooled model and bring your own AI are really one design. The planning language is public; the validator judges any author identically; so the heaviest AI workload (drafting) can be done by a model you already pay for, at zero marginal cost from us, in a chat window this afternoon.
That option disciplines the pricing permanently. Built-in builds have to be worth their credits against a free alternative that is always one paste away, which means they have to compete on convenience and pipeline quality (the review panels, the integrated validation loop, the one-click-ness) rather than on captivity. Pricing that has to stay cheaper than your exit is pricing you can trust long-term, in a way no contract clause replicates.
The quiet summary: metered things should be metered, shared things should be shared, and the door should never be locked from the inside. It is not a sophisticated pricing philosophy. It is just the one that does not require your team to count heads before asking a question.