What happened
Models.dev’s page for Meta Muse Ember lists four providers, including OpenCode. In the OpenCode row, the model ID is muse-ember-1.0. The catalog gives the route a context limit of 1,048,576 tokens and an output limit of 270,000 tokens. It lists input pricing at $0.10 per million tokens and output pricing at $0.50 per million tokens.
Models.dev describes Muse Ember as Meta’s smallest and most efficient reasoning model. According to that description, it is intended for work agents repeat frequently: tool calls, coding subtasks, routing, extraction, and long-document parsing. The page says it can work alongside Muse Wonder or Muse Spark, where those models plan and Ember handles volume. That is the catalog’s characterization of the model, rather than an independently measured account of performance.
The page identifies the model family as muse, labels the weights closed, and marks reasoning, tool calls, and temperature as capabilities. It lists November 9, 2026 as both the release date and the latest update date. Structured output is marked as supported in the OpenCode row, while temperature is not marked there. The provider table also includes DevPass (LLM Gateway), LLM Gateway, and Meta. Their entries use the same canonical model family, but the displayed support flags and limits are not identical in every row.
The OpenCode entry is notably not simply a generic model record. It attaches a named provider, a model identifier, stated limits, and a token price to one route. That is enough information to put Muse Ember into an initial provider comparison for a team already using OpenCode or considering it as a model gateway. It is not, by itself, documentation of request syntax, authentication, regional availability, billing mechanics, or service-level commitments.
Models.dev calls itself an open-source database of AI-model specifications, pricing, providers, and features. It says its provider and catalog data are available through JSON endpoints, and it offers a type-safe SDK, @opencode-ai/models, for querying its snapshot. Those capabilities make the listing potentially useful beyond manual browsing: a team can inspect a catalog programmatically while maintaining its own model-routing or evaluation configuration.
For a builder, the material change is therefore a visible OpenCode-provider listing for Muse Ember, with enough metadata to frame a trial. The listing does not demonstrate that a particular account can call the model immediately, nor does it show how the provider behaves under load. It does show what should be verified first: the exact route, the displayed context and output ceilings, and the listed input and output prices.
What the archive adds
New Runtime’s earlier coverage reported that Muse Ember was available in Google Cloud Model Garden on November 10, 2026 (earlier coverage). This is a new provider-access fact, not a restatement: the OpenCode listing supplies a different route and its own displayed output limit and token prices. An earlier New Runtime note also examined Meta’s Muse Spark Open release boundary through its license (earlier coverage); that licensing question does not determine access to closed-weight Muse Ember.
Trend signal
This is a weak but concrete example of the provider layer becoming easier to inspect: one catalog page puts model identity, provider choices, capability flags, limits, and prices next to each other. That can improve procurement and routing decisions, but it does not show completed-task cost or reliable cross-provider portability. This does not yet fit a pattern New Runtime tracks.
Why now
Models.dev dates both the model’s release and its latest update to November 9, 2026. New Runtime’s earlier coverage placed Muse Ember in Google Cloud Model Garden on November 10, 2026. The sequence suggests a period of expanding distribution surfaces, although the catalog does not explain whether the OpenCode row was added at launch, later, or through a separate commercial arrangement.
Connections to other events
New Runtime’s November 10 coverage described Muse Ember as one of several Meta Muse models available through Google Cloud Model Garden (earlier coverage). The connection is distribution rather than a claim of equivalent product behavior: Google Cloud Model Garden and the OpenCode provider listing are separate paths with potentially different limits, billing, access conditions, and operational characteristics.
Why it matters
A model only becomes an operational option when a team can map it to a route, an expected budget, and a bounded job. The OpenCode row gives enough metadata to start that process. A team can select one repeatable workload—such as extraction from long documents, tool-call routing, or a coding subtask—record input and output tokens, and estimate the listed token charge before running a controlled comparison.
The 1,048,576-token context figure may be relevant for document-heavy systems, but it is a stated ceiling rather than proof of useful long-context behavior. Similarly, a low displayed token price is not equivalent to low cost per completed task. Retries, tool failures, output length, latency, and human review can all dominate the practical economics of an agent workflow.
The useful distinction is between discovery and adoption. A catalog entry reduces discovery friction and can be incorporated into an internal model inventory. Production routing should follow only after the team has confirmed credentials, rate limits, actual invoices, quality on its own evaluation set, and failure behavior. This is especially important when the workload involves tool use or decisions that require downstream verification.
What happens next
- OpenCode will clarify a user-facing access or billing path for Muse Ember. (3 months, 55%). Watch for: provider documentation, product release notes, or a route-specific API example.
- Teams comparing Muse Ember will publish or share workload-specific quality and latency results. (6 months, 45%). Watch for: reproducible agent-task evaluations that name the provider route and settings.
Limits and uncertainty
Models.dev is a catalog publisher, not an independent benchmark operator or Meta product announcement. Its page does not independently verify Meta’s characterization of Ember, test reasoning quality, or measure performance on agent tasks. It also does not establish whether every OpenCode account can access the model, whether plan or geographic restrictions apply, or what uptime and rate limits a caller receives.
The listed prices and limits are useful metadata, but teams should confirm them at the point of use. The page does not explain treatment of retries, cached tokens, tool-related calls, discounts, taxes, or other billing categories. It also does not disclose latency, throughput, capacity, safety behavior, or service guarantees. None of those gaps mean the route is unavailable; they define what remains to be tested before production reliance.
Skill to build now
Create a small model-route evaluation card this week. For one repeatable task, record the provider and model ID, prompt and tool configuration, input and output tokens, latency, completion quality, retry count, and reviewer time. Enter the catalog’s $0.10-per-million-input and $0.50-per-million-output figures as a provisional estimate, then replace them with observed billing. If you route agent work through a gateway, keep the route identifier in every evaluation record so results remain comparable when provider defaults change.
Reader takeaway
OpenCode’s Models.dev entry makes Muse Ember a concrete model route to investigate, with a named identifier, stated limits, and listed token prices. Treat it as a discovery and evaluation signal, not proof of availability or performance: test one bounded agent workload, verify billing and access, then decide whether it belongs in production routing.