Muse Code has two prices and neither of them is the price: a subscription at $5, $15, $50 or $200 a month, and a token rate on the model API of $1.25 per million input and $4.25 per million output [VENDOR: the vendor’s published plans and rates]. The split is documented on OrcaRouter in the muse code write-up of the terminal coding agent — the subscription buys the harness and the API key is billed separately per token — and this article is about what that separation does to a budget.
What each half actually buys
The subscription buys the harness: the `muse` binary, the interactive terminal UI, the `muse exec` non-interactive mode, the `muse serve` session protocol, the OS sandbox, the workspace trust model that loads skills, rules and hooks, and the four usage tiers.
The token rate buys the work: every plan, edit and command the agent performs consumes input and output tokens on the model API, billed at the Standard-tier rates.
A team that budgets only the subscription has priced the software and not the work. A team that budgets only the tokens has priced the work and not access. The monthly total is the sum, and the two components have completely different shapes: one is a step function in seats, the other is linear in usage.
The arithmetic on a realistic pipeline
The cost that separates the two halves is the number of non-interactive passes a month, because `muse exec` is the mode that scales.
Take a CI pipeline that runs the agent on every pull request: 40 pull requests a month, each with two passes, on a context of 25,000 tokens of files and diff and an output of 2,500 tokens.
• Input: 40 × 2 × 25,000 = 2,000,000 tokens × $1.25 ÷ 1,000,000 = $2.50.
• Output: 40 × 2 × 2,500 = 200,000 tokens × $4.25 ÷ 1,000,000 = $0.85.
• Token total: $3.35 a month.
Add a $5 seat and the whole arrangement costs $8.35 [OURS arithmetic on VENDOR rates]. At that volume the subscription is 60 percent of the bill and the tokens 40 — the harness is not a rounding error, it is the larger half.
Now scale the pipeline. A hundred and fifty pull requests a month with the same shape:
• Input: 150 × 2 × 25,000 = 7,500,000 × $1.25 ÷ 1,000,000 = $9.38.
• Output: 150 × 2 × 2,500 = 750,000 × $4.25 ÷ 1,000,000 = $3.19.
• Token total: $12.57, against a $5 seat.
At 3.75× the volume the token bill is 3.75× larger and the seat is unchanged. That is the crossover shape in miniature: below a few dozen passes a month the seat dominates; above a few hundred, the tokens do.
The crossover is not a fixed number, because the four tiers gate usage rather than volume. Running more passes than your tier allows is a different kind of failure from running a large bill — it is a limit, not a cost.
The version that changes what the tokens buy
One variable on the token side is easy to overlook: which Muse Spark the CLI is driving.
Muse Spark 1.3 is the current generation, dated 2026-09-02. The CLI still selects Muse Spark 1.2 by default. 1.1 is served on the same tier at the same rates [VENDOR].
All three bill at the same $1.25/$4.25, so the version is not a cost decision — it is a capability decision that costs the same. A team paying for the harness and running the previous model has bought the current product and is using the previous one, at no saving and no warning.
The check is cheap: `muse –version` reports the CLI, and the model selection is a separate setting that has to be named explicitly to reach 1.3.
Why the harness is a protocol, and why that changes the cost model
The part of Muse Code that most summaries miss is that it is not only a CLI. `muse serve` runs a versioned session protocol, `muse schema` prints its JSON schema, and `npm install @muse-code/sdk` installs a TypeScript wrapper. The changelog shows the protocol being extended deliberately: sessions can be renamed over it, clients can read a structured diff summary per edit, and a driving program can set a session-wide reasoning-effort default.
For a budget, that last item is the interesting one. A reasoning-effort default is a per-session multiplier on how many tokens each step spends. A service driving thousands of sessions through `muse serve` can change its own token consumption by changing that setting, without changing a single price.
So the two halves of the bill are not independent in practice. The harness sets how much work each pass does, and the rate card prices that work. A team optimising the token half is really optimising its own harness configuration.
The model is on a gateway at the same rate
The token half of the bill does not have to be paid at the vendor’s endpoint, and this is the one place the two halves can be separated commercially.
The Standard-tier rates of $1.25 input and $4.25 output are exactly what the OrcaRouter Meta provider page shows for Muse Spark 1.1 and 1.2, passed through with $0 markup, with a $0.150 cached rate and a 1M context [OURS catalogue; VENDOR rates].
So a team can keep the harness — which is licensed and billed by the vendor — and route the model calls through a gateway that charges the same per-token rate with its own failover, logging and spend controls. The seat is unchanged; the token half simply has a different address.
That matters most at the scale where the token bill dominates. On the hundred-and-fifty-PR pipeline above, $12.57 a month is small in absolute terms but the shape of the decision is not: it is the part of the bill that grows, and it is the part that can be moved without touching the subscription.
How to build a budget for a two-bill product
Four steps.
Price the seat and the work separately. They have different shapes and different growth rates. A single blended number hides which one is about to double.
Count the passes, not the developers. `muse exec` and `muse serve` are the modes that scale with automation, and they are where the token bill comes from.
Name the model explicitly. The CLI’s default is not the current generation, and the rate card is identical across generations, so an unstated default is a capability loss with no cost saving.
Treat the harness settings as cost settings. Reasoning effort, session defaults and pass structure all move the token bill without moving a rate.
A product sold as a seat plus a meter is not unusual; what is unusual here is that the meter is the part that decides the bill, and it is the part a plan comparison never shows.
Sourcing note: the four plan prices, the Standard-tier rates of $1.25 and $4.25 per million tokens, the three Muse Spark versions and their dates, and the session-protocol and reasoning-default details are the vendor’s own published facts as reported on our pages read on 2026-10-21 [VENDOR]. The Muse Spark 1.1/1.2 rates on the OrcaRouter Meta provider page are the vendor’s published prices passed through with $0 markup [OURS]. The per-pass and per-pipeline figures are our own arithmetic on a stated shape — 25,000 input tokens, 2,500 output tokens, two passes per pull request — and are not a quote from any vendor. All values checked 2026-10-21.
