更直接的近期产品信号来自 10 月 2 日公告：代码审查请求可通过 REST/GraphQL API 指定审查力度；默认审查自 9 月 28 日采用 Balanced，显式选择 Lite 的设置保留。默认选项可以改变团队的消耗路径，但公告本身没有证明每次审查更贵，或质量一定提高。来源：10 月 2 日公告。
GitHub 明确把一个 AI Credit 定义为 0.01 美元的用量计价单位。阿里云 Token Plan 的 Credits 则按模型、token、思考模式和工具调用等因素扣减，实际记录以控制台为准。两个名字相近的单位不能按数量直接比大小；某个套餐含有更多 Credits，不等于可以买到更多相同质量的工作。来源：GitHub 计费单位文档；来源：Token Plan Team 文档，9 月 28 日更新。
二、两种“共享”，对应两种不同的可用容量
Copilot Business 的月费为每席位 19 美元，含 1,900 AI Credits；Enterprise 为 39 美元，含 3,900。组织/企业的额度在计费实体范围内合池，未用额度不结转，并在每个日历月首日 00:00 UTC 重置。中途加席位等情况还要检查比例计费规则，不能拿完整月额度直接估算短周期。来源：组织与企业计费文档；来源：席位价格与计费周期。
Token Plan Team 的基础额度随席位分配，每个席位绑定个人。用尽后才消耗另购的共享用量包；一个包为 625,000 Credits、700 美元，有效期一个月，未用部分到期失效。这不是把所有成员的基础额度自动合池。控制台还可限制成员对共享包的使用；某成员能取用多少，也受包内剩余额度约束。来源：Team 套餐与扣减顺序；来源：团队管理文档，9 月 28 日更新。
Personal 文档另有两个值得核对的边界：9 月 22 日已移除周额度，按订阅周期管理月额度；其服务只允许兼容工具内的交互使用，不能用于自动脚本、应用后端或非交互批量调用。Team 同样限定交互工具用途。因而，套餐接口兼容某个 API 标准，不等于拿到了通用生产 API 的使用权；也不能为节省额度而共享个人密钥。来源：Personal 文档，9 月 28 日更新；来源：Team 使用政策。
这里采用阿里云国际站的新加坡 region 产品文档，不外推到中国大陆其他套餐；Personal 另明确为 Global 部署，region 名称不能证明所有推理都发生在新加坡。采购时至少要分别写下计量单位、可共享范围、到期时间、追加用量方式和停止条件。它们决定的是可交付容量的约束。把到期服务额度想成永久存放的现金余额，会忽略其中最重要的部分。
When AI Coding Moves to Credits, What Does a Team Actually Buy?
Copilot and Token Plan expose different sharing rules. An analysis of allowance mismatch, consumption tails, and budget interruption explains when governance may earn sustained payment.
Why can one team keep working at the end of the month while another, with the same ten AI coding seats, has unused allowance alongside a need to pay for more usage? Model capability and the advertised price may not explain the difference. A more basic question is who receives the allowance, who can draw on it, and which conditions stop a request.
My thesis is that credit billing adds an allocation problem to competition in AI coding. A seat buys access, a meter describes consumption, and budget rules determine which work can continue. A monthly price cannot stand in for all three. Products that reduce allowance mismatch and unexpected interruption may create value, but a usage dashboard alone does not establish a moat, revenue, or profit. Facts are current as of October 9, 2026. All mathematical examples below are original analysis, not customer data or measurements.
1. Establish the timeline and the unit first
GitHub announced that usage billing for Copilot was live on June 1, 2026. October therefore should not be described as the start of token billing. Its August 28 notice specified that the October 1 change to upfront seat payments covered existing Business/Enterprise customers paying by credit card or PayPal; the corresponding start for new customers was September 1. Payment timing alone establishes neither a price increase nor stronger demand. Source: June 1 announcement; source: August 28 payment notice.
A more direct recent product signal is the October 2 announcement: REST/GraphQL review requests can specify effort, and the default review has used Balanced since September 28 while explicit Lite settings remain intact. Defaults can change the consumption path of a team, but the announcement does not prove that every review costs more or achieves higher quality. Source: October 2 announcement.
GitHub defines one AI Credit as $0.01 of metered usage. Alibaba Cloud Token Plan deducts Credits based on factors including model, tokens, thinking mode, and tool calls, with actual usage recorded in its console. Similar names do not make the units comparable. A larger credit count does not establish greater capacity to perform the same work at the same quality. Source: GitHub billing-unit documentation; source: Token Plan Team documentation, updated September 28.
2. Two forms of sharing create different usable capacity
Copilot Business costs $19 per seat per month with 1,900 AI Credits; Enterprise costs $39 with 3,900. Organization/enterprise allowance is pooled at the billing-entity level. Unused allowance does not roll over and resets at 00:00 UTC on the first day of each calendar month. Mid-cycle seat additions also require checking proration rather than assigning a full monthly allowance to a short period. Source: organization and enterprise billing; source: seat prices and billing cycles.
Token Plan Team assigns base allowance to individual seats, each bound to a member. Only after it is exhausted does usage draw on a separately purchased shared pack: 625,000 Credits for $700, valid for one month, with unused credits expiring. Unused base allowance is not automatically pooled across members. Administrators can also limit an individual’s draw on the pack, subject to its remaining balance. Source: Team plans and deduction order; source: team management, updated September 28.
Personal documentation adds two boundaries: weekly allowance was removed on September 22, with monthly allowance managed by subscription cycle; use is limited to interactive activity in compatible tools, excluding automation scripts, application backends, and non-interactive batch calls. Team likewise limits use to interactive tools. Compatibility with an API standard is therefore not permission to operate a general production API workload, nor to save allowance by sharing personal credentials. Source: Personal documentation, updated September 28; source: Team usage policy.
The Alibaba Cloud sources here describe international-site products in the Singapore region, not every mainland-China plan. Personal also specifies Global deployment: a region name does not establish that all inference happens in Singapore. A purchase decision should specify the unit, sharing scope, expiry, replenishment mechanism, and stop conditions separately. These constrain deliverable capacity. Treating expiring service allowance as permanently deposited cash obscures the most consequential terms.
Original conceptual mechanism. The two-user example assumes a common cycle and unit price, fully shared allowance and no individual hard caps. Each user receives 100 units and uses 160 or 40: separate overage totals 60, versus zero under full pooling. This is synthetic arithmetic, not actual product prices, user data or any vendor’s team-seat rules. Check real pool scope, cycle, expiry, overage and stop conditions separately; an ordinary budget alert is not automatically a hard stop. AI tokens and Runner/Actions resources have separate meters, and task acceptance remains another check. Reducing allowance mismatch does not guarantee workflow completion.
Start with a deliberately simplified comparison: a common unit and period, fully transferable allowance, the same overage price with additional usage available, no individual hard caps, and no behavior change caused by sharing. Let \(S_i\) denote user \(i\)’s fixed seat fee, \(a_i\) allowance, \(u_i\) usage demand before allowance blocking, and \(p>0\) the monetary price per extra unit; define \((x)_+=\max(x,0)\). Separate and fully pooled bills are:
These are hypothetical contracts, not reproductions of a vendor’s full invoice. Taxes, discounts, proration, other execution resources, and directly attributed extra usage are excluded. Seat fees stay fixed and demand is fully served in this comparison without hard stops, so only the sharing rule changes. Separate each user’s overage from unused allowance:
The proof is short. Since \(\sum_i x_i=P-N\), separate metering charges \(P\) extra units and pooling charges \((P-N)_+\). When \(P\ge N\), the saving is \(N\); otherwise it is \(P\). Pooling cannot increase this simplified bill: it removes exactly the overage and unused allowance that can offset each other. It does not reduce the physical computation of any model call.
In synthetic allowance units, A and B each receive 100 and use 160 and 40. Separate metering produces 60 extra units while B leaves 60 unused. Full pooling has total allowance and use of 200, so overage is zero. These figures are not either vendor’s actual plans or user data. If both use 160, no unused allowance offsets demand and the pool still has 120 extra units. If an individual hard cap blocks A, the aggregate equation also cannot guarantee that A’s request proceeds.
A separately purchased shared pack requires a different model. Let \(H\) be available pack allowance. First sum the overage of individual seats as \(E\), then calculate the amount \(R\) that the pack cannot cover:
\[E=\sum_i(u_i-a_i)_+,\qquad R=(E-H)_+\]
Ignoring member limits and expiry order, this models individual base allowances followed by a shared supplementary pool. It is not Alibaba Cloud’s billing simulator, and \(R\) is not an automatically issued cash bill: it is an allowance shortfall for given demand. Hard stops censor actual usage, so deductions from served calls alone cannot recover all demand. In the example, \(E=60\); B’s unused base allowance does not automatically erase it. The official deduction order pauses service after all applicable quotas are exhausted until the next cycle or purchase of a shared pack. Decisions must also account for pack size and remaining validity: one cannot assume it is possible to buy exactly \(E\) units.
4. Equal monthly averages can hide different budget risks
Let \(U\) be random total consumption in a period and \(A\) fully pooled available allowance. The positive-part function is convex, giving:
\[\mathbb E[(U-A)_+]\ge(\mathbb E[U]-A)_+\]
Substituting average consumption can therefore understate expected overage. This does not imply that greater variance always costs more; that stronger claim needs an additional distributional relation, such as convex order, rather than variance alone. A synthetic distribution makes the distinction clear:
With allowance 200, constant use of 200 produces no overage. Use of 100 in half the periods and 300 in the other half has the same mean but expected overage of 50. No supplier or customer has been measured to follow this distribution here. It illustrates why release peaks, coordinated migrations, and incident repair can make members busy together. Adding more people to a pool need not diversify that demand. Inspect joint usage over tasks and periods, rather than seat count alone.
If more usage can be purchased immediately, tail risk mainly appears as variable spending. If approval, payment status, individual limits, or a hard budget prevent replenishment, it appears as interrupted work. Budget controls can exchange one risk for another: limiting the bill at the cost of delaying some tasks. For experimental-code review, data processing, or urgent fixes, a monthly average does not capture the cost of that delay.
5. Zero marginal cash payment does not erase opportunity cost
Consuming included allowance may require no immediate extra payment, yet takes capacity away from other work. To illustrate allocation, let \(d_j>0\) be expected usage for task \(j\) and \(v_j\) its net business value after accounting for quality, human effort, and risk. These are planning estimates, not measurements here or token prices. Let \(z_j\) represent the execution fraction and consider a continuous relaxation:
Real tasks are often indivisible; \(0\le z_j\le1\) is only an approximation that explains allocation. \(V(A)\) is monetary value. \(\lambda\) is a supergradient, or shadow price of capacity, measured in currency per allowance unit; where differentiable it equals \(V'(A)\). Here \(\partial V(A)\) denotes the superdifferential of the concave value function. The corresponding Lagrangian is:
For a given \(\lambda\) in the relaxed problem, comparing \(v_j\) with \(\lambda d_j\) compares task value with the cost of occupying scarce allowance. It helps explain how a low-value lengthy review can displace more time-sensitive work. It is not a ready-made scheduler: dependencies, uncertain quality, and indivisibility need further constraints. Necessary security or quality checks should not be deleted to conserve credits.
The shadow price is not supplier gross margin, and pooling alone cannot show that it exceeds the posted overage price. If additional units are available instantly and without limit at \(p\), with no further constraints, assigning a replaceable unit scarcity value above \(p\) generally has no justification. Greater urgency value requires a real restriction such as a hard spending ceiling, approval delay, or service limit. An expiring unit with insufficient demand may have no additional use. Invoice price, customer opportunity cost, and supplier cost are distinct quantities.
6. How do technical settings reach allowance and delivery?
A multi-step coding session may repeatedly read context, generate output, execute tools, and continue from their results. Consumption depends on the call path. More output, weaker cache reuse, retries, and deeper checks can change totals. A stronger model or deeper check may also reduce later rework, so a single-call price does not establish the direction of total task cost.
Copilot’s rate documentation distinguishes input, cached input, and output token categories. Code completions and next edit suggestions are not AI Credit metered. Code review automatically selects an undisclosed model and consumes both AI Credits and GitHub Actions minutes. Pricing it with an arbitrarily selected chat model is therefore unjustified. Two resource meters also do not mean two extra cash charges on every request: each has its own included allowance and billing conditions. Source: model rates and code-review documentation.
The Balanced default and API selection of effort provide a testable decision: for comparable PRs and unchanged acceptance standards, how do effort changes affect consumption, issues found, human review, and rework? This is a proposed comparison, not an experiment performed here. Stratify by PR size and difficulty, record failed attempts and final merge outcomes, and avoid selecting only successes or treating word count as review quality.
Stop rules also differ. Copilot user-level budgets cover included and extra usage and enforce a stop at exhaustion. Ordinary organization, enterprise, or cost-center budgets primarily govern overage, with Stop usage off by default. Cost centers can also control included usage. “A budget is configured” therefore does not establish that every request is subject to a hard stop. Source: budget scope and enforcement.
A useful product loop connects task records to actual deductions, execution resources, and applicable limits; suggests or selects review effort within permitted interactive use; identifies a feasible response before allowance runs out; and checks the outcome. Token Plan’s usage restrictions still apply. This analysis is not a recommendation to use its personal or team credentials for a background routing service.
7. Where might business value accrue, and what else explains the moves?
My inference is that a code-hosting platform’s proximity to PRs, team permissions, and merging makes it easier to connect appropriate task effort to billing. A model-subscription platform may instead cover different usage intensities through multiple models and tiered allowance. Teams may pay repeatedly for less time lost to budget blocking, reconciliation, and incorrect delivery, rather than simply more credits. This is a product-value hypothesis; announcements cannot establish renewals or revenue growth.
Records explaining task provenance, changed defaults, and deduction attribution are more actionable than one aggregate usage number. Yet if platforms provide these capabilities free, an independent budget-management product may struggle to earn a premium. If contract boundaries differ too much across tools, integration and maintenance may also absorb its savings. Clear permissions and reconcilable records are entry conditions, not an automatic moat.
Three alternatives matter. First, payment and usage changes may primarily address risk control, abuse, or collection timing, without improving model economics. Second, stronger models could reduce retries enough to weaken the allocation problem. Third, synchronized or nearly equal member demand leaves little overage and idle allowance to offset. Simple seat tiers and notifications may then suffice.
Subscription allowance is not proof of the supplier’s compute cost. Credits are a customer-facing contractual meter. Without actual revenue, inference resource costs, service costs, and discounts, they cannot establish gross margin. Plan sales, contract amounts, sustained adoption, and financial realization remain different evidence.
8. What would validate or overturn this thesis over 6–24 months?
These windows run from publication and propose observations without invented growth targets. Keep team scope, task difficulty, acceptance rules, and pricing version consistent. Record all eligible work, including tasks blocked by limits and still incomplete.
Window
What to record
Causal link tested
Within 6 months: by April 2027
Expired unused allowance, overage spending, budget blocks and delay; consumption tails and errors for comparable tasks
Do pooling or effort controls reduce mismatch and interruption without lowering quality by skipping checks?
6–12 months: by October 2027
Continued use by the same team, allowance and seat upgrades, renewals; reconciliation and unblock time before and after setting changes
Does improvement persist and create an identifiable reason to pay, beyond trials or promotions?
12–24 months: by October 2028
Where available, actual price premiums for budget governance and contribution profit including integration, support, and infrastructure
Can suppliers capture customer value, or do free platform features and maintenance erase the premium?
If task difficulty and quality are aligned and pooling or controls fail to reduce idle allowance and blocking; if delay, rework, and maintenance offset invoice savings; or if customers will not pay separately for governance, the strong claim that allocation becomes a monetizable product capability should weaken. Increased credit consumption alone would not validate it. The relevant outcome is reliable allocation of usable capacity to worthwhile work within explicit contractual boundaries.
