[maxmad64bis]

Summary

Turn on freeAccessPolicy: "strict" and the read-only candidate listing starts hiding things. A model the zero-cost guard excludes doesn't show up as excluded — it's gone, and the operator can't tell "no free allowance left" from "the quota fetcher is broken".

That listing exists to be honest about the pool; its module header says a candidate the routing path would skip "is never dropped from this listing". #9133 settled the same question for the resilience filter, via a skip opt-out. The zero-cost guard never got it.

So it gets it. The guard is disabled for the inspector build, exactly as the resilience filter already is, and every candidate carries freeAccessExclusion — null when the guard is satisfied, otherwise one of:

Reason	Means
not-in-catalog	absent from FREE_MODEL_BUDGETS
regime-not-free	catalogued, but the tier doesn't grant free access
no-hard-stop	free tier, but exceeding it might silently bill
contradictory-noauth	a no-auth candidate whose entry isn't keyless
exhausted	a fresh reading says the allowance is used up
state-unknown	no quota reading, or one too old to trust
no-connection	no account to check at all

The last three are the point. An exhausted allowance fixes itself, a reading that never arrives means the fetcher is broken, and a candidate with no account was never going to be checked. All three used to look identical, because the row just disappeared. STRICT_ZERO_COST.md spells out what each one asks an operator to do.

Dispatch is untouched. The guard still applies to the routing pool, and a test pins that. What changed is which build skips it.

Under the hood the boolean deciding one connection's fate became a classification, and evaluateCandidateConnections is now a thin wrapper returning the same string[] it always did. The three existing guard suites weren't modified — they're the net, and their 31 cases still pass.

One order change: freshness is now checked before status, so a stale EXHAUSTED reading reports state-unknown. Same exclusion either way; the reason is just honest about what we know.

excludeTosAvoid still drops its candidates without a reason. Same hole, different guard — what a ToS exclusion should report is a separate question, so it's documented rather than closed.

Related Issues

• Related to fix(providers): Only part of auto/* pool candidates were returned #9133
• Related to feat(routing): per-candidate control + policy selection UI for auto/* channels #7819

Validation

• Change type: routing
• Focused tests and category gates from the golden path
• npm run lint
• Reconciled with the current active release base; focused checks rerun afterward
• Production-code changes include a new or updated automated test in this PR

Red first: drop && !skip and the listing test fails — the excluded candidates vanish again. Restore it and 27 cases pass across the new files, the #9133 locked-model test and the #7819 route test. The three pre-existing guard suites (under vitest.mcp.config.ts) stay green at 31, unmodified.

npm run lint exits 2 here and on an untouched checkout of the base alike (suppressions left that do not occur anymore, zero reported errors).

Tests Added Or Updated

• tests/unit/strict-zero-cost-exclusion-reason.test.ts (new: the classification, plus the contract the pool filter depends on)
• tests/unit/auto-combo-candidates-free-access-reason.test.ts (new: dispatch untouched, the listing keeps excluded candidates with a reason, policy-off stays free)

Coverage Notes

strictZeroCostFilter.ts gains two exported functions and loses a private helper; both are covered directly, and the old public entry point keeps its contract under the tests it already had. virtualFactory.ts gains the skip term and an annotation pass that only runs for the inspector. autoComboCandidates.ts copies a field, the job it already does for the breaker, the cooldown and the model lock.

Reviewer Notes

• The annotation lives in buildPreparedPool, not the handler: the handler has no access to settings, so doing it there would duplicate two thresholds with nothing keeping them in agreement.
• For a multi-account candidate, exhausted beats state-unknown — an observed exhaustion is a fact, a missing reading is the absence of one. Without a rule the reason would depend on connection ordering.
• With the policy off nothing is classified and the field is null.
• resolveFreeAccessState is called on the same candidates the guard used to call it on, so the inspector's quota-lookup load is unchanged.