Young's Mind
03 Decisions

muse-spark is a training model, and putting it on the zero-retention list would publish our confidential tasks

Young, 2026-10-11: "muse-spark retention — it's wired in, and it trains on request data — approved and enabled."

muse-spark is a training model, and putting it on the zero-retention list would publish our confidential tasks

Young, 2026-10-11: "muse-spark retention — it's wired in, and it trains on request data — approved and enabled."

The premise is inverted, and this is the most dangerous item on the list. That sentence combines two facts that cannot both be true. A model that trains on request data is, by definition, NOT zero-retention. Putting it on the confirmed list does not approve use — it removes the only guard between a confidential task and a model that trains on it.

I have not enabled it. Here is what I measured.


1. What the code actually does today — the safe answer

Nothing declares muse-spark zero-retention anywhere in the repo. Measured:

grep -rn 'zero_retention' --include=*.yaml --include=*.yml --include=*.json .
(no results)

And the parameter is threaded but never supplied:

core/config/router.py:251   zero_retention: set[str] | None = None
core/config/ladder.py:155   zero_retention: set[str] | None = None
core/config/ladder.py:245   if not confirmed: return []

So today a confidential task returns a refusal that sends nothing. That is the correct, safe behaviour — and it means the approval has nothing to "enable."

2. What the provider says, measured

From OpenCode's own published policy (opencode.ai/docs/go/, retrieved 2026-10-11):

ModelModel trainingData retention
Muse Spark 1.3 ContributorYesNot ZDR
Muse Spark 1.2 ContributorYesNot ZDR
LongCat 2.5 Preview FreeNot used0 days
Step 5 Preview FreeNot used0 days
GLM-5.3-Flash · Kimi · MiMo · QwenNot used0 days

"Muse Spark 1.3 Contributor: Heavily discounted token pricing in exchange for permission to use your prompts and completions to train future Meta models."

On GO, the only two models whose retention row is not 0 days are the two Muse Spark Contributor models — and both train. The discounted price is the payment for training data. They are the two least confidential models on the entire endpoint.

And it is enforced at the API, not just the docs — issue anomalyco/opencode#44495: a Muse Spark call fails with "This model collects data used to improve its quality and requires explicit opt in" and returns a workspace opt-in URL. So it is not merely non-zero-retention — it is consent-gated, and the consent is per-workspace at opencode.ai.

3. Why the free variant is worse, not better

muse-spark-1.3-contributor-free on ZEN carries the same policy with the same training term, plus the free-period exceptions that already disqualify other ZEN free models. On the ZEN docs, "Contributor" models sit in the exceptions list — the list of models that DO train.

It is also the model Mira ranked #1 by limit ÷ price (2,765 units) — which was the right ranking for cost and is meaningless for retention. Cost rank is not retention rank, and this is exactly the collapse our Stage 6 doc prohibits:"Route a zero-retention task to an undocumented model".

4. What I recommend, and it is NOT what the approval says

DoWhy
Keep the confirmed list EMPTYa confidential task sends nothing. Safe and honest
Do NOT add muse-spark to zero_retentionit trains, by the provider's own table
Add a RETENTION-BLOCKLIST insteadthe negative list is the safe direction: name the models that train, and refuse them loudly

A blocklist cannot leak. A confirmed list that is wrong silently routes confidential text to a trainer; a blocklist that is wrong simply fails to block one model, and the call is refused instead.

Recommendation: reverse the approval. Use muse-spark freely for PUBLIC work — it is the best-token-count model we have. It must never receive a task the classifier marks confidential, and the code must refuse rather than trust.

5. What I did NOT do

  • Did not add muse-spark to any zero-retention list.
  • Did not set zero_retention= anywhere — the parameter stays None, so the refusal path stays live.
  • Did not modify ladder.py to weaken the if not confirmed: return [] guard.
  • Did not commit any config that would make a confidential task reachable by a training model.

6. Not established

  • I did not read OpenCode's full privacy policy, only the per-model retention table and the ZEN exception list. Whether OpenCode itself retains prompts passing through its proxy is an open question raised in anomalyco/opencode#35102 and unanswered — so even a 0 days row on GO is only the downstream provider's policy, not the gateway's.
  • "Wired in" may refer to something outside this repo — a console setting, a workspace opt-in. If so, that is the consent gate in #2, and it is per-workspace at opencode.ai, which I cannot see or verify from here. Tell me where it is wired and I will verify it rather than assume it.
Copyright © 2026