A usage meter for a vendor that has none.

Meta ships a coding agent.

On 5 August 2026 Meta released Muse Code and Muse Spark 1.2. Meta's post calls Muse Code “a terminal coding agent powered by Muse Spark 1.2, our newest model”, installed on macOS or Linux with a single curl line. It describes a local event log “in which every model call, tool run, approval, and edit is appended”, so the agent can resume where it stopped after a crash.

The Register's write-up the next day, “Meta wants to get inside your terminal with its new coding agent”, put the price plainly: “Muse Spark's actual intelligence is metered at US$1.25 per million input tokens and US$4.25 per million output tokens.”

On Hacker News, the first comment was about a second price: “Meta is offering a 10x discount on input ($0.10 vs. $1.25/Mtok) and 20x discount on output ($0.20 vs. $4.25/Mtok) if you opt in to let them train on your data.” Hold on to that one. It matters twice in this story.

So Muse is pay per token. There is no monthly plan with a five-hour window, no weekly cap. You pay for what you use. That shapes what a useful meter looks like.

Muse as an engine, not a plugin.

In Luminair every model company is an engine, and every engine lives in one file. Meta's is desktop/engines/muse.js. Its opening comment calls Muse “engine number three”, and everything Luminair knows about Muse sits there: where the command lives, how it installs and updates itself, how a Meta sign-in becomes a Luminair account, and how its JSON stream turns into the events a session pane understands. The IPC for install, update and status is registered by the file itself, so main.js has no idea the engine exists.

A few things in that file are worth knowing if you use Muse through Luminair.

Meta also publishes a local model, Muse Glimmer, as open weights on the Ollama registry. Luminair runs it through Ollama on your Mac, and it only appears in the model picker once the weights are actually on disk. It costs nothing to run, which becomes relevant in a moment.

Every path said 404.

The account menu in Luminair shows a usage line under every signed-in account: how much of Claude's five-hour window is gone, how much of a Codex month, and so on. When Meta accounts arrived, the obvious question was where Muse's line would come from.

The comment above the Muse meter records the answer. On 15 September 2026 we tried Meta's API with a signed-in account's key: it answered 404 on every usage, billing and account path. Only the models listing answered.

At that point there are two easy mistakes. One is to show nothing, and let a Meta account look as if it costs nothing. The other is to invent a percentage: pick a daily budget, divide by it, draw a bar. That bar would look exactly like Claude's and mean something completely different. Worse, it would look authoritative.

Meta already told us the rate.

While the API would not say what you had spent, the launcher does keep a price list. It caches Meta's model catalog under ~/.local/share/muse/model-catalog/, and every row carries a cost block in US dollars per million tokens. This is the real row for the model Luminair uses, read from the catalog on the Mac this post was written on, trimmed to the fields that matter here:

{
  "model_id": "muse-spark-1.2",
  "release_date": "2026-08-05",
  "is_default": false,
  "context_limit": 1007997,
  "cost": { "input": "1.25", "output": "4.25", "cached": "0.15", "currency": "USD" }
}

Those are the same numbers The Register printed. The other half was already in Luminair. Since the token-attribution work in early August, every finished turn goes into a daily log, per model. In the same change as the Meta meter, recordTokenSpend in main.js started keeping input and output tokens apart per model, with a comment saying why: “a pay-per-token engine (Meta) prices them differently, and its meter is this tally times the catalog rate.”

The meter itself is about eighty lines at the end of the engine file. It reads every catalog file, takes today's log across every user scope on the computer, keeps only models whose id starts with muse-, and prices each one. Here is the case the test suite checks:

A few rules sit inside that function, and each one is there to avoid a specific kind of wrong number:

• Local, not Meta. Glimmer turns are skipped. They ran on your machine and Meta billed nothing.
• Older days fall back gently. Log entries written before the input and output split exist only as a total. For those, the meter uses the day's overall input to output ratio rather than pretending all of it was cheap input.
• A missing price is said out loud. If a Muse model has no row in the catalog, its line still appears with its token count and a note, “no price in the Meta catalog for” that model, rather than a guessed dollar figure.
• An idle day is not a missing meter. With nothing run today, the account still shows one row reading $0.00, so you can tell “free today” from “broken”.

Each row carries percent: null, a dollar amount, a reset at local midnight and estimate: true. The account menu already knew how to draw a money-first row with no percentage, because Claude's extra usage credit arrives the same way. So the Meta row slots in without special UI:

Each meter says what it is.

The Muse meter landed on 16 September 2026 in the same commit as two others, for engines whose vendors also publish no meter an app can call directly. Put side by side, they show why one shape does not fit every vendor.

That is the whole rule. A meter should be the vendor's number when there is one, the vendor's refusal when that is all there is, and, when there is neither, our own count in the vendor's own currency, labelled as ours.

Checked, and not claimed.

Sources

• Meta AI Research · 5 August 2026Introducing Muse Code and Muse Spark 1.2
• The Register · 6 August 2026Meta wants to get inside your terminal with its new coding agent
• Hacker News · August 2026Muse Code and Muse Spark 1.2 (discussion)

For how Luminair holds many engines in one app, read One window for every model.