Building a Muse connector: the API, the costs, and what to prep

Meta opened Muse connectors to developers on 2026-09-18: your service stops waiting to be installed and starts being reached by an agent when a person's task needs it. This guide lays out what Meta has actually published about the program, what an agent-facing API needs to have ready, where the metered model spend sits in a connector's backend, and how a prepaid wallet turns the worst backend bill into a top-up instead of a debt. It also separates the Muse agent platform from the Muse Glimmer open-weight model served on this platform, because the shared name is already tangling searches.

All amounts in this guide are US dollar amounts, and every program fact carries its date: this space changed three times in the week before publication.

What a Muse connector is

Muse is Meta's consumer personal agent. It launched on 2026-09-08 in the United States on iOS, Android, and muse.ai, with a free tier and monthly subscriptions at $20 or $100 depending on usage, per CNBC's launch coverage. Mark Zuckerberg's framing, quoted across the launch interviews, is an agent that understands your habits and goals and handles everyday tasks for you.

A connector is how a service becomes reachable inside those tasks. The model is the one the muse.ai/platform page states: you bring the API, Muse brings the agent, and a person reaches your service by asking for it. The partner logos on the platform page at launch were consumer services: Peloton, Gmail, and Lattice. Coverage of the out-of-the-box set names Browser, Facebook, Gmail, Instagram, and the Meta catalog.

Two properties follow from that shape, and both matter to anyone planning to build one. First, the user never installs anything: distribution is the directory listing inside the agent, and Muse's editors decide featured placement, which makes the directory a ranking surface the way app stores are. Second, the traffic arrives unforecast: a placement decision on their side, a usage spike on yours, with no launch email and no ramp.

What Meta has published, and what it has not

The connector program opened on 2026-09-18 with a single page. Here is the honest split, verified against muse.ai/platform on 2026-09-19.

One more fact belongs in this section rather than a footnote: on 2026-09-19 the Submit a connector button on the platform page pointed back at the same page. The program is announced but the intake door is not mechanically open yet, and there are no developer docs to read ahead on. The practical reading is that readiness and queue position are the scarce assets right now: the developers who can submit a working, reviewable connector the week intake opens get the directory's early attention, and everyone else gets in line behind them.

What "you bring the API" will ask of your service

Muse has not published the connector contract, so anything specific about required verb shapes or auth headers would be invention. What can be said today is what the published review criteria imply, because "functional, security, and legal requirements, and complete end to end testing" is a real test suite even before its details exist:

• A live HTTPS API the reviewer can exercise end to end, with no sales call in front of it.
• Authentication an agent system can hold and use without a human in the loop.
• A machine-readable description of the surface, which in practice means an OpenAPI specification, plus one plain paragraph saying what the service does for a person.
• Operations shaped as outcomes the agent can request, not internals it must assemble.
• Documented, predictable errors, and idempotency on any operation that moves money or state.
• Billing that survives a usage spike arriving without warning, which is the subject of the next two sections.

Every one of those is worth building regardless of how Muse's eventual spec lands, because they are the same requirements any agent-facing surface imposes. None of them is wasted work if the connector program shapes up differently than expected.

The cost line nobody prices in: the connector's backend model calls

A connector that does real work almost always calls models somewhere in its backend: classifying the request, extracting entities, summarizing results, planning steps, ranking options. Those calls are metered per token at whatever inference provider the backend uses, and they run unattended inside an agent loop that multiplies calls per task.

This is the exact failure shape documented in how to avoid API bill shock: estimation error, runaway loops, and agent fan-out, with a documented case of a 100-agent swarm burning 603 billion tokens in one month for a 1.3M bill. The connector version has a new amplifier the old cases did not. A connector lives or dies by directory placement, and placement is a step function: one good position, and the backend's call volume jumps by whatever multiple the placement drives, overnight, on billing that at most providers is post-paid credit with alerts that lag.

The question to answer before submitting anywhere is not whether the backend can serve the traffic. It is what the backend's worst day costs, and what stops it.

The spend shape that fits: a floor under the backend

The structural answer is the same one the bill-shock guide argues for any unattended workload, applied to the connector's inference line item: a billing shape where the worst case is bounded by something chosen in advance.

postpaid worst case:  cost = r x V, and V is unbounded
prepaid worst case:   cost = at most W
when the wallet reaches zero, the next request is denied

Name the pieces: r is the per-unit rate your backend pays, V is the volume a runaway workload or a placement spike consumes, W is the prepaid wallet balance sitting under the key. On a postpaid account the spike bills you for every unit it burns while you sleep. On a prepaid account it burns the wallet and hits a floor.

This platform is prepaid only, and the mechanics are the ones a connector backend wants: the wallet is the billing model, a balance guard denies any request whose key sits at or below zero at request time, and every reply carries a usage object whose cost field reports that call's retail charge, so the backend can log spend per request without estimating. The API is OpenAI-compatible, so pointing a connector's model calls at it is a base URL and key swap (the OpenAI-compatible API guide covers the details). Keys are revocable, and the hygiene worth copying from the bill-shock guide applies doubly here: one key per connector environment, so a staging loop and a placement spike never share a ceiling. Two honest limits, unchanged from that guide: per-key spend caps inside one account are on the roadmap, not shipped, so the wallet floor is the hard stop today; and prepaid means topping up for the work you plan, with the balance treated as the blast radius.

Two Muses: the agent platform and the open-weight model

One naming collision needs untangling, because it is already sending searches to the wrong pages. Meta's Muse is the consumer agent and the connector program described above. Separately, Meta Superintelligence Labs released Muse Glimmer 30B in August 2026: an open-weight, Apache 2.0, about 29.6 billion parameter agentic model with built-in image input, distilled from the larger Muse Spark model. That checkpoint is a file anyone can download, and it is served as a metered API on this platform at muse-glimmer-30b, alongside other open-weight chat models like qwen3.6-35b and glm-5.3-flash.

If you went looking for a Muse API meaning the model, that model page is the destination. If you are building a connector backend and want an agentic open-weight model under it, the open-weight release means the choice is self-hosting versus a hosted metered route, not vendor lock-in: the same weights, your hardware or ours.

A readiness checklist while the intake door is closed

The window between announcement and open intake is prep time. The checklist, in submission order:

1. Stand the API up live, end to end, with no human gate in front of the happy path. The published review includes complete end-to-end testing.
2. Write the one-paragraph capability description: what a person asks for, what your service does, what it returns. This is the "describe your product" intake step, and it is also the text a directory editor reads.
3. Publish a machine-readable surface: an OpenAPI specification covering every operation the connector exposes, with errors documented per operation.
4. Put auth on a credential an agent system can hold: issued, revocable, and scoped per environment.
5. Add idempotency keys to every operation that moves money or state, so an agent's retry cannot double-charge.
6. Put a floor under every metered dependency, inference first: prepaid wallets where the provider offers them, enforced hard limits where it does not, and a local spend tripwire inside the backend loop as the early-warning layer.
7. Dry-run the spike: place a load test at several times current volume and watch what the billing shape does, before a directory editor does it for you.

Frequently asked questions

What is a Muse connector?

A service integration for Meta's Muse personal agent. You expose an API, and when a person's task in Muse needs what your service does, Muse's agent calls it: the platform page's phrasing is that you bring the API and Muse brings the agent. Connectors are listed in a directory inside the agent, with editors choosing featured placement. The program opened to developers on 2026-09-18.

How do I submit a Muse connector for review?

Per the published three steps: describe your product, submit for review, and appear in the directory once approved. The review covers functional, security, and legal requirements plus complete end-to-end testing. As of 2026-09-19 the Submit a connector button on muse.ai/platform pointed back at the same page, so the intake form was not mechanically open yet; watch that page, and use the closed window to finish the readiness checklist above.

What does it cost to build or run a Muse connector?

Two different numbers. Listing economics, meaning any fee or revenue share Muse charges or takes, were not published as of 2026-09-19. Your running costs are yours: hosting, and the metered API calls your backend makes, model inference being the line item that scales with usage. A connector that calls models server-side should assume its inference bill is proportional to directory-driven traffic it cannot forecast, and bound it in advance: the bill-shock guide documents what unbounded looks like.

Can a Muse connector call an LLM API on its backend?

Yes, and that is the common shape for any connector doing nontrivial work: the connector's own backend classifies, extracts, summarizes, or plans using model calls, metered per token. Two disciplines keep it boring: an OpenAI-compatible provider so the backend is portable with a base URL change, and a spend floor under the key, prepaid wallet or enforced hard limit, so an agent-driven usage pattern cannot open a credit line.

Is Meta's Muse agent the same thing as the Muse model on this platform?

No. Muse the agent is Meta's consumer personal agent and the connector program's host. Muse Glimmer 30B is a separate open-weight model that Meta Superintelligence Labs released in August 2026 under Apache 2.0, distilled from the larger Muse Spark model; this platform serves it as a metered, OpenAI-compatible API. The shared brand root is a naming collision, not a product relationship.

How do I cap my connector's API spend?

Layered, with the provider-side floor as the load-bearing layer: a prepaid wallet or enforced hard limit at the inference provider, so the worst case is a top-up rather than a bill; one key per connector environment, revoked on suspicion, so containment is surgical; and a local spend counter inside the backend loop as a tripwire on your own runaway code, which catches your bugs in minutes but cannot stop a thief. The full comparison of what major providers actually ship, with their documented enforcement lags, is in how to avoid API bill shock.

Sizing a wallet and pointing a key at this platform starts on the pricing page; sign up and create the connector environment's first key when the backend is ready.

Last verified: 2026-09-19