Vibe Coding Is Real: The Subscription Is a Balance, Not a Seat

Vibe coding is a real category now. Collins made it Word of the Year 2025, defining it as “the use of artificial intelligence prompted by natural language to write computer code”. What has not caught up is how the category gets priced. Search for what AI-assisted development costs and you get sticker prices — $20 a month, $10 a month — quoted as if they were seat licences. They are not. On 1 June 2026 GitHub moved Copilot to usage-based billing, and Cursor already published its included usage in dollars. On both platforms the subscription is a prepaid balance that drains at the model’s own API price. This post reads both meters, does the division, and shows what the published numbers put a floor under.

What changed on 1 June 2026

GitHub’s own documentation dates the change precisely. Its model-multiplier reference opens with the line “On June 1, 2026, GitHub moved to usage-based billing,” and then scopes itself: the multipliers on that page “apply only to Copilot Pro and Copilot Pro+ subscribers on an existing annual plan who remained on the legacy premium request-based billing model after June 1, 2026.”

Two things follow from that sentence. First, the premium-request model that most published pricing explainers describe is now labelled legacy by the vendor that invented it. Second, it did not disappear — annual subscribers were grandfathered, so both meters are live at the same time and a buyer can be on either one without knowing which.

The replacement unit is documented just as precisely. GitHub states that “Each token is priced based on the model used, and the total is converted into AI credits, where 1 AI credit = $0.01 USD.” That is a token meter with a currency wrapper. It is not a seat.

The subscription is a prepaid balance

Once you know to look for it, both vendors say this on their own pricing pages, in numbers.

GitHub’s plan page lists a price and a credit allowance side by side: Copilot Pro at $10 per user per month with “$15 monthly total credits for Pro”, Pro+ at $39 with “$70 monthly total credits for Pro+”, and Max at $100 with “$200 monthly total credits for Max”. The free tier is metered differently again — “2,000 completions per month”.

Cursor’s pricing documentation is even more explicit, because it denominates the allowance in dollars against a named pool. Pro is $20/mo and includes $20 of what Cursor calls Other Models, which it defines as “The pool for third-party models, charged at the model’s API price.” Pro Plus is $60/mo including $70. Ultra is $200/mo including $400. When the pool is empty, Cursor documents the overflow: “Add on-demand usage: Continue at the same API rates with pay-as-you-go billing.”

That last sentence is the tell. If exhausting the plan drops you to the same API rates you were already being charged at, then the plan was never a rate — it was a balance. The subscription bought quantity, not a discount on the meter, and the meter runs at list price on both sides of the boundary.

Both ladders top out at exactly 2.0x

There is one useful division to run on those published tables: included usage value divided by monthly price. Call it leverage — how many dollars of model usage a dollar of subscription buys. The inputs are the vendors’ own published figures; the arithmetic is ours.

Verdict: two vendors, publishing independently, land on the same ceiling — the top rung of each ladder returns exactly two dollars of model usage per dollar spent, and nothing on either published table goes above it. That is not a law of the market; it is what both tables say as of August 2026, and it takes a minute to re-check. Treat 2.0x as the best published rate available and price accordingly.

The bottom of the ladder is the more surprising half. Cursor Pro at $20 a month includes $20 of Other Models usage charged at the model’s API price — leverage of exactly 1.0. On the third-party model pool, the entry plan is not a discount on anything. It is a prepayment. Any ranking of these tools by sticker price therefore inverts the actual per-token value ordering: the cheapest plan is the worst rate, and the most expensive plan is the only one that halves your model cost.

One honesty boundary, because it is load-bearing. Cursor’s ladder arithmetic above covers the Other Models pool only. For its own models the page says “Cursor Models: Significantly more included usage for Cursor Grok 4.5 and Composer 2.5” and publishes no figure, so no leverage number can be computed for that pool and none is claimed here. The published comparison is third-party models against third-party models.

One published table spans 0.33 to 57

The legacy meter is worth reading even if you are not on it, because it is the only place either vendor has published a full per-model cost table in a single unit. Under premium-request billing each model carries a multiplier against a monthly allowance — Copilot Pro gets 300 premium requests a month, Pro+ gets 1,500.

The published multipliers as of August 2026 run from 0.33 at the bottom (Claude Haiku 4.5, GPT-4o, GPT-4o mini, GPT-5 mini, GPT-5.1-Codex-Mini) to 57 at the top (GPT-5.5). In between sit Claude Sonnet 4.5 at 6, Sonnet 4.6 at 9, Claude Opus 4.5 at 15, Opus 4.6 through 4.8 at 27, Gemini 3 Pro at 6, and GPT-5.1 at 3.

Divide the ends into each other and the same monthly allowance stretches by a factor of about 173 depending on nothing but model choice. Concretely, against a Copilot Pro allowance of 300: a 0.33-multiplier model gives roughly 909 interactions in a month, and GPT-5.5 at 57 gives 5. Five. GitHub documents the soft landing — “If you use all of your premium requests, you can still use Copilot with one of the included models for the rest of the month” — but the shape of the month is set on day one by a dropdown, not by how much work there was.

This is the number that makes fixed-price quoting for AI-assisted work hard, and it is the number no cost calculator in the category exposes. Task volume is not the dominant variable. Model routing is.

What actually draws down the meter

Not everything the editor does costs money, and the split is documented rather than inferred. GitHub states that “Chat, agent mode, code review, Copilot cloud agent, Copilot CLI, and Copilot Apps consume GitHub AI Credits”, while code completions and next-edit suggestions do not consume credits on paid plans.

That is a meaningful line. The feature most associated with the category — inline autocomplete as you type — is the free part. The features that actually replace engineering hours, agent mode and code review, are the metered part. A team that adopts AI coding tools and sees no spend is a team still using autocomplete.

Code review has its own published constant, and it is the sharpest number on the legacy table: a multiplier of 13. Each time Copilot reviews a pull request, the monthly allowance drops by 13. Against Copilot Pro’s 300 premium requests, that is 23 reviewed pull requests in a month before the allowance is gone, with nothing else running. For a team shipping daily, automated review is not a rounding error on the bill — it is most of the bill.

On team plans the balance is pooled

The organisation plans change the risk shape. GitHub documents that “Copilot Business and Copilot Enterprise include per-user GitHub AI Credits allowances that are pooled at the billing entity level.”

Per-user allowances that pool means the per-user number is an accounting convenience, not a cap. One engineer running an agent against a large repository on a high-multiplier model draws from the same balance as everyone else. There is no documented per-seat wall stopping them. The team’s exposure is the sum, and the distribution across seats is not something the plan constrains.

For anyone budgeting a project this is the difference between a fixed and a variable cost line. Ten seats at a published price looks fixed. Ten seats drawing on one pooled balance at a rate set by model choice is a variable cost with a floor at zero and a ceiling set by how the team works. Budget the pool, then instrument who draws on it — the same discipline that allocating a fixed concurrency pool across services demands in a NetSuite account, where adding services never adds capacity.

Team plans can also carry a rate the individual plans do not. Cursor documents that “On Teams and Enterprise plans, third-party model requests include a Cursor Token Rate of $0.25 per million tokens.” Read that alongside the definition of the third-party pool as “charged at the model’s API price” and the per-token cost of the same model is not identical across plan types. It is a small number and it is published, which is the point: it is checkable before it appears on an invoice, unlike the productivity assumption it is usually buried under.

The productivity multiplier is the one number nobody can read

Every claim that AI-assisted development is 3x or 5x faster traces back to self-report. The best-known attempt to measure it instead of asking about it is METR’s randomised controlled trial, and its result is worth stating exactly because it is so often stated loosely.

In the early-2025 study, 16 experienced open-source developers worked 246 real issues from their own repositories, randomly assigned to allow or disallow AI, primarily using Cursor Pro with Claude 3.5/3.7 Sonnet. METR reports that “the use of AI causes tasks to take 19% longer, with a confidence interval between +2% and +39%” — while the same developers estimated afterwards that AI had sped them up by 20%.

The follow-up matters more than the headline, and it cuts against easy readings in both directions. In its February 2026 update METR reports for the original developers “a speedup of -18% with a confidence interval between -38% and +9%”, and for newly recruited developers “-4%, with a confidence interval between -15% and +9%”. Both of those intervals span zero. Negative here means slower, so the point estimates are still negative — but neither result supports a directional claim at all, and METR says so plainly: because developers increasingly decline to work without AI, “our estimate reported above is a lower-bound on the true productivity effects of AI”, and their data is “only very weak evidence” about the size of any improvement.

Read that honestly and the conclusion is not “AI makes developers slower”. It is that the multiplier is not currently measurable to the precision anyone quotes it at, by the group that has tried hardest to measure it. Google’s DORA programme lands in compatible territory from a different method, reporting that “AI improves throughput, but often at the cost of stability if your foundation isn’t solid” — a trade-off, not a multiplier.

So one side of the cost equation is published to the cent and re-checkable in a minute, and the other side has a confidence interval wider than the claim. Quote the side you can read.

What this changes for integration work

For NetSuite, WooCommerce and Shopify integration work specifically, the metered-model finding has a second edge: the tasks that draw least from the meter are the tasks that were never the expensive part.

Scaffolding a REST client, writing a webhook receiver, generating test fixtures — public-API-shaped work, well represented in documentation, cheap in tokens and fast to verify. That is genuine compression and it is why delivery timelines have moved. The rest of the AI for commerce teams guide library works through where that compression holds and where it stops.

What does not compress is account-specific state, because it is not in any training corpus and often not in any public document. Whether a NetSuite account’s concurrency allocation leaves room for another integration is a per-account fact. Which field names a SuiteQL query must use depends on a permission-gated catalogue that an integration role may not even be able to open, as the data-source mismatch behind SuiteQL field names shows. Whether writing a location onto a sales order silently opts that line out of automatic assignment is documented behaviour a model will not infer from your prompt.

The economic consequence is specific: AI-assisted development compresses the part of an integration budget that was already the cheap part, and leaves the discovery, configuration and verification work untouched. A quote that falls by the full “3x” is a quote that has silently repriced the expensive half. This is the same structure as the per-step billing model behind no-code platforms, where the unit that bills is not the unit the buyer is thinking in.

A cost model you can actually quote

Three published inputs are enough to bound the tooling line of a project budget without inventing a productivity figure.

Verdict: build the estimate as balance ÷ draw rate, then treat everything above the balance as on-demand at list price — because that is exactly what both vendors document happens. Do not apply a speed multiplier on top; there is no published figure to apply.

The floor this puts under the category is the useful output. At the best published leverage on either ladder, a dollar of subscription buys two dollars of model usage, and past the balance it buys one. No plan on either published table takes the cost of the model below half its list price. Any quote that assumes AI tooling drives the cost of the model-executed work toward zero is assuming something neither vendor publishes.

What to ask before you sign

Work down this list with any supplier quoting AI-assisted delivery, or before adopting a tool internally.

• Confirm which meter you are on — usage-based credits, or grandfathered request-based billing on an annual plan.
• Divide included usage by monthly price for every plan tier and compare the leverage, not the sticker price.
• Ask which model handles agent work by default, and look up its multiplier or per-token price before assuming volume drives cost.
• Check whether automated code review is enabled and multiply its cost by your monthly pull-request count.
• Establish whether allowances pool across the team, and who is accountable for the pool rather than the seat.
• Price the overflow explicitly at list API rates — the documented behaviour once the balance is empty.
• Reject any timeline built on a stated productivity multiplier unless the supplier can name the measurement behind it.
• Separate the quote into public-API-shaped work and account-specific discovery, and expect only the first line to have moved.

If you want that split done against your own stack rather than in the abstract, that is the conversation we have on an integration scoping call — what compresses, what does not, and what the meter says either way. The same discipline applies to picking the model itself: as covered in the guide to comparing retirement clocks rather than benchmarks, the published operational facts about a model outlast its benchmark scores, and both belong in the decision.

Frequently asked questions

Related guides

• How to Choose a NetSuite Integration Partner (Without Burning $40k)
• Composable Commerce and NetSuite: Adding Services Does Not Add Concurrency
• TikTok Shop in 2026: Should WooCommerce and Shopify Merchants Actually Care?