Muse via the raw Meta Model API (loop-muse-build)

A SECOND, unrelated way to reach the same models: a key-only LoopAgentAdapter against Meta's OpenAI-compatible endpoint, with no muse binary and no CLI login. It is registered but ships retired, so the recipe below is what to run once the account can actually bill.

# 1. mint the key (operator action, once): sign in at dev.meta.ai and create a Model API key.
#    Store it in the GLOBAL config layer, not a repo .env:
#      ~/.cyberine/.env  ->  MODEL_API_KEY=LLM|<numeric_id>|<secret>

# 2. confirm auth independently of billing -- these are two separate gates
curl -sS -H "Authorization: Bearer $MODEL_API_KEY" https://api.meta.ai/v1/models

# 3. un-retire the worker: delete the 'loop-muse-build' entry from RETIRED_WORKERS
#    in src/core/workerProfiles.ts

# 4. dispatch it explicitly (it is not in fleet.json, so the router never auto-picks it)
CYBERINE_BUILD_FLEET=loop-muse-build cyberine run "<task>"

Why the key is MODEL_API_KEY and not META_API_KEY: those are two credentials for two products. META_API_KEY authenticates the muse CLI (and is normally unnecessary, since muse login stores an OAuth token in the macOS Keychain); MODEL_API_KEY authenticates this HTTP API and appears nowhere in the CLI binary. Neither substitutes for the other, and lifting the CLI's Keychain token to use as a bearer here is a forbidden pattern in this repo (see the ksmpy tombstone).

Known Limitations and Deferred Work

It ships retired because the endpoint bills separately, and this account has no payment method. Measured 2026-09-05 with a freshly minted key: GET /v1/models returns 200 and lists all four muse ids, while EVERY POST /v1/chat/completions returns 402 billing_not_configured -- reproduced on muse-spark-1.3, muse-spark-1.3-contributor, muse-spark-1.2 and muse-spark-1.1, with and without a tools array. Auth and billing are independent gates here, so metaDirect (which only tests key presence) cannot detect the second one; the RETIRED_WORKERS entry is what keeps the router off a worker that fails every dispatch, exactly as it does for loop-minimax-build's 402.

The flat-rate muse subscription does NOT cover this path. The muse CLI worker is costModel: 'subscription' with $0 marginal cost; this one is costModel: 'metered'. Meta publishes no rate this repo can read -- the CLI catalog's cost: null describes the subscription, and /v1/billing and /v1/usage both 404 -- so costClass is pinned at 3 rather than guessed cheap, because an unknown rate must never win a cheapest-first router pick.

Tool calling is UNVERIFIED on this endpoint. The 402 arrives before any completion, so a tool-call round trip has never been observed to succeed. lspCapable and multimodal are therefore deliberately absent from the worker profile -- either flag would float an unproven worker up in routing. Verify tool calling before trusting it for implement tasks.

Not in the auto-routing pool. Same fleet.json gate as the CLI worker above: with no entry in ~/.cyberine/fleet.json it is excluded from auto-routing and reachable only through an explicit CYBERINE_BUILD_FLEET. Whether it should be added there is a deliberate operator decision, not a defect.

Tool progress is post-hoc. The event stream has no tool-call-START event -- only tool.result -- so the TUI learns a tool ran after it finished, unlike claude/codex/opencode where progress reads running <tool>. The detail string says ran <tool> (<outcome>) so the difference is visible rather than implied. There is no fix available from the exec surface. muse serve (MSP) does stream richer live telemetry, and it was evaluated and deliberately DEFERRED (krjy7) - the reasoning and the concrete reviving conditions are recorded in docs/providers/muse-cli.md.

Usage is a post-hoc log read, not stream data. muse exec --json emits no token field on any line, so usage is read from the durable session log after the process exits. A failed read reports usage: undefined with a printed reason rather than a zero -- but it does mean usage is unavailable while a run is still in flight.

This repo's own .claude/rules/ do not reach a muse worker. Muse has no rules-directory concept: it loads a workspace-root AGENTS.md (or CLAUDE.md as a fallback when no AGENTS.md exists) and nothing else. A muse worker in a Cyberine worktree therefore does not see the project rules the other CLI workers pick up.

--model validation cannot be trusted in either direction, so the adapter gates on the LOCAL catalog before spawning. Measured, the same bogus id answered normally with exit 0 in 20 of 21 runs in one session and failed in 6 of 7 in another, hours apart on the same machine and credential -- the split is server-side. If CYBERINE_MUSE_MODEL names an id absent from ~/.local/share/muse/model-catalog/, the dispatch fails before spawning with the catalog listed.

Subscription quota is unreadable. The interactive TUI shows a 5-hour and a weekly window as percentages, and the binary carries the structs behind them, but they appear in no exec event, no session log, and not in the MSP wire schema. Nothing here can warn before the quota runs out.

Nested sandbox is verified on Seatbelt only. CYBERINE_TASK_TRUSTED=false keeps Muse's own sandbox running inside the host sandbox, measured working on macOS/Seatbelt (10.5s vs 9.0s single-layer). The same nesting on bubblewrap or a container backend is unmeasured.