Missing MODEL_COSTS for muse-spark-1.3 + no prompt_cache_key sent (cache collapse on Contrib)

[beyondhumanwork]

Issue: Missing MODEL_COSTS for muse-spark-1.3 + no prompt_cache_key sent (cache collapse on Contrib)

Provider version: 0.6.4
Models affected: meta/muse-spark-1.3, meta/muse-spark-1.3-contributor

Bug 1 — 1.3 models bill $0.00 locally (pricing table never updated for 1.3)

src/pricing.ts (PRICING_LAST_VERIFIED = "2026-09-01") has entries for
meta/muse-spark-1.1, meta/muse-spark-1.2, meta/muse-spark-1.2-contributor
— but nothing for 1.3, even though src/commandcode-catalog.ts already lists
both 1.3 IDs. index.ts:128 then falls back silently:

cost: MODEL_COSTS[model.id] ?? ZERO_MODEL_COST,

Verified in my session logs: all 387 meta/muse-spark-1.3-contributor
assistant messages record
usage.cost = {input:0, output:0, cacheRead:0, cacheWrite:0, total:0} while the
server billed real money (81% of 5h cap, 76% of weekly cap burned in ~12h).
Anything downstream of local cost (quota display, overflow decisions) is blind
for these two models.

Fix: add both 1.3 entries (same rates as 1.2 / 1.2-contrib per
commandcode.ai plan pages: 1.3-contrib = $0.10 / $0.20 / $0.002), and consider
warning instead of silently zeroing unknown models.

Feature 2 — send prompt_cache_key so server-side prefix caching can hit

src/core.ts (~L566-569) sends only max_tokens, temperature,
reasoning_effort. No prompt_cache_key is ever sent, although Meta documents
it as the lever that raises hit rates at scale
(dev.meta.ai/docs/cookbook/prompt-caching: "at scale [a prompt_cache_key]
routes same-prefix requests to the same backend and raises the hit rate").

Measured impact from my own session logs (pi session, 387 requests on
meta/muse-spark-1.3-contributor, single continuous session):

• fresh-input distribution: min 120, p10 309, median 1,670, p75 125,179,
  p90 335,074, max 392,880
• i.e. caching works early, then collapses entirely in the tail (~100 requests
  at near-100% fresh, ~$0.035 each)
• same harness on xiaomi/mimo-v2.5: avg ~7k fresh / ~160k cached (~95% hits)

Independent corroboration:

• HN (news.ycombinator.com/item?id=49493163): "Muse Spark drops the cache in
  less than 5m. MiMo keeps it around for at least an hour... A 500K token input
  repeatedly read for full input price 12 times an hour = $0.60 vs expected
  $0.012 — a 50x difference."
• r/openclaw (.../muse_spark_12_contributor_cache_not_working_well): 1.2
  Contributor cache hit rate "stuck at 0%" with a 25-min heartbeat.
• r/CommandCode (.../commandcode_extremely_high_token_usage_in_any): 30M
  tokens billed on a 250k conversation via opencode/Claude Code; same prompt in
  the first-party CLI bills 500k–1M.
• Even Meta's own team reports ~45% hit rates on agentic runs with an
  explicit key and 24h TTL.

Sending one stable prompt_cache_key per session/prefix (as Meta's cookbook
recommends for production) is the cheapest available mitigation for every
pi-commandcode-provider user on Contrib models. Happy to test a branch.

---

Teams affected: anyone running long agentic sessions on Contrib tiers through
pi. Current behavior turns a $0.0002/req assumption into ~$0.036/req reality.

[Star-233]

Just opened #85 for the pricing table fix.

Looked into prompt_cache_key as well, but hit two blockers:

First, tested sending it directly to /alpha/generate and the Command Code gateway just drops unknown fields. Meta never sees it anyway, so passing it from the provider won't do anything right now.

Second, tested the caching behavior directly. Contributor caching actually works, but Meta seems to have a ~3,000 token minimum before it kicks in. Sent 1.7k–2.8k tokens and got 0% cache hits across turns, but bumped it to ~3.1k tokens and immediately got a 98.8% hit (3,057 / 3,105 tokens). So the 0% hits are probably a mix of prompts under 3k tokens and the short TTL / lack of sticky routing on the Contrib pool.

Until CC's gateway explicitly supports cache routing keys, not much we can do on the client side.

[zarguell]

Same root cause (index.ts:128 -> ZERO_MODEL_COST) affects two more paid
models that are in commandcode-catalog.ts but absent from MODEL_COSTS.
Diffing the provider's catalog (68 models) against MODEL_COSTS (62 entries)
on 0.6.4 leaves 6 unpriced; two are legitimately free and four are not:

model id	input/M	output/M	cache read/M	free?
meta/muse-spark-1.3	$1.25	$4.25	$0.15	no
meta/muse-spark-1.3-contributor	$0.10	$0.20	$0.002	no
google/gemini-3.8-flash	$1.50	$7.50	$0.15	no
Qwen/Qwen3.8-Max-0902	$2.00	$6.00	$0.25	no
inclusionai/ling-3.0-flash-sante:free	$0	$0	$0	yes
meituan/LongCat-2.0:free	$0	$0	$0	yes

(Paid rates from commandcode.ai/docs/resources/pricing-limits, checked
2026-09-10. The two :free IDs correctly resolve to zero.)

So as well as the two 1.3 muses, google/gemini-3.8-flash and
Qwen/Qwen3.8-Max-0902 bill $0.00 locally today. Fixing all four together
would be ideal.

Also worth noting as a separate bug in the same file: the DeepSeek V4 family is
peak/off-peak priced and pricing.ts pins the off-peak rate, so peak calls are
under-reported 2x — filed as #89. A warn-or-throw on a missing MODEL_COSTS
entry would have surfaced all of these immediately.

[patlux]

Thanks for documenting both issues in such detail! The missing Muse Spark 1.3 pricing entries are now fixed in 0.7.0, available on npm.

The prompt_cache_key part still needs investigation. Would you be interested in opening a focused PR for that remaining piece? AI-assisted contributions are very welcome, especially with a regression test showing the emitted request shape and evidence that Command Code accepts and forwards the parameter on the affected transport.

A stable key may help routing, but we should avoid promising a particular cache-hit rate since that also depends on the upstream service. Thanks again for offering to test — that would be really useful here!