Muse Spark 1.3 is a general-purpose reasoning model from Meta with tool calling, JSON mode and a 1M-token context. GetVibe API serves it through the standard OpenAI-compatible endpoint, so you can call it with the code you already have. There is one thing to know before you start: Muse Spark thinks a lot before it answers, and if you leave max_tokens small, you will get an empty response. This guide shows the model ID, the price, what we measured, and how to set it up so it works the first time.
The one setting that matters: max_tokens
Like other reasoning models, Muse Spark writes hidden reasoning tokens before the visible answer. Those tokens count toward max_tokens and are billed as output. What sets Muse Spark apart is how much it reasons: roughly 650 to 5,400 reasoning tokens on a short question, by the figures in our catalog.
We saw the same pattern ourselves. We asked a one-line arithmetic question (how long is a train trip from 14:35 to 18:10) and got a correct, one-sentence answer, but look at the token split:
- Visible answer: about 20 tokens (“The trip lasts 3 hours and 35 minutes.”)
- Reasoning: 514 tokens
- Total output billed: 534 tokens
If max_tokens had been 256, the model would have run out of budget mid-thought and returned an empty message with finish_reason: "length". The fix is simple: give it room. For short questions use at least 4,000; for coding or multi-step tasks 8,000 to 16,000 is reasonable. You only pay for tokens actually generated, not for the limit you set, so a generous ceiling costs nothing extra on easy prompts.
Specs and price
- Model ID:
muse-spark-1.3 - Maker: Meta
- Price: from $0.8875 input · $3.0175 output per 1M tokens.
- Cached input: a tenth of the regular input rate for repeated prompt prefixes.
- Context window: 1,048,576 tokens.
- Reasoning effort:
minimal,low,medium,high,xhigh,max. Reasoning is billed as output. - Tool calling and JSON mode: supported.
- Input: text only (no images).
The price says “from” because GetVibe routes each request to the cheapest healthy channel first and falls back if it is busy, so a request can occasionally cost more than the floor. The Muse Spark 1.3 model page shows the live range, and the dashboard shows what every request actually cost; see balance and usage.
Because the model reasons heavily, budget by output tokens, not by the length of the answer you see. A request whose visible reply is one sentence can still bill several hundred output tokens.
How to connect
Get an API key from your GetVibe account, point any OpenAI client at https://getvibeapi.com/v1, and use the model ID muse-spark-1.3.
Python with the OpenAI SDK
import os
from openai import OpenAI
client = OpenAI(
base_url="https://getvibeapi.com/v1",
api_key=os.environ["GETVIBE_API_KEY"],
)
resp = client.chat.completions.create(
model="muse-spark-1.3",
messages=[{"role": "user", "content": "A train leaves at 14:35 and arrives at 18:10. How long is the trip? Answer in one sentence."}],
max_tokens=8000, # generous: reasoning tokens count toward this limit
)
print(resp.choices[0].finish_reason)
print(resp.usage.completion_tokens, resp.usage.completion_tokens_details.reasoning_tokens)
print(resp.choices[0].message.content)
Our run on October 22, 2026 printed this, in about four seconds:
stop
534 514
The trip lasts 3 hours and 35 minutes.
Always check finish_reason in production. stop means the model finished; length means it hit your limit and the answer may be missing or cut off.
curl
curl https://getvibeapi.com/v1/chat/completions \
-H "Authorization: Bearer $GETVIBE_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"model": "muse-spark-1.3",
"messages": [{"role": "user", "content": "Summarize the trade-offs of SQLite vs PostgreSQL for a small SaaS in five bullets."}],
"max_tokens": 8000
}'
In our run this came back with finish_reason: "stop", five clear bullets (operations, concurrency, features, reliability, cost and future-proofing) and this usage: 27 prompt tokens, 998 completion tokens, of which 704 were reasoning. Again, about 70% of the output bill was thinking you never see.
Turning reasoning down with reasoning_effort
Muse Spark accepts the standard reasoning_effort parameter with six levels, from minimal to max. Lower effort trims reasoning tokens, which makes answers faster and cheaper. We sent the same train question at two levels:
reasoning_effort="low": 315 reasoning tokens, 335 output tokens in total, correct answer.reasoning_effort="high": 439 reasoning tokens, 459 output tokens in total, same correct answer.
Even on low, the model still reasoned for about 300 tokens on a trivial question, so lowering effort does not make it safe to shrink max_tokens to a few hundred. Reasoning length also varies from run to run; our default-effort run used more than the high one. Use lower effort for routine traffic and save high and above for problems that actually need it. Background in reasoning effort explained.
Tools, JSON and long context
Tool calling uses the standard tools array and tool_calls in the response, so existing agent frameworks work without changes; see tool calling. For machine-readable output, JSON mode is supported; our JSON mode guide explains the differences between models.
The 1M-token window fits large documents or long agent histories in a single request. When the same big prefix is resent every turn, it is billed at the cache rate, a tenth of normal input. See prompt caching explained for how to keep the prefix cache-friendly.
When to pick Muse Spark 1.3
- Good fit: questions where a careful, checked answer matters more than speed; agents that call tools; long-context reading at a moderate price.
- Less ideal: very short, high-volume calls where every output token counts, and anything that needs image input. A fast non-reasoning model is cheaper there; see the cheapest LLM APIs for high volume.
Stream responses so users do not stare at a blank screen
Since the model reasons before it writes, a non-streamed request returns nothing until the whole answer is ready. For chat interfaces, stream it. Nothing is shown while the model thinks, but as soon as the answer starts, tokens arrive one by one, and your client knows the connection is alive:
stream = client.chat.completions.create(
model="muse-spark-1.3",
messages=[{"role": "user", "content": "Plan a three-step database migration with rollback."}],
max_tokens=16000,
stream=True,
stream_options={"include_usage": True},
)
for chunk in stream:
if chunk.choices and chunk.choices[0].delta.content:
print(chunk.choices[0].delta.content, end="", flush=True)
if chunk.usage:
print("\n", chunk.usage)
Keep include_usage on: the last chunk then carries the token counts, including reasoning, which is what you are billed for.
Common mistakes
- Reusing limits from a non-reasoning model. A
max_tokensof 256 or 512 that worked for a chat model will produce empty answers here. - Estimating cost from the visible text. Our two test requests showed reasoning at 70 to 96% of output tokens. Log
usage, not character counts. - Sending images. The model is text-only; strip image parts or route those requests to a vision model.
- Treating every request the same. Use
loworminimaleffort for simple lookups and reserve higher levels for planning and analysis.
FAQ
Why does Muse Spark 1.3 return an empty response?
Almost always because max_tokens is too low. The model spends its budget on hidden reasoning and stops with finish_reason: "length" before writing the answer. Raise the limit to 4,000 or more for short tasks and 8,000 to 16,000 for complex ones.
What is the model ID?
muse-spark-1.3, sent to https://getvibeapi.com/v1/chat/completions.
How much does it cost?
From $0.8875 input · $3.0175 output per 1M tokens. Reasoning tokens are billed as output, so look at usage.completion_tokens, not at the length of the visible reply.
Does Muse Spark 1.3 accept images?
No, input is text only. For screenshots and diagrams use a vision model such as Gemini 4 Argon.
Can I see the reasoning?
The reasoning itself is not returned; you get its token count in usage.completion_tokens_details.reasoning_tokens, which is enough to monitor cost.
