Subscription or metered: what new model pricing means for AI budgets

AI models now reach engineering teams in two ways: metered API access, paid per token, and subscriptions with usage limits. Many organisations use both, often without a clear view of either. Meta's launch of Muse Wonder this week is a useful example, because the same model family is offered both ways, with different capabilities. This article compares the two pricing models and what each means for budgeting and control.

The context: one model, two ways to pay

Meta's developer announcement, published on 12 October, sets the API price for Muse Wonder at $4 per million input tokens and $20 per million output tokens, with cached input at $0.20 per million and a context window of one million tokens.

The most capable variant, Wonder Full, is available only by subscription, on the Power and Maximum Usage plans. The announcement describes the Maximum plan as offering 80 times the usage limits of the entry plan, with limits that reset every five hours and every week. The research post covers the model itself.

How the two models differ

Metered API access

• You pay for exactly what you use, per token.
• Cost is visible per request, so you can attribute it to a person, project or tool.
• Cost has no ceiling unless you set one.
• Cached input, at a twentieth of the input price here, rewards tools that keep prompts stable.

Subscriptions

• A fixed price per seat, which makes budgeting simple.
• Usage is capped by rolling limits, so heavy users hit a wall rather than a bill.
• Some capabilities, like Wonder Full, are only available this way.
• Usage is largely invisible to the organisation: the provider counts it against the plan.

Analysis: what to make of it

Subscription-only models change the comparison. When the strongest variant isn't on the API at all, a team can't simply route to it from existing tooling. The choice becomes which plan to buy, for whom.

Fixed price is not the same as controlled cost. Subscriptions cap spending per seat, but they make it hard to see who gets value from the tool. Seats for occasional users are paid in full.

Metered access is easier to govern. Per-request costs can be logged, attributed and limited. That makes metered access a better fit where an organisation wants budgets per person or project.

Limits shape behaviour. Five-hour and weekly resets mean heavy users plan around the limit, or buy the larger plan. For a team, that can make the true cost per active user higher than the plan price suggests.

What it means for engineering and security leaders

Most organisations will end up with a mix: subscriptions for people who use a tool heavily and benefit from features only available that way, and metered access for everyone else and for automated work. The important thing is to know which is which, and to review it.

Keep in mind that tools signed in with a subscription account send traffic straight to the provider. Any controls you put on API traffic, such as budgets or model rules, don't apply to it.

Practical takeaways for this week

• List which teams use AI coding tools through subscriptions and which through API keys.
• For subscriptions, compare seat count with active users each month and remove unused seats.
• For metered access, set budgets per person or project, with a warning before the limit.
• Check cached-input prices when comparing models: for coding agents they affect cost as much as list prices.
• Before buying a higher subscription tier for a team, check whether the same work could run on metered access at lower cost.

Where SpanDock fits

The SpanDock model proxy, in every plan, records the cost of each call. Per-person budgets and SpanDock Mind, which chooses a cheaper model when it is good enough, are on Standard and up; routing rules are on Premium and up. Only API-key traffic is routed: Claude Pro and Max sign-ins aren't used while the proxy is on.