muse-glimmer-30b: the Muse Glimmer 30B agentic model as a metered API

muse-glimmer-30b is this platform's serving alias for Muse Glimmer 30B, the open-weight agentic model that Meta Superintelligence Labs released in August 2026 under Apache 2.0. It is a dense model of about 29.6 billion parameters with a vision encoder built in, trained for always-on agents: long chains of tool calls, recovery when a call fails, and images read alongside text. This page gives the identity facts with their owners, the honest split between hosting it here and running it yourself, the exact call contract as this gateway enforces it, and both layers of the benchmark record. The route is live on the chat endpoint today.

Last verified: 2026-09-10

What it is

The model behind the alias is best understood by its geometry. Muse Glimmer 30B is dense, not a mixture of experts: about 29.6 billion parameters total, and that count includes a dedicated perception encoder of about 1.8 billion parameters (a ViT-G/14 vision tower). The text stack is 52 layers with a repeating attention pattern of three local layers followed by one global layer. The local layers use a 2,048-token sliding window; only every fourth layer attends across the whole context. Attention is grouped 32 query heads to 2 key-value heads. That design is why the model serves a long window without the memory cost of full attention everywhere, and it is part of why community testers found it stretches to much longer contexts than it was trained for.

The model was distilled from Muse Spark, a larger Meta model, and it is the first open model released by Meta Superintelligence Labs. The model card describes the target workload precisely: autonomous agentic tasks on consumer hardware, with multi-step reasoning, reliable tool use, multimodal understanding, and failure recovery trained into one model. Input is text and images; output is text only. Audio is not supported, and video is processed as individual frames. Training data covered more than 100 languages, and the knowledge cutoff is January 4, 2026.

The facts that matter for planning, each with its owner:

One row of that table clears up a confusion you will meet across the web. Pages disagree on the context window: some say 128K, some say 131K, one vendor page says 120K+. These are not different models. 131,072 is 128 times 1,024, so "128K" and "131K" are the same window written in different units, and the lower vendor figure most likely reflects serving reserves rather than the model. The card's plus sign is its own statement: the trained window is a floor of sorts, and the release blog points at longer use. Community testers took that seriously: one documented experiment ran the model on two DGX Spark units with YaRN scaling and passed retrieval checks at over 800,000 tokens. This platform's route sells the full 131,072-token window, and the Benchmarks section shows the live probe that verified it.

On reasoning: Muse Glimmer thinks before it answers. The strength of that thinking is controlled officially by a phrase in the system prompt, "Reasoning strength: high" for example, with four levels from low to xhigh. There is no thinking knob in the request body on this route, which is a deliberate contract decision covered in the API usage section.

The model answers to muse-glimmer-30b on the chat route, alongside the rest of the chat catalog. The models index reflects the catalog as it stands.

Use cases

The card's intended-use list translates into concrete jobs:

• Always-on agents. The training goal is a model that runs for hours: many sequential tool calls, state held by the harness, and recovery when a tool fails or returns something unexpected instead of halting. If you are wiring a personal agent or an automation that must survive its own mistakes, this is the model's center of gravity.
• Coding agents. The card names SWE-Bench style workflows as intended use, and the publisher's numbers on agentic coding benchmarks are strong for the size class. Community daily-driver reports are more mixed on raw coding intelligence than on tool use, which the Benchmarks section addresses directly.
• Function calling at the API level. Schema-based tool invocation across long multi-turn workflows is a trained behavior, not a prompt trick. On this route it works through the standard OpenAI tools shapes.
• Multimodal agent tasks. Screenshots, charts, and documents can enter the conversation through the perception encoder, up to 4,096 visual tokens per image.
• Synthetic data and evaluation. The card lists synthetic data generation and LLM-as-judge work as intended uses; a per-token metered route suits both, since these are batch-shaped workloads where you pay per token and want the metering on.

What it is not for: audio of any kind, video understanding beyond frame-by-frame treatment, and, on the evidence available, beating the best same-size rivals at raw coding intelligence. It is a tool-use and endurance specialist.

Local or hosted: the honest split

This model was built to run locally, and for some readers that is the right answer. The split:

Run it locally when a 24 GB or 32 GB machine is already on the desk, traffic is steady, the data must stay inside a boundary you control, or you want the quant ecosystem. The publisher ships two official 4-bit builds: K-Quant-17GB, targeted at 24 GB cards, and K-Quant-Dynamic, targeted at 32 GB systems, with measured quality loss of 1.0% and 0.2% respectively across 15 benchmarks. Full-precision BF16 weights run about 60 GB and belong on 64 GB or larger hardware; a serving stack with a full KV cache plans for more than the weights alone. Ollama's library carries it as muse-glimmer with vision and tools support, and llama.cpp, MLX, ExecuTorch, vLLM, and SGLang recipes all exist from day one. The release also ships a speculative decoding drafter called DFlash that proposes whole blocks of tokens, with publisher-measured decode speed going from 74.9 to 233.4 tokens per second on an RTX 5090, and smaller gains on Apple silicon.

Call the hosted route when there is no GPU to dedicate, traffic is bursty or occasional, you want the metering, key revocation, and billing ledger wrapped around the model, or you would rather not own a serving stack. That enumeration is the hosted product in one line: a pinned route on the chat endpoint, per-token metering against a prepaid wallet, keys revocable the instant one leaks, and a cost field riding every response.

Two model-specific warnings for the local road. First, tool calling breaks silently on a misconfigured server: the model's native tool-call format is called ATEM and it is not JSON, so a vLLM server needs the muse_glimmer tool-call parser and reasoning parser enabled or tool calls arrive mangled. Meta's serving guide documents the exact flags; this was the loudest complaint in the first weeks of community threads, and the fix is a pair of parser flags. Second, do not run it greedy: the same serving guide warns that temperature 0 degrades output, and recommends carrying the published trio of temperature 1.0, top_p 0.95, and top_k 64 rather than a bare temperature.

API usage

The route is POST /v1/chat/completions, OpenAI-compatible in shape, your console-issued Bearer key in the Authorization header. The model id is muse-glimmer-30b.

Four laws of this route that save debugging time:

1. There is no thinking knob. The gateway rejects reasoning_effort for this model with a named parameter error, because the platform contract exposes no thinking parameter here and the model's official control is not an API field. To set reasoning strength, put the phrase in the system prompt: Reasoning strength: high. This is the mechanism the model card documents, it travels as plain text, and it works on any OpenAI-compatible host that passes system messages through.
2. Tool calling is standard on top, unusual underneath. You send OpenAI tools shapes and read tool_calls from the response. The model's native format, ATEM, is parsed on the serving side on this route. One native behavior worth knowing: the model tends to emit one tool call per assistant message, so if you self-host later, a harness that reads only the first tool_calls entry of one message can drop work.
3. Every response carries your cost. Each reply reports cost in its usage object, the retail charge for that call at this platform's rates, computed from input, cached-input, and output token counts. A prepaid wallet pays the charge in the transaction that records the call, and its balance is what spend runs up against. Cached tokens are billed at their own rate and reported in prompt_tokens_details. Per-key spend caps are roadmap, not live; per-key revocation is live.
4. A full window is a long request. The route sells 131,072 tokens of context. A live probe on this route in August 2026 carried a 130,043-token fresh prompt end to end in 4.9 seconds, but a deep fresh context still deserves a client timeout with headroom, and streaming suits long reasoning chains.

curl

curl -X POST "https://api.ironstratum.com/v1/chat/completions" \
  -H "Authorization: Bearer $KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "muse-glimmer-30b",
    "messages": [
      {"role": "system", "content": "Reasoning strength: high"},
      {"role": "user", "content": "List three steps to verify a JSON schema against a payload."}
    ],
    "max_tokens": 1024
  }'

python

import os
import requests

resp = requests.post(
    "https://api.ironstratum.com/v1/chat/completions",
    headers={"Authorization": "Bearer " + os.environ["KEY"]},
    json={
        "model": "muse-glimmer-30b",
        "messages": [
            {"role": "user", "content": "Check whether this config file has duplicate keys."},
        ],
        "tools": [
            {
                "type": "function",
                "function": {
                    "name": "read_file",
                    "description": "Read a file from the workspace",
                    "parameters": {
                        "type": "object",
                        "properties": {"path": {"type": "string"}},
                        "required": ["path"],
                    },
                },
            }
        ],
        "tool_choice": "auto",
        "max_tokens": 2048,
    },
    timeout=120,
)
resp.raise_for_status()

message = resp.json()["choices"][0]["message"]
if message.get("tool_calls"):
    call = message["tool_calls"][0]
    print(call["function"]["name"], call["function"]["arguments"])
else:
    print(message["content"])
print("cost:", resp.json()["usage"]["cost"])

openai-sdk

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://api.ironstratum.com/v1",
    api_key=os.environ["KEY"],
)

response = client.chat.completions.create(
    model="muse-glimmer-30b",
    messages=[
        # The official reasoning control is this system-prompt phrase,
        # not a request parameter.
        {"role": "system", "content": "Reasoning strength: high"},
        {"role": "user", "content": "Summarize the failure modes of retrying a flaky API without backoff."},
    ],
    temperature=1.0,
    top_p=0.95,
    max_tokens=2048,
)

print(response.choices[0].message.content)
print("cost:", response.usage.cost)

Moving an existing OpenAI-SDK integration here is a two-line edit: the base URL and the model id.

Benchmarks

The evidence comes in two dated layers, and the basis of each is stated with it.

This platform's route. The window and its behavior were verified by a live probe on 2026-08-20; the measurement record is the platform's task-6 context probe log.

The model itself. From the official model card, publisher-reported. Configuration, per Meta's evaluation methodology report: high reasoning strength, temperature 1.0, top_p 0.95, top_k 64; for the comparison models, the better of each rival's self-reported score or Meta's internal reproduction.

Read that table with its label on. It is the publisher's own run, on named harnesses, and it shows a genuine split: Muse Glimmer leads clearly on the agentic benchmarks (MCP Atlas, DeepSearch QA, Gaia2) while Qwen3.6-27B leads on several coding and computer-use rows. The independent record is thinner and points the same way. Community daily-driver threads after the Qwen 3.8 release describe Qwen as the smarter coder and Muse Glimmer as the faster, lighter model, with one tester on a single RTX 3090 reporting roughly twice the decode speed at full context with the DFlash drafter enabled. None of this settles a workload question; it defines the honest state of the evidence. If the workload matters, run it on your own tasks, on this route or any other.

Getting started

1. Register on the console. The invite flow is the way in while the platform is in beta, and it is where the wallet and key management live.
2. Mint an API key. One per project is the working pattern: revoking a key touches nothing else, and the wallet balance remains the only spend ceiling shipping today (per-key caps are roadmap).
3. Check the rate. Input, cached-input, and output tokens each carry a registry rate, all three published on the pricing page, and each response's usage.cost field shows the accrual as it happens.
4. Make the first call. Paste the curl tab with KEY exported and send a single line. Once a reply lands, scale is nothing more than a bigger messages array.

For a deep fresh-context call, set your client timeout past the first-token wait. More chat models are on the chat category page, and the full platform map is the models index.