V3 — cost and provider policy

Read first: young-corrections-2026-10-10.md §1 (Min) and sol-corrections-and-lane-division.md §1 (Sol) both record the one-workspace correction. I am not restating it. This file holds the part of my lane that neither of them covered, because neither of us is the finance owner:

what a $60 allowance cap and a $40 PAYG float do differently to behaviour.

Young, 2026-10-10:

"Correction we only have 1 workspace / SolOS — GO $10 / allowance cap $60 credit on model usage — ZEN $40/mth pay as you go credit."

1. The one thing the correction changes that neither doc has

Min's §1 and Sol's §1 both note that GO is a subscription with an allowance cap and ZEN is pay-as-you-go. Both stop at "the ledger must record which pool a call drew on." That is necessary but not sufficient — the two instruments do not just need different labels, they need different behaviour, and the difference is invisible in a ledger that only records amounts.

A bundled allowance rewards use-within-cap. A PAYG float punishes use. Same arithmetic, opposite meaning.

This is why billing_instrument is not a label. If the ledger records only dollars, a call that draws GO-allowance and a call that draws ZEN-float look identical and are priced the same. They are not: one is consuming something already bought, the other is spending cash.

Behavioural consequence, and it is a rule rather than a preference: free-first is unchanged and already settled. But tier 2 must default to GO, not ZEN — GO's cap is a resource we have already bought, while ZEN is money leaving the account. ZEN tier 2 is an escalation above GO tier 2, not a peer of it.

The ladder Young ruled — free first, then selected paid — holds exactly. This only orders the two paid instruments, which Young's line did not specify.

2. No fallback provider — stated plainly, because it is a resilience fact

Young ruled Opencode only. Under my earlier two-workspace reading I argued Zen free was "the only independent redundancy." That argument is now void and I am withdrawing it explicitly, because it is the kind of claim that survives in a doc after it stops being true.

There is one provider. GO and ZEN are two payment instruments inside it, not two operational estates. If Opencode degrades, switching GO→ZEN does not help — it just changes who we pay.

Consequence to record as accepted, not discovered: V3 has no provider-level fallback. That is a resilience decision wearing a cost decision's clothes, and it belongs on the record. The internal redundancy that does exist is per-model: V2's model-health circuit breaker quarantines a model that cannot answer, so the fleet survives a single model dying. That is the redundancy V3 has, and it is not provider redundancy.

3. The $60 cap against a $10 package — confirm before enforcing

A $10 package carrying a $60 allowance is credit worth 6× the subscription. That is commercially favourable enough that I want it confirmed rather than assumed, because the enforcement behaviour differs entirely:

I am not writing enforcement until this is answered. A guard built on the wrong one of those is worse than no guard: a hard-block guard on a soft ceiling halts the fleet unnecessarily, and a soft guard on a hard ceiling spends past the cap.

4. The ledger spec — what my lane owes

V2 recorded zero cost across 30,721 attempts. The $10/day was visible only because opencode stats exists as an external tool. A month could have passed. The ledger is not reporting — it is the instrument that makes every number in this design re-measurable.

Two rules that are not negotiable:

1. A tier-2 call without a why_paid value is a defect, not a blank.
2. cost_state: unknown must never be aggregated into a spend total. V2's 30,721 rows all read $0.00000 because an ImportError in bin/ was swallowed — an unknown that sums as free is a five-hour plausible-looking zero, and on a PAYG float it hides real cash leaving the account.

Result class closes a second V2 defect: a prose refusal sets no failure signal, so a task can read completed while nothing was produced.

Proof of done for this lane

1. grep -r for a key pattern in my directory returns nothing.
2. The ledger disaggregates refusal / empty / error from success.
3. A tier-2 choice cannot be recorded without a reason.
4. Window exhaustion is recorded as model-blocked, not as spend.
5. billing_instrument is always populated; unknown ≠ $0.00.
6. GO and ZEN are separately attributable — never one merged "spend" figure.

5. Free-first — what it rests on, unchanged by the correction

V2, one day, measured:

The free model did 9× the tokens for nothing. On a correctness-controlled test all four were right; the paid model's only justification was 4 seconds faster. 99% of that day's spend bought speed nobody needed.

Now on firmer ground than before: free sits outside both billing instruments entirely, so tier 1 is not merely cheaper — it is not billed at all. That strengthens Young's "free first" rule rather than merely permitting it.

6. Retention posture outranks cost — unchanged, and still mine

From SolOSV2/05-operations/free-model-reality-check.md:

Anything touching vault content, credentials, task text or the registry routes only to a zero-retention model, or to none at all.

A model that may train on our task text is not free. It is an undisclosed disclosure.

Today the cost ladder and the privacy ladder agree — the cheapest model is also the zero-retention one. The moment they disagree, this section wins. And on a workspace where ZEN is PAYG, a cheap-but-training model is doubly wrong.

7. "Free" is four states, not a boolean

The catalogue must be probed, not read. opencode models lists models that return Endpoint is unavailable. Availability is a measurement — and V2's catalogue was measured 2026-10-01, so it is stale by nine days and must be re-probed.

8. The registry gap — Min's lane, reported not fixed

cortex/registry/agents.yaml declares no model field. I read all 218 lines, 11 agents: id, name, plane, role, pronouns, host, port, endpoint, capabilities, boundaries — and no model anywhere. V2 held it in the personas (echo.md:13 → model: opencode-go/gpt-6-luna).

This is V3's defect class, currently live: the most expensive fact in the system — what each agent talks to, and now which payment instrument pays for it — has no home in the one registry. Worse, V2's persona files were generated from AGENT_IDENTITIES, so the model id silently vanishes in the projection.

Recommendation to Min: add model and billing_instrument to the registry, so the projection, my ladder, and Sol's router read one fact. I have not touched his file.

9. Still open, and mine

10. What I am not doing

• Writing providers.json or budget.json. They would restate facts the registry owns (§8). A second model list in my lane is V2's five-roster-sources defect, committed by the person whose job is to prevent it.
• Probing the catalogue. Every terminal call this session has failed on a stuck cwd (cd: /home/lab/.solos/config: No such file or directory), so opencode models never ran. No probe, no list.