Meta Muse Code pricing: what a free coding agent really costs

What Muse Code actually charges you for

Muse Code is Meta AI's terminal AI coding tool, shipped in beta on 5 August 2026 alongside the Muse Spark 1.2 model. You install it with one line, curl -fsSL https://dev.meta.ai/install.sh | bash, and run it by typing muse in a project directory.

Here is the thing that trips people up on the Muse Code product page: the section headed "Models and pricing" contains no price for Muse Code. It contains a five-column token table for Muse Spark. I searched the full rendered body text of that page for the words free, trial, credit, subscription, seat, plan, spend, limit and cap. Zero hits on all nine. The entire commercial story of Meta's coding agent is a token table.

So the real rate card is the Model API rate card. Every model Meta sells, as published on pricing and rate limits:

Three models, two prices, and no cheap-legacy escape hatch: 1.1 costs exactly what 1.2 costs. Rate limits apply per team rather than per key, so extra keys buy you nothing. Background submissions carry a third cap of 600 per minute on top. If you want the model-side reading of those same numbers, including what changed between 1.1 and 1.2, that is what the Muse Spark 1.2 pricing breakdown covers.

Then the extras, or rather the lack of them. There is one genuine add-on meter, web search grounding at $2.50 per 1,000 queries, charged on top of tokens and flat regardless of how much context each search pulls. Beyond that, Meta has less pricing machinery than most vendors, and mostly in your favour:

• No long-context premium. Meta says it flatly: "There is no long-context premium: you pay the same rate whether your context window is mostly empty or almost full." Several rivals step the price up past a context threshold. Meta does not.
• No cache-write fee. Caching is automatic, cached tokens are a subset of input tokens rather than a separate line, and the optional "24h" retention hint costs nothing extra.
• Meta's own scaffolding is free. From the docs: "Meta injects a small amount of steering context into every prompt (a system prompt and related scaffolding); those injected tokens are not billed."
• No batch API and no batch discount. background: true responses exist but are not discounted.
• No fine-tuning, at any price. There is no fine-tuning product in the docs at all.
• No volume or committed-use discount. The pricing page's words are "no minimums or upfront commitment," which cuts both ways.

That is an unusually clean rate card. Everything expensive about Muse Code happens somewhere else.

The three defaults that set your bill

Every metered agent has three or four settings that decide the size of the invoice. What makes Muse Code worth writing about is that all three of its cost dials ship at their expensive position, and none of them is on the pricing page.

Dial one is the model. Meta's configuration docs say it plainly: "The default model is muse-spark-1.2." That is the $1.25 and $4.25 tier, not the ten-cent one.

Here is where it gets muddy, and I want to be precise because the gap between the two answers is 12.5x on input. The launch blog says the opposite: Muse Code "starts on a contributor tier," and it gives you the switch command, /model to muse-spark-1.2-contributor. The configuration page never mentions the contributor tier at all. The word appears zero times on it, and the one --model example Meta prints is the redundant muse --model muse-spark-1.2. Meta's own two pages disagree about which price you are paying. The blog also calls the command /model where the docs call it /models. Until Meta reconciles them, run /models on your first session and read what it says rather than trusting either page.

Dial two is reasoning effort. Muse Spark is a reasoning model, and Meta is upfront about what that means for the bill: "It thinks before it answers; those tokens are billed as output." Output is the $4.25 meter. The documented effort levels are none, minimal, low, medium, high, xhigh and ultra, and the default is xhigh, sixth of seven. none is not supported in Muse Code at all.

ultra deserves a warning label, and to Meta's credit it has one. It is not a deeper-thinking setting; the client clamps the model request to xhigh anyway. What ultra actually does, in Meta's words, is change "how aggressively Muse Code delegates to multi-agent workflows on the client, which can raise token usage." Reach for it expecting better answers and you will get a bigger bill instead.

Dial three is the spend cap, and it does not exist. More on that below, because it is the part that decides whether any of this is safe to put on a company card.

Your conversation is the thing you are buying

The single most useful sentence in Meta's billing docs is a definition most people skim past. Charges are based on token usage, and every request consumes "Input tokens: your prompt, system instructions, and conversation history."

Conversation history. In a chat window that is a footnote. In an agent that reads files, runs tests, reads the output, and tries again, it is the entire cost model. Turn twelve is billed for turns one through eleven.

Two things soften this and one thing sharpens it.

Softening it: prompt caching is automatic, and the repeated prefix bills at $0.15 rather than $1.25, an 88% discount on the part of your context that has not changed. Meta also keeps memory recall cheap by design. At session start the agent injects an index of your memory files, "their paths, not their contents, up to 48 files," and reads individual files only when it wants them. That is a real cost control and it is nice to see one.

Sharpening it: code tokenizes worse than prose, which Meta also says out loud. "A token is roughly 3 to 4 characters of English text. Non-English text and code often use more tokens per word, so equivalent requests can cost more." A coding agent is the worst case for a per-token meter, and it is the product Meta is selling.

You can see the floor of all this in one measurement. A developer typed a single word into Muse Code on launch day and watched the meter:

"Meta AI released muse code today. so i tested out. just said hi as the first prompt, and it consumed 20.4k tokens (and $0.02)."

Abhinandan V., LinkedIn

Two cents is nothing. 20,400 tokens for two characters is the number to hold onto, because that is the size of the base your session starts compounding from before you have asked for anything.

Multi-agent by default is a billing decision

Meta markets Muse Code's headline feature as "Multi-agent by default." On the product page that reads as a capability. On the meter it is a multiplier, and the docs are specific enough to do the arithmetic.

Start with the fan-out. From Meta's extending docs: "The runtime runs several children at once. The default cap scales with the machine: roughly core count minus two, clamped between 2 and 16." Your laptop's core count is a pricing input. On a 16-core machine that is up to 14 write-capable children running as separate billed streams, each with its own context, each carrying its own copy of the task. Children run one level deep, so at least it cannot recurse.

You do not opt into this. The launch blog is emphatic: tasks are "fanned out automatically... Your working copy is never touched and you don't set any of this up - Muse Code does it all automatically." That is a real engineering achievement and I like the design. It is also the thing multiplying your token spend while you watch one progress bar.

Then the observers, which I had not seen covered anywhere and which surprised me most. Muse Code runs a team of background agents watching memory recall, skill recall, goal tracking and verification. Meta's own sentence: "Three of the four observers run by default, and each makes its own model calls, so they add token usage in addition to the main session." Three extra billed conversations you never typed into, on by default, switched off in settings.json under runtime_capabilities.

And there is a footgun in the interrupt. Pressing Esc "stops the turn only. It does not stop background terminals or subagents." The universal panic reflex when an agent goes off the rails does not stop the meter on the parallel streams. That one is worth knowing before you need it, and it is a sharper version of the same problem that makes subagent orchestration hard to budget for in every harness, this one included. If you want the comparison, Claude Code subagents and multi-agent systems work through the same trade-off from the other side.

Work out your own number

Meta publishes no cost calculator, and every worked example I could write would be wrong for your repository. So here is the arithmetic in a box you can put your own numbers into. It uses the published rate card and models the one thing that actually drives the bill: your conversation being re-billed on every turn, at the cached rate, once per parallel stream.

The percentage in that note is the point of the whole exercise. On any session long enough to be useful, most of what you pay Meta is for re-reading a conversation you already paid for. Shortening sessions is a bigger lever than switching models, which is not where most people look first. It is the same reason context window size turns into a budget question rather than a capability one once an agent is doing real work.

How that compares to buying a plan

The reason a metered agent feels strange is that almost nothing else in this category is sold that way. I priced up every serious agentic coding CLI against Meta's, and the pattern is consistent enough to be the finding: five of the six ship a flat plan and give you a hard spend cap on the metered route too. Muse Code has neither.

Read down the spend-cap column. Cursor's docs are the clearest on what a cap actually means in practice: "When a limit is reached, AI features stop for that user until the next billing cycle." Grok Build ships with a $0 invoiced billing limit by default, so requests get rejected once prepaid credit runs out. Even the metered API routes have ceilings, because vendors learned years ago that developers will not put a card down without one.

There is a second thing those vendors do that Meta does not, and it is the more useful one. They publish what you should expect to spend. Anthropic's own documentation puts Claude Code at "$13 per developer per active day and $150-250 per developer per month." Cursor publishes bands too, roughly $60 to $100 a month for daily agent users and $200-plus for power users. Meta publishes a rate card and wishes you luck. Nowhere in its docs is there a sentence telling you what a normal month looks like.

So on price per token Muse Spark is competitive, and the contributor tier is aggressive against anything except the cheapest Chinese labs. On price predictability, Muse Code is the only option here that cannot answer "what is the most this can cost me this month". If you have already sat through a procurement conversation about Claude pricing, Codex pricing, Windsurf pricing or GitHub Copilot pricing, you know what that certainty is worth to a finance team, and it is usually more than the token delta.

Buying tokens directly is still a real strategy, just a different one. It is the same decision as reaching for the OpenAI API or the Anthropic API instead of a packaged product: better unit economics, and you inherit the forecasting problem. The three big model APIs comparison covers where each lands next to Claude Opus 4.6 pricing and GPT 5.3 Codex pricing. If you are shopping purely on cheap tokens, Qwen pricing, Kimi K2.5 pricing, Mistral AI pricing and DeepSeek V3.2 all belong on the same spreadsheet. Hosting weights elsewhere is the third route, which is what Together AI pricing and Groq pricing exist for.

One credit worth giving Meta, since I have spent most of this post on the gap: the rate card itself is honest. Two prices, both printed, with the data terms stated in plain English under each one. No credit system standing between you and the number, which is more than you can say for the AI credits and Flex Credits schemes that have spread across the rest of the industry. The problem is not that Meta hid the price. It is that Meta priced the tokens and left the volume entirely up to the agent.

One community observation is worth repeating here because it sets the bar Meta is actually being judged against, and it is not Anthropic:

"This is a nice release and a solid improvement over Spark 1.1. It compares favorably with Grok 4.5. Not SOTA, but solid releases. I think they need to really get this more competitive with Deepseek V4 Flash / Luna pricing to move the needle."

mchusma, Hacker News

The thing Muse Code does not sell you: a ceiling

I have read every billing page Meta publishes for this product and there is no spend cap, no budget limit, no hard stop, and no usage alert in any of them. What there is, is a payment threshold, and it is easy to misread as a ceiling because it is a number attached to your account with a dollar sign on it.

Meta's words: "Whenever your current balance reaches your payment threshold amount, your payment method is charged for that amount. As you make successful payments, your payment threshold may be raised until your account reaches a final threshold amount."

Read that carefully. It is a trigger for charging your card, and it rises as you demonstrate you can pay. It is a credit limit that works in the vendor's favour. Anything left over gets charged on the first of the month regardless. The word "plans" appears in the billing page heading and in the nav description, and is never followed by an actual plan.

Developers noticed on day one, and the objection is not theoretical:

"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

I want to sit with that comment, because I recognise it from a completely different market. I build integrations at eesel and I sit in on enough sales calls to know that the request for a ceiling is the most ordinary thing a buyer asks for. One team I sat in with, anonymised here as a budget-conscious B2B hardware support group running around 250 tickets a month, had watched a previous vendor's price more than double and came in asking specifically for contractual price locks, floating annual prepayment as a way to get one. Nobody frames that as paranoia. It is just what happens once you have been surprised.

And the surprise usually lands after the product has already proved itself, which is the part that stings. Another team, a US fashion brand on Gorgias, ran twelve test chats against eesel's agent. The agent did well. Then they opened the billing page and immediately filed two cancellation requests, one of which read simply:

"PLEASE CANCEL MY subscription"

That was about eesel's own pricing page, not a competitor's, and it taught me something I have designed around ever since: the product working is not what decides the purchase, the bill is. A metered agent with no cap saves that conversation for the end of the month.

The closest thing Meta gives you to a brake is a step limit rather than a dollar limit: --max-model-steps <n> on headless runs, which Meta describes as being there "so a stuck task can't loop indefinitely." Useful in CI. It does nothing for an interactive session, which is where most of the spending happens.

Where the cheap tier gets expensive

The contributor tier is the most interesting pricing decision in the whole launch, and the most discussed. $0.10 in and $0.20 out is 12.5x and 21x cheaper than standard, and the label Meta puts under it on the product page is a single sentence: "Used to improve our products." The standard tier's label is "Not used to improve our products." I have rarely seen a vendor state the trade this bluntly, and a lot of developers respected it for that:

"I actually really like that pricing strategy. It's very transparent"

jjcm, Hacker News

"The fact that Facebook has so much experience taking advantage of people's private data is one of the reasons I believe them when they say they won't be doing it when you pay them for that service."

Simon Willison, Hacker News

The pushback split two ways. Some argued the discount undervalues the data, since the real cost of choosing it is the $4.05 per million output tokens you are forgoing. Others pointed out you can buy the same price without the data grab:

"FYI: there are providers of deepseek that offer the same or lower pricing and zero retention policies."

dghlsakjg, Hacker News

Beyond the ethics, there are four concrete reasons the cheap tier may cost you more than the sticker implies, and they are the ones I would want on a whiteboard before committing a team to it.

It is 30x more rate-limited on requests. 100 requests per minute against the standard tier's 3,000, while tokens per minute only drops 25%, from 4M to 3M. Meta throttled the request path specifically. An agent that fires many small tool calls in parallel, which is exactly what Muse Code's fan-out does, hits a request ceiling long before a token ceiling. A queued agent is a slow agent, and slow agents get rerun.

Access can be withdrawn without notice. One developer reported losing it mid-project:

"Pointing out for others: without warning I was restricted from using the contributor model because of "policy violations". I was working on Kaggle research and some Apple Security work at the time. They really need to make cyber a first priority product feature."

johnmlussier, Hacker News

The terms on free credits moved after the fact. Meta handed out $20 credits at the Muse Spark 1.1 launch, and the data-use language attached to them changed later:

"If you got the $20 in free credits from Meta for signing up when muse-spark-1.1 was release, please note that there's now small print stating "While using free credits your content may be used for product improvement" which was not present at muse-spark-1.1 launch when the credits were given out."

bradfa, Hacker News

Zero data retention is sales-gated and unpriced. From the launch blog: "We're also beginning to accept requests for zero data retention. Contact Meta sales to request this." Beginning, and by request. If a security review is going to block you, it will block you here, and there is no self-serve setting and no published price for the fix.

That last one is where cost and privacy stop being separate questions. A terminal agent reads your repository and ships it to a vendor's API as billable input, so every token that leaves your machine is simultaneously a line item and a disclosure. I hear the same question constantly on the support side of this business. A technical evaluator at a semiconductor hardware company would not move forward until he was satisfied the AI answered only from his org's approved knowledge rather than reaching out to a general model, and asked directly whether that behaviour could be turned off. He was not asking about pricing. He was asking the same question. The overlap is exactly why Claude Code security reads like a cost document in places.

For what the model itself is worth at that price, the fairest hands-on read in the launch thread was also the most useful:

"Muse code is rough around the edges. But combined with almost free model (muse spark contributor) it's actually pretty good. I think it's on the same level as grok build."

alexeiz, Hacker News

What I would actually do

Concretely, in the order I would do it, if I were putting Muse Code on a real project this week.

1. Run /models on your first session and confirm which tier you are on. Meta's docs and launch blog disagree, and the difference is 12.5x. Do not infer it, read it.
2. Drop --reasoning-effort to medium and see if you notice. Reasoning bills as output at $4.25. xhigh is the default, not a recommendation, and most tasks are not hard. This is the same lever that model selection and dropping to a cheap model tier give you in other harnesses.
3. Turn off the observer agents you are not using. Three run by default in settings.json under runtime_capabilities, each making its own model calls. Verification is already off; the other three are a choice.
4. End sessions rather than continuing them. The transcript is billable input on every turn, so a fresh /new on a new task is the single cheapest habit available. Use /compact when you must keep going.
5. Put --max-model-steps on every headless run. It is not a dollar cap, but it is the only documented stop, and CI is where a loop runs unwatched at 3am.
6. Watch the usage dashboard weekly, because nothing else will tell you. There is no cap and no alert beyond email. Treat the usage analytics habit as mandatory rather than optional, and if this is going into a team, read up on admin controls first.

And the structural point, which I would rather say plainly than bury. A metered agent with no ceiling is the build-it-yourself end of the market, and building it yourself has a cost that never shows up on any rate card. One eesel customer, an engineering lead at a crypto hardware company, put it better than I could:

"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."

Karel, GENERAL BYTES

Some teams should absolutely still buy raw tokens. If your workload is spiky, your engineers are strong, and someone owns the bill, the unit economics are better and Muse Code is a well-built harness to spend them through. The build vs buy call turns on who has time, not on who has the cheaper rate card. And if the answer is "neither, I want a plan," the best AI coding assistants roundup is the shorter route to one.

Try eesel for the support side of this problem

If you got here because you are trying to forecast what AI actually costs, and the work you are forecasting is customer support rather than code, the unit is the whole argument. Muse Code prices machine effort, so its bill moves with how long a model ran. eesel prices a resolved ticket, so the bill moves with work finished, which is a number your finance team already tracks.

That matters most in the place Muse Code has no answer for: you can see what you are going to owe. eesel simulates a new agent against your own historical tickets before it touches a live queue, so you get the resolution rate and the cost projection from your real ticket history rather than finding both out in production. I have shipped a lot of those integrations, and the simulation step is the one customers keep mentioning back, because it is the difference between a forecast and a hope.

Worth a look if you are weighing a metered model bill against a per-resolution one: the breakdown of cost per resolution, the case for outcome-based pricing, and how to build the thing in practice with an AI helpdesk. Free to try, and you will know your number before you commit to it.