Summary
The 2026-10-01 announcement lists "Muse Spark 1.3 Max (new max reasoning effort for harder problems)", but the max tier appears to be missing on the contributor SKU.
GET https://api.commandcode.ai/provider/v1/models returns 85 ids with no separate -max SKU — the muse routes are exactly:
meta/muse-spark-1.1
meta/muse-spark-1.2
meta/muse-spark-1.2-contributor
meta/muse-spark-1.3
meta/muse-spark-1.3-contributor
So "1.3 Max" is a reasoning tier on 1.3 rather than a distinct model id.
What works
On meta/muse-spark-1.3 the max tier is reachable end to end: an effort of max is accepted, the request is sent, and the response is recorded as "thinkingLevel":"max".
What does not
On meta/muse-spark-1.3-contributor, the same request is silently clamped to xhigh. The turn completes, the answer is correct, and the recorded thinking level is xhigh with no warning or diagnostic anywhere in the response or stream. A caller that explicitly selects max has no way to notice they are running a lower tier.
Reproduction
Using the coding agent (omp) against the Command Code provider:
- Select
meta/muse-spark-1.3-contributor
- Explicitly request the
max effort
- Observe the request completes, and the session transcript records
thinkingLevel: xhigh rather than max
The same sequence on meta/muse-spark-1.3 records thinkingLevel: max.
Expected behavior
Either:
max is accepted on meta/muse-spark-1.3-contributor as it is on meta/muse-spark-1.3, or
- the route explicitly rejects
max (e.g. a 4xx naming the supported efforts), rather than accepting it and quietly downgrading
The silent clamp is the part worth fixing regardless of which of the two applies. It burns a request that the caller believes ran at max.
Related
Environment
- Observed 2026-10-01
- Provider: Command Code,
https://api.commandcode.ai/provider/v1
- Client:
omp 18.4.8
- Catalog as served at that time:
meta/muse-spark-1.3 advertises max; meta/muse-spark-1.3-contributor does not
Summary
The 2026-10-01 announcement lists "Muse Spark 1.3 Max (new max reasoning effort for harder problems)", but the
maxtier appears to be missing on the contributor SKU.GET https://api.commandcode.ai/provider/v1/modelsreturns 85 ids with no separate-maxSKU — the muse routes are exactly:So "1.3 Max" is a reasoning tier on 1.3 rather than a distinct model id.
What works
On
meta/muse-spark-1.3themaxtier is reachable end to end: an effort ofmaxis accepted, the request is sent, and the response is recorded as"thinkingLevel":"max".What does not
On
meta/muse-spark-1.3-contributor, the same request is silently clamped toxhigh. The turn completes, the answer is correct, and the recorded thinking level isxhighwith no warning or diagnostic anywhere in the response or stream. A caller that explicitly selectsmaxhas no way to notice they are running a lower tier.Reproduction
Using the coding agent (
omp) against the Command Code provider:meta/muse-spark-1.3-contributormaxeffortthinkingLevel: xhighrather thanmaxThe same sequence on
meta/muse-spark-1.3recordsthinkingLevel: max.Expected behavior
Either:
maxis accepted onmeta/muse-spark-1.3-contributoras it is onmeta/muse-spark-1.3, ormax(e.g. a 4xx naming the supported efforts), rather than accepting it and quietly downgradingThe silent clamp is the part worth fixing regardless of which of the two applies. It burns a request that the caller believes ran at
max.Related
muse-spark-1.3-contributor; those appear unrelated to reasoning effort, and this report is against a credential where the route otherwise responds.Environment
https://api.commandcode.ai/provider/v1omp18.4.8meta/muse-spark-1.3advertisesmax;meta/muse-spark-1.3-contributordoes not