Start with the order of operations, because that is what produces the confusing block messages. A request first checks the most specific user-level budget that applies; if the user is over it, the request dies there and nothing else can top it up [8]. If the shared credit pool still has credits, the request is served at no extra cost [9]. Once the pool is empty, usage becomes metered at $0.01 per AI credit [9]. Then cost center, organization and enterprise budgets are consulted in that order, and whichever applies either pays or hands the decision to the stop-usage setting [10].
That is where the default bites. Three of the six controls sit at cost center, organization and enterprise scope, and they enforce nothing unless "Stop usage when budget limit is reached" is enabled, which it is not out of the box [3][5]. The other three are user-level, and those always hard stop with no option to continue [4]. So the same $20 written into two different fields produces two different systems: one refuses the request, the other sends email while the charge accrues [3].
The arithmetic is the second half of the problem. Budgets only govern metered products, and Copilot seats are license-based, so a budget on them alerts and nothing more [2][6]. GitHub's own documentation says an enterprise budget is not a total monthly budget, and its worked example is 400 Copilot Business licenses at $19 per month, or $7,600 in license fees; add a $5,000 enterprise budget and the ceiling is $12,600 [7]. Check the multiplication yourself: 400 times 19 is 7,600, and 7,600 plus 5,000 is 12,600 [11]. The license fees are 60.3 percent of that ceiling [12]. A forecast built on the $5,000 field has already missed most of the bill.
Two more mechanics matter before you touch anything. Metered usage requires the AI credit paid usage policy to be enabled at enterprise or organization level; with it off, users are simply blocked when the pool empties, no matter how generous the budgets look [13]. And budgets do not stack. Whichever has the least capacity remaining blocks first, so the most specific user-level budget quietly sets the real ceiling regardless of what the enterprise allows [14][8].
The delegation model is the part I would call good design. An organization owner can set a budget for their own organization, but it can only restrict usage further below whatever an enterprise admin already set, never raise the ceiling [15]. That is the correct direction for a control that costs money to get wrong. The cost center user-level budget is the same instinct applied to scale: one per-user amount set once, applying to every current and future member, which is how engineering gets $20 per user and marketing $5 without creating thousands of individual records [4].
None of this is hard to configure. Creating a spending limit takes about two minutes [1]. The gap between configuring it and knowing what it stops is where the surprise invoices live [1], and closing that gap costs one checkbox plus threshold alerts at 75, 90 and 100 percent [5]. If you want a hard ceiling on metered spend today, the user-level controls are the only ones that give you one without a setting change, and any budget set to $0 blocks immediately [4].
