S
Glossary
Seat-Based Credit Pool
A seat-based credit pool is a shared balance of credits sized by the number of paid seats. Each seat adds a fixed credit allotment to one account-level pool, and any seat can draw from it. Per-seat allotments differ: each user's credits stay private and can't move to a teammate.
Key Takeaways
A pool equals paid seats times credits per seat. GitHub's docs count 100 Copilot Business users at 1,900 credits as a 190,000-credit pool.
Pooling lets light seats cover heavy ones, and it also lets one seat's heavy use leave less for everyone else.
Per-seat allotments stop one user from drawing on teammates' credits and strand credits when a heavy seat hits its limit.
Seat changes, rollover, and expiry vary by vendor, so each needs a written rule.
How does a seat-based credit pool work?
A seat-based credit pool multiplies paid seats by a fixed allotment and funds one shared balance with the result.
GitHub Copilot pools included credits at the billing entity, and Runway's Team plan adds 6,900 credits per seat each month to one balance. In hybrid seat and usage pricing, the pool is one way to share the included usage.
Each paid seat adds its allotment to the pool, and usage deducts through credit burn-down until the pool hits zero and the account blocks or bills overage.
The arithmetic uses Runway's 6,900 credits per seat across five seats. One seat consumes 60 percent of the pool (20,700 credits) and the other four use 2,000 each.
Pooled | Per-seat | |
|---|---|---|
Credits available | 34,500 shared | 6,900 per seat |
Heavy seat's 20,700 credits | Fully covered | 6,900 served, 13,800 unmet |
Other four seats' use | 8,000 | 8,000 |
Credits left over | 5,800 | 19,600 |
How do pooled and per-seat credit allotments compare?
Pooling absorbs heavy users and per-seat allotments contain them, and each gives up what the other does well.
Axis | Pooled | Per-seat |
|---|---|---|
Heavy-user absorption | Light seats' unused credits cover a heavy seat | A heavy seat hits its allotment while teammates' credits sit idle |
Cost predictability | Included credits are fixed, but the day the pool empties isn't | Each user's allotment is fixed, and usage traces to one user |
Abuse risk | One seat's heavy use leaves less for everyone | A heavy user's allotment is spent on that user alone |
Admin controls | One balance, and GitHub documents user-level budgets to restrain a single draw | Each seat's allotment is a built-in limit, but credits can't move between users |
Cursor Teams takes the per-seat route with no transfers between users, and its docs call the amount a usage allowance. Windsurf's legacy credit-based Enterprise plans attach credits to the seat. Both start from per-seat pricing, and the credit version is credit-based pricing.
What goes wrong with a seat-based credit pool?
Pools fail where one user, seat change, or expiry date affects the whole team.
One seat uses most of the pool. GitHub answers with user-level budgets that cap one person's draw from the shared pool, which works as a per-user spending cap.
Seat changes mid-cycle. GitHub grows the pool immediately when you add a license and shrinks it only at the next cycle after a removal. Cursor keeps the seat of a removed member who used credits occupied until the cycle ends and prorates adds (see proration credit). On Windsurf, a replacement inherits what the departing member used.
Rollover and expiry. Runway rolls unused credits over for a month, while GitHub forfeits them and resets the pool at 00:00:00 UTC on the first of each month. Credit rollover covers the rules.
How do teams implement a shared seat pool?
Teams implement a shared seat pool with one wallet at the account level, a recurring grant sized as seats times allotment, and written rules for deduction order, rollover, and behavior at zero. The decisions to settle before launch:
Wallet location: the account, or a parent above child accounts.
Grant size: median use per seat, not the heaviest user.
Per-user limits: whether one seat can draw the whole pool.
Deduction order: which grant burns first when prepaid credits and promotional credits coexist.
Rollover and expiry: per grant or wallet-wide.
Flexprice is enterprise-grade, open source usage based billing infrastructure for AI and SaaS companies. It can be deployed in your own VPC, on-prem, or on Flexprice's managed cloud. Credits and Wallets covers recurring credit packages that auto-renew, rollover rules, stacked credit types with custom deduction priority, and a choice at zero between charging the payment method and blocking usage. Parent-child accounts are supported too. CASParser set up metering in two developer days. "It just magically works behind the scenes. There's almost negligible lag around updation of the quotas." - Sameer Kumar, Founder, CASParser. Book a demo.
Related terms
Seat pools sit where a flat seat fee meets metered credit use.
Credit-based pricing is the model that defines what a credit buys.
Credit burn-down is the deduction process that drains the pool.
Hybrid seat and usage pricing adds metered overage on top of the seat fee.
Per-seat pricing is the flat fee that funds each seat's contribution.
AI credits are a common unit for token and model usage.
FAQ
Is a seat-based credit pool the same as hybrid seat and usage pricing?
No. A pool is one way to deliver the included usage inside a hybrid plan. Hybrid pricing describes the whole structure of a seat fee plus metered charges, and the pool describes how the included credits are shared.
How many credits does each seat usually add?
Allotments vary by vendor, and a credit count means little without the credit's value. GitHub's Business seat costs $19 a month and adds 1,900 credits at $0.01 each, so the credits equal the seat fee. Runway's $69 seat adds 6,900 credits. Compare what a credit buys before comparing the counts.
Do pooled credits roll over?
It varies by vendor. Runway rolls unused team credits over for a month, and GitHub forfeits unused credits when the month ends. Set rollover per pool before launch, because every seat shares the carried balance.
Back to glossary
