Meta Muse Spark 1.2 pricing: the rate card that never changed

Meta Muse Spark 1.2 pricing, the full rate card

Here is every published number, checked against Meta's own pages on 17 August 2026. All prices are US dollars per million tokens.

That third row is the one most coverage misses. Meta's Model API page lists the previous checkpoint at exactly the same price, and the pricing doc confirms both checkpoints share standard pricing. There is no cheap-legacy tier to retreat to. If 1.2's behaviour costs you more, downgrading does not get the money back, which is a change from how Muse Spark 1.1 pricing read at launch when it was the only checkpoint on the card.

A few things here are worth saying plainly before I get into what the rate card hides.

There is no long-context premium. Meta says it outright on the pricing and rate limits page: you pay the same whether the window is nearly empty or nearly full. Several providers step the price up past a context threshold, and if you are stuffing a large stable prefix into every call, that difference compounds fast.

Prompt caching is automatic and free to turn on. Meta's prefix caching has "no flag or key to manage," there is no cache-write fee on the list card, and cached tokens are a discounted subset of input rather than a surcharge. You can ask for extended retention with prompt_cache_retention: "24h", though Meta calls that a hint rather than a guarantee.

And Meta's own scaffolding is free. The docs note that Meta injects a small amount of steering context into every prompt, and those tokens "are not billed and are excluded from the token counts reported in your usage." That is a small courtesy, but it is the sort of thing that quietly shows up on other invoices.

The rate card did not move. The bill went up 37%.

This is the part that makes Muse Spark 1.2 pricing strange to write about. Meta shipped a new model on 5 August, kept the price the same, and the cost of doing the same work rose by more than a third.

Artificial Analysis runs the same nine-evaluation suite against every frontier model, so the version-over-version comparison is as close to controlled as public data gets. It publishes two separate cost measures, and they are worth keeping apart because they do not move together.

The weighted cost per task went from $0.2923 on 1.1 to $0.3992 on 1.2, a rise of 36.6%. The total to run the whole suite once went from $547.32 to $639.27, a rise of $91.96 or 16.8%. The first is the number that predicts what a given piece of work costs you, and it is the one I lead with. The second is the number that tells you where the money went, and I break it down in the next section.

I want to be careful about what the 37% is and is not. It is a benchmark workload, not your workload. But it is the same benchmark on both versions, priced off the same rate card, which makes it a clean read on one question: how much more does this model spend on a unit of work? Over a third more, for free, without anyone announcing a price change.

This is the failure mode I keep watching teams walk into, and it has nothing to do with Meta specifically. A prospect once sat on a call with me working out his own numbers, landed on roughly $30,000 a month for a company scaling toward 150,000 tickets, and the whole confusion came from the gap between the unit he was counting and the unit he was billed on. Another was quoted a 3,000-interaction monthly allowance while running about 500 tickets a day at four exchanges each, which burns through the allowance in a day and a half. Neither person was bad at arithmetic. In both cases the multiplier between "the thing I count" and "the thing you bill" was invisible until the invoice arrived. Muse Spark's rate card has exactly that shape.

Where the extra $92 actually went

Almost everyone, including an earlier version of my own Muse Spark 1.2 breakdown, assumed the cost jump was extra thinking. Reasoning models get more expensive by reasoning harder, and 1.2 was pitched as the smarter checkpoint. It is a reasonable guess.

It is also wrong, and the published cost breakdown says so.

Reasoning is the one line that got cheaper. 1.2 spent $20.71 less on hidden thinking tokens than 1.1 did. The increase came from everywhere else, and cache read is the single biggest mover at nearly double.

The per-task token counts explain why. Answer tokens per task went from 7,237 to 12,874, a 78% jump. Reasoning tokens per task rose only 16%, from 15,158 to 17,557. Meanwhile the whole index ran on roughly the same total output budget either way, 95M tokens against 94M.

So the practical translation is this: Muse Spark 1.2 does not think harder than 1.1, it writes longer. If your workload runs AI agents across multiple turns, more verbose answers feed straight back into the next call's context, which is exactly the mechanism that doubled the cache read line. Verbosity compounds in a way that raw thinking does not.

That is a knob you can actually turn. Ask for shorter answers, cap output tokens, and trim the parts of your prompt chain that carry previous responses forward. It is ordinary LLM optimization, the same discipline that keeps Anthropic API pricing predictable, and the same reason the OpenAI API surprises people who never look at output length.

The contributor tier is 12.5x cheaper and 30x tighter

The two-price structure is the thing everyone quotes about Muse Spark, and they usually quote it wrong, because the discount is different on input and output. Input drops 12.5x. Output drops 21.25x. Cached input drops 75x.

Meta's framing is unusually direct. The docs describe contributor as "heavily discounted token pricing in exchange for permission" to train future models on your prompts and completions, aimed at "prototyping, testing integrations, and scaling experiments where training on your data is acceptable." And tier is not an account setting you toggle. In Meta's words, "Tier is a model attribute". You opt out of training by calling a different model ID.

The Hacker News thread on launch day was almost entirely about whether that trade is fair, and the split was sharp.

"What are you talking about? This is one of the most honest offers ever made by a corporation. "We'll use your data, and we'll compensate you for it." Where is the problem?"

p-e-w, Hacker News

Not everyone agreed the standard tier's promise is worth the premium. When one commenter argued Meta trains on everything regardless of invoice, Simon Willison pushed back with a sarcastic account of what that accusation actually implies, which is that a company would print two data policies and knowingly violate one. The contractual difference is the product.

But the argument nobody was having is the one that matters most for a production budget. Here are the published limits:

The contributor tier costs 12.5x less per input token and allows 30x fewer requests per minute. The token ceiling only drops 25%, so the throttling is uneven on purpose. Meta squeezed the request path specifically. Contributor is priced for volume and gated for prototyping, which is a coherent product decision and a nasty surprise if you find it after building on it.

One X user hit it directly and put it in five words: the requests per minute "seem to be severely limited". That is the only concrete rate-limit report I could find on any verifiable platform, which tells you how few people have pushed contributor past a hobby workload.

Two more mechanics worth knowing before you plan around these numbers. Limits are pooled per team, not per API key, so adding keys does not add headroom. And background responses carry a separate cap of 600 submissions per minute per team, on top of RPM and TPM.

Work out which tier you can actually use

Price is the second question. Throughput is the first, because no discount helps if the ceiling is below your floor. Set your numbers here and the answer falls out.

The meters sitting beside the token meter

Token rates are the headline, and they are not the whole invoice. Four other things bill or gate you.

Web search grounding is metered separately at $2.50 per 1,000 search queries, charged on top of the tokens for the request. If your agent grounds every answer, that is a second meter running in parallel with the first, and it is the one most likely to be missing from a spreadsheet built off the model page.

There is no batch API and no batch discount. The docs navigation lists no batch surface at all. The only async path is background responses, which is a submission mode with its own rate cap rather than a discounted tier. If you have been planning around the batch discounts other providers publish, that saving does not exist here.

There is no fine-tuning offering for Muse Spark. The models doc lists three inference model IDs and nothing else. Fine-tuning on Meta's developer site is Llama-weights territory, which is a different product with a different cost structure.

There is no hard spend cap, and that is the complaint that actually stopped people signing up. Two separate Hacker News users said the same thing on the same day.

"Unfortunately I find this too high risk, I entered my credit card, but can not set a limit. The best I can do is get an email alert. I feel like I am one oopsie away from getting a 100 dollar bill."

sams99, Hacker News

That is a billing-UX gap rather than a pricing one, and it is fixable in an afternoon, but it is worth knowing that on a model whose entire pitch is cheap tokens, the thing blocking conversion is the absence of a ceiling.

How Muse Spark 1.2 pricing compares

Sticker rates flatter and mislead in both directions, so the column that matters is measured cost per task on a fixed benchmark. Here is Muse Spark against the models it actually competes with, using Artificial Analysis's leaderboard figures.

The buy-side reading is straightforward, and it is good news for Meta. Muse Spark 1.2 is the cheapest model on that board scoring above 56. Everything smarter costs at least 2.8x more per task. Opus 5 is 5.9x. The closest like-for-like is GPT-5.6 Terra, which scores essentially level and costs $0.51 against Muse Spark's $0.40, so Meta is 22% cheaper at the same intelligence.

One correction worth flagging, because it trips up cross-post comparisons. Artificial Analysis blends at 7:2:1 cache hit to input to output on these pages, not the older 3:1 input-to-output ratio that circulates widely. The math checks: (0.7 × $0.15) + (0.2 × $1.25) + (0.1 × $4.25) = $0.78. If you see a blended figure quoted against a 3:1 assumption, it is not comparable to this table.

And GPT-5.6 Luna is the row that breaks any simple story about cheap meaning weak: $0.05 per task, eight times cheaper than Muse Spark, at 52.3 on the index. My GPT-5.6 Luna writeup goes into what it gives up to get there.

For the rows immediately above Muse Spark, Kimi K3 pricing has the full rate card. The open-weights option at the cheap end of the board sits in my DeepSeek V4 Flash review.

What the rate card leaves out

A pricing post should be as clear about the gaps as the numbers, because the gaps are where a budget goes wrong.

Speed and latency are unpublished for 1.2. Artificial Analysis has no output-speed, time-to-first-token, or end-to-end response measurement for this checkpoint, and the leaderboard shows a dash in all three columns. Muse Spark 1.1 does have them, at 225.9 tokens per second and 1.38 seconds to first token, but those belong to the old checkpoint and should not be attributed to 1.2. If response time is part of your cost case, you are waiting on data that does not exist yet.

There is no zero-data-retention program. I checked the full docs navigation and could not find a data-retention, privacy, or ZDR page of any kind, self-serve or sales-gated. The closest control is a response-storage flag: store: false on the Responses API stops GET /v1/responses/{id} from returning your response, and Meta is explicit that it "does not disable caching." Tier is the only data lever there is.

The API is still public preview. Meta's product page now leads with "Public preview. Now available with expanded global access," which is better than the geo-restricted framing at launch, but preview is preview. Pricing and limits on a preview surface are subject to change in a way a general-availability rate card is not.

And a smaller one that matters if you are testing the cheap tier: access can be pulled. One developer posted a 403 mid-work, with no prior warning, reading "Your access has been restricted due to repeated policy violations". Contributor is priced like a promotion and gated like one.

What one developer actually paid

Everything above is list prices and benchmark runs. The most useful datapoint I found is someone reporting their real session cost, which is rarer than it should be.

"even with this subsidized pricing, less than an hour of usage resulted in slightly over $1 of cost (fig. 1). if i do this all month it'll be more expensive than the highest Anthropic/OpenAI subscription"

Kun Chen, X

That is on the contributor tier, the cheap one, the one people were calling absurdly underpriced on launch day. An hour of agentic coding work came to over a dollar at $0.10 per million input tokens.

The same point turned up from a practitioner on LinkedIn within a day of launch, framed as a warning rather than a receipt.

"But token price isn't the full picture. What matters is cost per task. Different models burn different amounts of tokens to solve the same problem. We don't have that data yet for Muse Spark 1.2. Cheap tokens mean nothing if the model takes twice as many shots to get there."

Rob Gonda, LinkedIn

He wrote that before the cost-per-task data existed. The data arrived and proved him right, in a direction nobody predicted: 1.2 burns more tokens than its predecessor by answering longer, while its thinking got slightly cheaper.

Why tokens are the wrong unit for a support queue

I have spent three years at eesel watching AI work live support queues, and in that whole time I have never seen a team successfully forecast a support bill from a token rate card. The arithmetic is easy enough. The unit just does not survive contact with a real ticket.

One resolved ticket is not one prompt. It is retrieval across a help centre and a macro library, a ticket classification pass, a drafting pass, usually a retry when the first draft is wrong, sometimes a tool call to look up an order, and then the whole conversation carried forward as context when the customer replies. Every one of those steps multiplies. A cheap per-token rate multiplied by an unknown number of steps is not a budget, it is a hope. Which model you pick matters far less than that structure, as I argued when picking the best model for support tickets.

And you can watch this go wrong in real numbers. Support teams routinely underestimate by a factor, and the ones that get burned worst are the highest-volume ones, precisely because the multiplier compounds. That is the same structural trap as the Muse Spark 1.2 story: the rate stayed still and the consumption moved. My AI customer service cost breakdown has the fuller picture of what teams actually end up paying.

This is why eesel bills per resolved ticket rather than per token or per seat, and it is the first thing I say to anyone who arrives holding a token rate card. A resolution is the unit the business already counts, it maps to something a support lead can defend in a budget meeting, and it does not silently reprice itself when a model starts writing longer answers. The same argument sits behind my cost per resolution framing.

It is also why the meter belongs on the ticketing system rather than the model, and why the honest comparison for a support lead is against a person rather than an API. I worked that one through in AI versus human agent cost.

The other half is knowing the number before you commit to it. I simulate every rollout against a customer's own historical tickets first, which gives you a resolution rate and a cost against real traffic rather than a benchmark. That habit came from watching confident-sounding bots quietly give wrong answers in production, which is its own discipline covered in preventing AI hallucinations, and it happens to solve the forecasting problem too. There is more on that in the build versus buy guide, which is the decision most teams reading a rate card are actually making.

Try eesel

If you are pricing Muse Spark 1.2 because you are planning to build support automation on a raw model API, the token rate is the least interesting number in the project. eesel sits on your helpdesk, reads your existing knowledge base and past tickets, and starts resolving front-line conversations in minutes, billed per resolved ticket so the invoice tracks work done rather than tokens spent.

The part worth trying first is the simulation. Point it at your ticket history, and before anything goes near a customer you get a resolution rate and a projected cost on your own traffic, which is the forecast a token rate card structurally cannot give you.

One engineering lead who went through exactly this decision put the reasoning plainly. Anonymised, they run a Bitcoin-ATM hardware company with a 300-plus article Confluence and Telegram knowledge base:

"We could try to write our own LLM application but we didn't want to invest our time into that. We wanted something that we would not have to maintain."

Free to try, and you can see the simulated numbers before you decide anything.

The verdict on Muse Spark 1.2 pricing

At $1.25 in and $4.25 out, Muse Spark 1.2 is the best value on the frontier board above 56 on the intelligence index, and Meta deserves credit for not repricing on the upgrade, for charging nothing extra on long context, and for making caching automatic instead of a config exercise.

The thing to plan around is that the model got 37% more expensive to run without the price changing, because it answers 78% longer than 1.1 did. Cap your output tokens, watch what your prompt chain carries forward, and check your peak requests per minute before you assume the contributor tier is available to you at all.

And if the workload is a support queue, price it in resolutions. That is the only unit that has ever survived a real invoice.