GitHub Copilot Joins Atlassian and HubSpot in Repricing AI: Three Vendors, Three Different Metric Bets, One Structural Cause

TL;DR. On April 27, GitHub announced that all Copilot plans transition to usage-based AI Credits on June 1, 2026. That makes GitHub the third major AI vendor in 30 days to reprice. Atlassian Rovo’s forced bundled-consumption hybrid (originally bundled with Cloud subscriptions in 2025) became publicly documented through licensing-advisory coverage in February. HubSpot Breeze moved to per-resolved conversation on April 14. GitHub Copilot is moving to token-based metering on June 1. The three vendors made different metric choices triggered by the same cost pressure underneath: agentic AI workflows broke the cost structure of the original per-seat or flat-rate pricing model, and the vendors are passing the volatility through. Eleven days before GitHub’s announcement, we published the six structural flaws of credit-based AI pricing. GitHub’s June 1 move operationalizes flaws one, four, five, and six in a single rollout. Cost-driven repricing is a vendor-side symptom, not a customer benefit. The architectural alternative — building the pricing on a value metric the customer can verify, instead of a cost meter the vendor can adjust — is the piece every one of these announcements skipped.

The cluster matters because it forecloses an easier argument. When Atlassian moved Rovo into Cloud subscriptions with credit metering in February, the trade-press read was “AI add-on attach rates are bad, vendors are bundling.” When HubSpot moved Breeze to per-resolved conversation on April 14, the read was “AI agent pricing is shifting to outcomes.” Each story had a tidy single-vendor narrative that captured part of the picture and missed the broader pattern. With GitHub Copilot moving to token-based AI Credits on June 1, the pattern crosses the threshold from anecdote to category shift, and the structural cause underneath the three different metric bets is what pricing teams need to see clearly.

What GitHub announced (and what it costs)

AI Credits replace premium request units

GitHub’s announcement is structurally simple and operationally significant. Every Copilot plan will now include a monthly allotment of AI Credits, with usage calculated by token consumption (input, output, and cached tokens) at the published API rates for each model. The current premium-request-unit metering is going away. Pricing on the existing plans stays nominally unchanged: Pro at $10 per month with $10 in monthly AI Credits, Pro+ at $39 per month with $39 in credits, Business at $19 per user per month with $19 in credits, and Enterprise at $39 per user per month with $39 in credits. Business and Enterprise customers get promotional uplifts in the first quarter ($30 of credits for Business, $70 for Enterprise) that disappear afterward.

The dollar-for-dollar credit equivalence is the line trade-press coverage has anchored on, and it deserves careful reading. A $10 plan with $10 in credits is not the same product as a $10 plan with unmetered chat at the previous rate. The customer’s monthly bill is held constant, but the value the customer receives inside that bill is now a function of token consumption against vendor-set per-token rates. GitHub’s own framing acknowledges the previous mismatch: “a quick chat question and a multi-hour autonomous coding session can cost the user the same amount.” Replacing that with metered consumption shifts the consumption volatility from the vendor to the buyer.

What’s free, what’s metered, and the double-meter on code reviews

Code completions and Next Edit suggestions remain free for every plan and do not consume AI Credits. That is the load-bearing customer-promise piece of the announcement and it preserves the day-one developer experience for the most-used Copilot features. Everything beyond that — Copilot Chat, Copilot CLI, the Copilot cloud agent, Copilot Spaces, Spark, third-party coding agents, and Copilot code review — consumes credits at token rates that vary by model.

Copilot code review carries an extra structural twist worth naming separately. Starting June 1, every code review run on a private repository will be billed in two ways simultaneously: as AI Credits under the new usage-based model, and as GitHub Actions minutes drawn from the customer’s existing plan entitlement, with any usage beyond included minutes billed at standard GitHub Actions overage rates. Admins on Teams and Enterprise plans can use Actions budgets to cap spending, but the cap operates on the overage layer; the entitlement-draw underneath is unavoidable. GitHub Actions minutes is not a new metric for GitHub overall — Actions has billed in minutes for years with established per-minute rates, customer billing relationships, and procurement contracts. What is new is applying the Actions-minutes meter to Copilot code review for the first time, simultaneously with introducing AI Credits as a second meter on the same workflow. The vendor borrows one metric from Actions, layers a new metric on top, and points both at the same workflow. Public repository code reviews are not affected by the double-meter — Actions minutes remain free for public repos — which sets up an interesting cost-management dynamic for organizations that have shifted internal projects between public and private visibility.

The strategic intent behind the double-meter is worth naming. Long-running code reviews on larger repositories consume meaningfully more compute than short reviews on small ones, and the AI Credits meter alone — priced in tokens — captures the model-inference cost without fully capturing the infrastructure cost of running the workflow itself. Actions minutes was already in place as the metric for that infrastructure cost; pointing it at Copilot code review lets the vendor capture additional value that scales with repository size and review duration. The intent is rational from the vendor’s side. The execution is harder for the buyer. Standard Linux Actions rates run $0.008 per minute with established markup, while AI Credit rates track model API rates directly. The meters use different units, entitlements, and overage curves. Estimating monthly bills requires forecasting two consumption profiles against separate allowances. Procurement teams cannot estimate costs without a pilot period. Cap negotiations on both meters are the predictable response, which is likely to dampen the value-capture intent the double-meter was designed to enable. The same procurement friction that constrained similar moves at Atlassian Rovo applies here, with one additional buyer lever: the customer can negotiate caps on the AI Credits side and caps on the Actions-minutes side, and the vendor has to land somewhere defensible on both.

Multi-meter pricing isn’t new. On-premise software used per-CPU, per-user, per-session, and per-GB meters simultaneously. Buyers taught vendors that this creates estimation headaches. SaaS simplified to per-user-per-month for predictable scaling. GitHub’s credit-plus-minutes structure regresses toward on-premise multi-meter pricing. The compute economics of AI do not fit clean per-user pricing anymore, so vendors are bringing back the multi-axis approach. The on-premise problem returns with one twist: consumption is repo-specific. Organizations with multiple private repos face one estimation problem per repo, plus portfolio aggregation. SaaS-era procurement teams lack the multi-meter playbook and face the highest exposure.

The estimation problem also reshapes the vendor’s go-to-market motion. When procurement can’t forecast multi-axis bills, deals become pilots instead of enterprise contracts. Pilots carry their own fragility. Surprise overages in month one or two can spook accounts and kill pilot conversions. Vendors moving to multi-meter pricing must prepare for this commercial-motion shift. The motion looks like pilot-led entry, transparent in-flight estimation tooling, careful overage management during the trial window, and a renewal pathway built around the actual usage data the pilot produces. This capability is necessary but not sufficient for multi-meter pricing. Pilot data hasn’t accumulated, field execution varies, and surprise bills trigger reactions regardless of vendor playbooks. Vendors whose commercial orgs are still oriented around closing annual commitments at signature face higher structural risk than vendors that have built the pilot motion, but the differential is in the size of the exposure, not in any guaranteed outcome. Pilots can get killed before they convert under both setups; the accounts migrate to competitors with pricing structures that are easier to estimate up front when the friction is high enough. Atlassian, HubSpot, and GitHub are now in a category where the prior commercial-org playbook (close on annual commits at signature) does not match the buyer-side estimation reality (need a pilot to model usage), and that mismatch is its own form of go-to-market debt that has to be paid down before the new pricing produces enterprise revenue at scale. That is a double-meter — the same piece of work is metered through two distinct consumption surfaces, each with its own rate, allowance, and overage logic. We documented the same hybrid pattern at Atlassian Rovo and HubSpot Breeze last week, where standard Rovo credits and Rovo Dev credits operate as two separate currencies inside one product. GitHub’s version is sharper because the second meter (GitHub Actions minutes) was already billed independently. Code review now sits at the intersection of both meters, and procurement teams that have not budgeted for the compound bill will find out at the first invoice cycle.

The annual-subscriber forced migration

Annual subscribers on Pro or Pro+ get the most asymmetric treatment in the rollout. Their existing premium-request-based pricing stays in place until their annual term expires, which sounds protective on the surface. Two execution decisions reshape that protection. On June 1, model multipliers for annual subscribers increase, raising the effective consumption rate against their existing premium-request allotment. The increase is not uniform across the model catalog. Third-party calculations against GitHub’s published models and pricing reference tables put the steepest multiplier change at roughly 27x for premium model classes (Claude Opus and equivalent), with smaller increases at the lower end. When the annual plan does expire, the customer is moved to Copilot Free rather than auto-renewed under the original terms. The combination forces a decision: switch to monthly before June 1 and absorb the new credit metering on the new structure, or hold the annual plan through expiration with a higher effective burn rate that depends entirely on which models the customer’s workflows route to, then accept a downgrade to Free.

Increasing multipliers and demoting customers at renewal forces migration. This mirrors Atlassian’s forced-bundled-consumption pattern where credit allowances are included regardless of usage. Both moves transfer consumption volatility from the vendor to the buyer through a structure the buyer cannot opt out of without giving up the product.

The retirement of annual plans is itself a licensing-model decision worth naming separately. Term length sits inside the rights-to-use dimension of the license agreement — the same Section 3 territory where the value metric and seat definition live. Eliminating annual commitments is a defensive vendor move. GitHub’s own cost structure has been changing weekly. They no longer want to commit to a 12-month price when their underlying compute economics may shift twice in that window. So they push the term-length variability down to the customer. The customer’s previous mechanism to lock in a price through a 12-month term is now gone, and the residual mechanism (multi-year procurement negotiations) sits at the Enterprise edition where deal sizes justify the legal work. For Pro and Pro+ buyers, the term-length protection is structurally eliminated. Monthly is the only on-ramp, and monthly means the vendor’s per-token rates can change as fast as their cost economics demand.

Sign-up freeze on Pro, Pro+, and Student plans

The fourth element of the announcement gets less attention in trade coverage and tells more of the structural story than any of the others. Earlier in April, GitHub paused new sign-ups for Copilot Pro, Pro+, and Student plans, tightened usage limits on existing accounts, and adjusted model availability. A vendor that pauses new customer acquisition on its individual plans before the new pricing structure is even live is a vendor admitting the unit economics under the current pricing have broken. GitHub has been public about the driver: agentic Copilot workflows, parallel coding sessions, and more capable models have caused a significant change in computational demand. Industry coverage of internal estimates suggests the weekly cost of running Copilot has roughly doubled since the start of 2026.

A sign-up freeze followed by a pricing reset is the cleanest possible signal that the new pricing is cost-driven, not customer-aligned. It is the move a vendor makes when the existing model is losing money on every new customer and there is not enough time to redesign the architecture before the next earnings cycle.

What 30 days of repricing reveals

How the three vendors’ bets diverge

The temptation across trade press, pricing newsletters, and most secondary commentary is to lump the three announcements together as “AI vendors moving away from flat fees.” The framing is true and analytically empty. Each of the three vendors changed the value metric the price attaches to, and each picked a different metric. The differences are not stylistic. They reveal three different bets about where consumption volatility should sit and which side of the contract should carry the unpredictability.

Each vendor moved at multiple architectural layers, with different depth at each one. Atlassian moved packaging substantively (the add-on-to-hybrid bundle) plus licensing-model (credits as the metric). HubSpot moved licensing-model plus pricing-model substantively, with smaller packaging adjustments alongside (28-day free trial added on Customer and Prospecting Agents, intra-family differentiation across Breeze agents on different pricing models). GitHub moved all three substantively. At the licensing-model layer, the metric shifted from premium request units to token-based AI Credits, the term-length structure contracted by retiring annual plans entirely (monthly only), and allocation moved to organization-level pooling for Business and Enterprise. At the packaging layer, Pro/Pro+/Student sign-ups froze indefinitely and model availability was redrawn across plans. At the pricing-model layer, per-token rates and multipliers went up. The headline reads as a billing change. Whether the three-decision move was a coordinated redesign or a reactive scramble against shifting cost economics is not visible from outside the vendor. What is visible is the structural result: the move shifts cost variability from the vendor to the buyer at every layer of the architecture, regardless of how the decision-making process inside GitHub actually unfolded. The licensing-model decision moved at every vendor. That is not a coincidence; it is the whole point.

Same root cause: agentic AI broke the cost structure

The structural cause is the same in every case. The original pricing models — per-seat for Atlassian’s Cloud subscriptions, per-conversation for HubSpot’s Breeze, premium-request-units for GitHub Copilot — were designed for a workload profile that does not match how customers actually use AI in 2026. Single-shot questions and bounded interactions are not the dominant workload anymore. Long-running agentic sessions, parallelized model calls, deep-research workflows, and cross-repository iterations are. Each of these patterns consumes substantially more vendor-side compute per unit of customer-facing value than the original pricing model assumed.

Industry consensus through 2025 was that AI costs would steadily decline as foundation model providers scaled inference capacity and competed on per-token rates. The consensus had a specific number behind it: GPT-3.5-equivalent inference fell from roughly $20 per million tokens in late 2022 to under $0.10 by late 2024, cited across pricing newsletters and vendor analyses as proof AI economics were on a steady downward path. The number is correct for the model class it measures and load-bearing for an argument it cannot carry. Per-token prices for frontier models have come down too, but the workloads driving these repricings are not bottlenecked on per-token price. Agentic loops, reasoning-token consumption, and parallelized model calls multiply tokens-per-task by orders of magnitude, and total cost per customer task is rising even as headline per-token prices fall. We have argued the opposite publicly since April 2024, when we responded to the Forbes investigation into Stability AI’s cost collapse — the company that projected $153 million in 2023 costs against $11 million in revenue and was caught underpaying AWS bills — by warning that companies absorbing AI costs blindly would get crushed once their customer mix shifted toward heavy users. The argument extended a year later in our Forbes Tech Council piece on GenAI costs, which made the contrarian point directly: AI costs would not necessarily plummet the way the prevailing consensus assumed. The piece named the specific mechanism that would keep them from falling: “with the advent of AI agents, algorithms can send requests back to an LLM, consuming even more tokens behind the scenes, where users aren’t able to fully understand their consumption.” Eleven months later, GitHub cited essentially that mechanism — agentic workflows running long, parallelized sessions consuming more resources than the original plan could support — as the rationale for repricing. The thesis hardened in AI Software Pricing: “a pricing metric that assumes costs only go in one direction is a metric that will break.” By Value Metric Decision: “a pricing metric designed around ‘costs only go down’ will break — possibly sooner than most companies expect.” The 30-day pattern is what that two-year-old prediction looks like in operation. The vendors built pricing structures around the consensus that costs would fall. The cost economics moved the other way for the workloads that actually matter, and the original structures broke first.

Vendors in this position have a wide menu of paths to consider. They can absorb the cost differential and protect customer experience at the expense of margin. They can degrade the product (cap usage, downgrade models, throttle agentic features) and protect margin at the expense of customer value. They can negotiate harder with model providers on capacity reservations or volume commitments, invest in their own inference-cost optimization (caching, model distillation, routing logic), restructure the product to reduce token-heavy workflows, differentiate by absorbing variability where competitors are pushing it down to buyers, or run combinations of the above. Repricing — changing the metric, with the direction the variability moves built into the metric choice — is one path through that option set. Atlassian, HubSpot, and GitHub landed on repricing in different forms within thirty days of each other. The structural cause underneath their decisions is shared (cost economics shifted faster than the original pricing model could absorb), but the choice to reprice is one decision among several that were available, and the vendors that take different paths in the next ninety days will produce a more complete picture of what was actually on the table.

What the cluster does and doesn’t show

The cluster does not show that any of these metrics is structurally correct. None of the three vendors has converged on a value metric the customer can fully verify against the value they derive. But the three moves are not equally questionable, and the layer each vendor occupies on the stack determines how defensible its decision is. The layer-distance argument matters because the further a vendor sits from the underlying compute, the less appropriate it is to peg the customer’s bill to that compute.

GitHub Copilot’s chat-and-completions surface sits closest to the consumption wire. Copilot is a developer-facing product, but its cost structure on those features is dominated by direct token consumption against frontier models the way Anthropic and OpenAI charge their own customers for raw API access. When GitHub moves to per-token AI Credits for that surface, the argument for the move is that they are close enough to the model layer that pricing in tokens is honest rather than opaque: the variability the customer is now exposed to is the variability GitHub itself faces from the model providers underneath. Tokens-as-currency is the narrow edge case in our credit-based pricing analysis where the structure has been the incumbent answer, because the buyer is technical and expects the abstraction. The original analysis was careful to note that tokens are the incumbent answer, not necessarily the right one. Foundation model providers are already moving toward subscription editions, capacity reservations, and capability-based differentiation as the underlying economics shift, which means the consumption-wire defensibility itself is not stable. We are not endorsing token pricing as a durable answer at any layer. We are observing that, at GitHub’s position on the stack today, the structure is more defensible than it would be one layer up — and that defensibility is conditional on the foundation model pricing landscape, which is itself in motion. The structural flaws of credit-based pricing apply at reduced force on the consumption-wire features today; whether that reduction holds in twelve to eighteen months depends on decisions being made at the model layer that GitHub does not control.

The framing is harder to defend across the rest of Copilot’s portfolio. Copilot code review runs as an automated workflow inside GitHub Actions, analyzing pull request diffs against project context — the customer is buying integrated PR-review automation, not raw model access. The Copilot cloud agent navigates repositories autonomously to execute multi-step tasks, which is application-layer workflow integration. Copilot Spaces is a knowledge-organization layer that overlaps directly with the kind of work Atlassian Rovo is doing inside Confluence and Jira. Each of these capabilities sits closer to the application layer than to the consumption wire, and each is now being metered with the same token-based pricing as the chat features. The uniform pricing decision across a heterogeneous portfolio is its own structural mismatch. At the consumption-wire features, token pricing is defensible. At the application-layer features, token pricing imports the same opacity Atlassian’s customers are pushing back on, with a double-meter compounding the issue specifically on code reviews run against private repositories. GitHub did not make one pricing decision. It made one pricing decision applied to a portfolio that spans both ends of the layer stack.

Atlassian Rovo is further from the wire. Rovo is a productivity capability embedded inside Jira, Confluence, and the Teamwork Collection. The customer is buying workflow integration, not raw model access. The value derivation is operational (tickets summarized, documents drafted, agents executing tasks across the project graph), not token-shaped. A credit currency layered on top of that workflow is an additional abstraction, sitting one level removed from the value the customer can verify. Without deep visibility into how Atlassian’s customer groups actually derive value from Rovo across different work patterns, we cannot prescribe the optimal value metric. That diagnostic work is exactly what application-layer vendors have to invest in to land somewhere defensible. We can say the optimal metric is not credits, because credits are not how the customer experiences the value, and we can say with confidence that the structural flaws apply at full force in this position on the stack.

HubSpot Breeze made the most ambitious metric move of the three. A resolved customer-service conversation has surface-level appeal: it is observable on a per-event basis and shapes more cleanly to the buyer’s mental model of what the agent is doing than credits or tokens do. That surface appeal is what makes per-resolution attractive in slide decks and trade-press coverage. The harder questions are field-execution questions, and they are not yet answered. The first is definitional: what counts as “resolved,” and who decides? Customer-marked? Auto-detected? Time-bounded? If a ticket is reopened within seven days, does the resolution void? A second category lives in field defense — when the customer pushes back at renewal on edge cases (agent-handled resolutions that escalated to a human, partial resolutions, false-positive resolutions, conversations resolved by the customer’s own action), how does the salesperson hold the price without giving the negotiation away? Procurement compounds both. Enterprise buyers will negotiate per-resolution rate caps, volume floors, and definition clauses that HubSpot has not yet had a renewal cycle to harden against. The convergence-rate concern documented earlier sits underneath everything: as the resolution rate climbs, the unit price has to drop in lockstep, and that price drop has to survive whatever definition disputes have accumulated in the meantime.

Per-resolution is not unambiguously closer to value-aligned. It removes the friction-filled issues credits introduce and replaces them with a different set of friction-filled issues that have not yet survived a renewal cycle in the field. We will know whether HubSpot’s bet pays off when the first wave of annual contracts comes up for renewal and the definition fights start.

The cluster shows three vendors making three different metric-redesign moves under the same cost pressure. Each move is rational from the vendor’s local position on the layer stack. Each move also exposes the vendor to a distinct flavor of renewal-cycle field defense: Atlassian on credit conversion rates, HubSpot on resolution definitions, GitHub on token-rate competitiveness with the model providers underneath. The vendor that wins the field-defense war is not the one whose metric looks cleanest in the announcement post. It is the one whose metric and field execution harden together over multiple renewal cycles. These three vendors give us three different bets on which combination will hold up. None of them has been tested yet.

How GitHub’s move operationalizes the credit-based pricing critique

We published six structural flaws of credit-based AI pricing on April 16, eleven days before GitHub’s announcement. Even with the layer-distance moderation noted above, four of those flaws operationalize in the GitHub move in ways that are observable from the announcement itself. The flaws are real at the consumption wire; the difference is that the customer’s ability to verify the vendor’s pricing against the underlying model API is higher than it would be one layer up in the stack.

Flaw one in public — exposed cost structure

The first structural flaw of credit-based pricing is that it exposes the vendor’s cost structure and invites margin compression as costs move. GitHub’s announcement is the cleanest public demonstration of the flaw to date. The vendor’s framing is explicit: weekly Copilot operating costs have risen sharply, agentic workflows are the driver, and the new pricing aligns customer charges with actual usage. Translated structurally: customer pricing is now a passthrough of vendor compute cost, and the customer’s bill will move with whatever happens to the underlying model and infrastructure economics. When token rates for the most capable models change at the API layer — and they have moved both up and down at every major foundation model provider in the last twelve months — the GitHub Copilot customer’s bill moves with them. The customer has no insulation from infrastructure-layer pricing volatility.

Flaw four in public — vendor-controlled exchange rate

The fourth structural flaw is that credit-based pricing creates an exchange-rate risk between credits and underlying consumption that the vendor controls unilaterally and procurement teams correctly identify as opacity. GitHub’s announcement provides the textbook example: model multipliers are increasing on June 1 for annual subscribers. A multiplier change is the conversion rate moving. The customer’s contractual relationship is denominated in dollars. The customer’s actual entitlement is denominated in credits. The relationship between the two is set by GitHub’s published per-token rates and per-model multipliers, both of which the vendor adjusts at their discretion. Procurement teams that have negotiated annual commitments based on the previous multiplier structure are being told their effective unit cost is rising by an amount the vendor sets. That is not a bug in the rollout. That is the lever the entire credit-based structure is designed around.

Flaw five in public — prepaid cash masking

The fifth structural flaw is that prepaid credit allotments mask the underlying economic shift. GitHub’s $10-equals-$10 framing is the cleanest version we have seen. The headline reads as “no price change,” because the dollar amount on the invoice is unchanged. The structural reality is that the $10 is now denominated in a unit (AI Credits at per-token rates) that did not exist a month ago, and the customer’s effective consumption against that $10 depends entirely on which models they use and which features they engage. The customer’s old $10 bought a defined entitlement (premium request units with model-class fallback). The customer’s new $10 buys an undefined entitlement that the vendor will value-adjust quarterly through model rate changes and multiplier resets. The cash flow is identical. The economic exposure is fundamentally different.

Flaw six in public — revenue ceiling at infrastructure margins

The sixth structural flaw is that credit-based pricing caps revenue at infrastructure margins because the metric is a passthrough of compute cost rather than a representation of customer value. GitHub Copilot was, until April 27, an application-layer product priced on a value-aligned metric (a developer’s productivity inside an editor) that allowed Microsoft to capture margin above the cost of the underlying model API. The June 1 move repegs the customer price to the vendor’s cost of model usage. The application-layer margin headroom that came from charging $10 for a developer license while paying API rates underneath is gone. GitHub Copilot’s margin curve from June 1 forward will be a function of how efficiently Microsoft can run model inference against published API rates. That is an infrastructure-layer business model. It is the structural ceiling we documented two weeks ago, and it is now operationalizing on a calendar.

What pricing teams should learn from these repricings

Token-based pricing is not the answer; it inherits all six structural flaws

The pull of token-based pricing is real and the logic is straightforward. Customer charges align with vendor cost. Heavy users pay more. Light users pay less. Margin volatility is bounded. Each of those statements is true at the rollout. None of them survives the next eighteen months because token-based pricing inherits every structural flaw of credit-based pricing in a more concentrated form.

The concentration shows up as a layer-of-abstraction problem. Credits are a synthetic currency designed for the user-facing wallet layer; tokens are the atomic units the model itself processes, normally seen only by developers consuming the API directly. Pricing in tokens pushes the metering boundary one layer down the hierarchy — exposing the buyer to a unit that was not designed for finance-team visibility. Atlassian’s credits are a designed unit that masks underlying compute behind a stable per-action mapping the buyer can read. GitHub branded its product “AI Credits” with dollar-denominated balances ($10 of credits equals $10), but the meter underneath is tokens at per-model rates with vendor-adjusted multipliers. The wallet-layer label is real; the abstraction it implies is thin, because the customer’s effective unit cost moves with both per-token rates and multiplier changes, both vendor-set and both adjustable. The action-to-token conversion that determines a buyer’s bill is an artifact of model internals, varying with context length, model choice, reasoning depth, and the number of agentic-loop iterations the model decides to run. The buyer can read the rate card and still not know what a single Copilot interaction costs.

The cost structure exposure is not just visible; it is the entire pricing structure. The renewal-table negotiation is not whether the vendor adjusts the credit conversion rate but whether the vendor’s published per-token rates are still competitive with what foundation model providers will offer the customer directly. That is a renegotiation against a moving target the customer can verify independently.

Pricing-consultancy commentary has been particularly strong on the credit-based-as-standard argument. The usual framing: vibe coding apps and AI-agent companies have settled on credit-based metering as the dominant pattern, tokens and credits are becoming the standard approach to pricing AI solutions, and the recommended move is to study what the early movers are doing to develop credit-based pricing models for the rest of the application layer. The argument is empirically true on the popularity dimension and structurally hollow on the durability dimension. “Most companies are doing this” is not the same statement as “this works at scale.” The early-mover cohort has not yet been through a renewal cycle where enterprise buyers had time to develop systematic procurement responses to credit-based contracts. The “emerging standard” claim is being made without the receipt the late-mover would actually want: the ratio of credit-cap clauses negotiated at renewal versus credit-cap clauses absorbed without negotiation. We do not know that ratio yet, and the publicly documented Atlassian Rovo case (a 6,000-seat customer renegotiating $180,000 of projected overage exposure) is the directional evidence that early movers are about to find out.

Cost-driven repricing is a vendor symptom, not a customer benefit

When secondary coverage — trade press, pricing newsletters, and analyst commentary alike — frames a pricing change as “aligning customer charges with usage” or “reflecting actual consumption,” the framing always favors the vendor. The customer-side reality is that consumption volatility moved from the vendor to the buyer. The vendor’s margin is now bounded by their own cost-management efficiency. The customer’s bill is now bounded by their own usage-management discipline. The shift is structurally clean for the vendor and structurally hostile to enterprise procurement teams that need predictable, budgetable cost lines. Pricing teams reading these announcements should look for who carries the volatility after the change, not who is described as benefiting from “alignment.” The customer who was promised alignment is the customer carrying the volatility.

The architectural alternative — and why GitHub could not have taken it

The architectural alternative we have been writing about for the last sixty days is to identify the value metric the customer derives, build packaging that maps to how customer groups actually use the product, and set price points that produce a rational net price across the customer base — what our pricing model and B2B pricing strategy work covers in depth. For Copilot, that metric exists. The customer-recognizable value is developer productivity, measured in pull requests merged, time-to-completion on tasks, defect rates, or any of several proxies. The packaging exists too — distinct customer groups derive value differently (an indie developer building a side project, a startup engineering team, a regulated-industry enterprise, a monorepo platform team).

The architectural alternative would have been to keep the per-seat license, redefine what a seat entitles, and price the seat against a productivity metric that customer groups can verify. GitHub did not take that path because it does not solve the immediate cost problem. The infrastructure spend doubled since January. A productivity-metric pricing redesign takes nine to eighteen months to ship cleanly. The new pricing had to ship before the next earnings cycle. The vendor optimized for time-to-deployment over architectural correctness, and the resulting structure exposes every customer to the cost dynamics of the underlying model API. That is the trade-off worth naming as customers evaluate the change.

What we will be watching next

Whether GitHub’s per-token rates produce predictable bills

The first thing to watch is whether the published per-token rates produce bills enterprises can budget against. The historical pattern in token-based pricing is that monthly bills become unpredictable enough that procurement teams build internal usage-throttle layers (the “internal usage police” pattern we documented in the credit-based-pricing analysis), which reduces adoption and turns the new pricing into a self-suppression dynamic. If GitHub’s billing dashboards expose enough granularity for engineering managers to predict usage by repository, by team, and by feature, the bills become budgetable. If they do not, the next twelve months will produce a wave of capped-credit renewals (the same pattern we have seen at Atlassian Rovo) and a developer-side push toward direct model API access.

Whether the annual-subscriber migration triggers a competitive shift

The forced-migration treatment of annual subscribers — multipliers up on June 1, annual plans retired entirely, demotion to Free at expiration — is the most aggressive part of the rollout. Enterprise procurement teams that signed annual commitments under the previous structure are now negotiating with a vendor that has unilaterally repriced their effective entitlement. Anthropic’s Claude Code (a CLI-driven coding tool that bills directly at Anthropic’s published API token rates) and Google’s Gemini Code Assist are positioning at exactly this customer group, and the structural pressure is sharper than trade press, pricing newsletters, and most secondary commentary suggests. GitHub’s per-token AI Credit rates now have to remain competitive against what developers can get from Anthropic or Google directly. That is a renegotiation against a moving target the customer can verify independently in real time. If the migration produces a meaningful loss of enterprise mindshare, expect Microsoft to soften the multiplier increase or restore some form of annual protection. The first six weeks of June are the verification window.

Whether a fourth vendor joins within 90 days

Atlassian, HubSpot, and GitHub all repriced in 30 days. The cost structures driving each repricing apply to every AI-tool vendor in the application layer. We expect a fourth and fifth vendor to announce comparable repricings within 90 days. The vendors with the most exposure are the ones with the largest agentic-workflow deployments and the smallest margin headroom. Watch the customer service AI category (Salesforce, Zendesk, Freshworks), the developer tooling category (Cursor, Codeium, Tabnine), and the productivity-AI category (Microsoft 365 Copilot, Google Workspace Gemini, Notion AI). Whichever vendors announce next will tell us whether this is a category-wide shift or a 30-day cluster.

Whether any vendor differentiates by pulling variability back from the buyer

The structural pattern across the three repricings is the trigger and the act of changing the metric, not the direction the variability moved. Atlassian and GitHub pushed consumption variability to the buyer because credits and tokens are consumption metrics that scale with attempts. HubSpot absorbed it, carrying execution risk on every unresolved conversation. HubSpot is the closest of the three to a buyer-side predictability position, but per-resolution still leaves the buyer exposed to volume of attempts, definition disputes at renewal, and the per-resolution unit price as a renegotiation lever. A vendor that moved further than HubSpot, offering a metric that gives the buyer hard predictability on the bill itself, would be addressing the procurement-side pain that every enterprise buying AI features is currently absorbing. The metric does not yet exist in any validated form. Whatever it would look like (capacity reservations with vendor-borne overage absorption, outcome-based contracts with monthly bill ceilings, productivity metrics with fixed rates per customer-recognizable result, or something none of us have imagined yet), the structural opening is currently unclaimed. We are not predicting that any specific vendor will take this path, and we are not naming a specific metric as the answer. We are observing that the opportunity is open in a moment when no current AI vendor offers buyer-side bill predictability, and predictability is a value proposition that procurement teams are demonstrably willing to pay for.

The structural lesson from the cluster is not that flat-fee AI pricing is dead. The lesson is that vendors who priced AI features without identifying a value metric the customer could verify, anchored in the broader SaaS pricing models architecture, ended up exposed to the cost dynamics of the underlying model layer. The repricings being announced now are a vendor-side correction. They are not a customer-side improvement. The pricing teams reading these announcements and trying to figure out what to do with their own AI features should ignore the metric-bucket question and focus on the architectural one: which value metric does your customer actually derive value from, and is the price attached to that metric or to a passthrough of your vendor cost? If you are sitting on an AI pricing decision and the conversation in your organization is collapsing into “credits versus tokens versus per-resolution,” see our approach or book a working session.

FAQs