Follow-up from the Router Core extraction review. Not a bug today — everything below resolves correctly right now. It is a note about how much slower recovery got.
The dependency
Several load-bearing routing targets are hidden: true in blockrun's catalog — deliberately excluded from /v1/models, but still available: true and therefore callable by direct ID:
| Target |
Where it is load-bearing |
nvidia/gpt-oss-120b |
ultimate free backstop, both AGENTIC tiers (config.ts, set by 6a790eb) |
nvidia/gpt-oss-20b |
head of the free coder fallback chain |
nvidia/qwen3-next-80b-a3b-instruct |
Franklin free-profile default |
moonshot/kimi-k2.5 / k2.6 / k2.7 |
Franklin VISION_MODELS (re-added in Franklin#122) |
They work only because available: true. The catalog hides them for a real reason — NVIDIA's free tier reserves the right to use prompts for service improvement — so the flag they depend on is one that gets revisited.
This exact class already caused breakage before: hidden: true strips a model from /v1/models and silently breaks router primaries targeting it.
What the extraction changed
Before, retargeting a dead free model was one commit in ClawRouter. Now the chains live here, pinned by immutable commit SHA in two consumers:
router-core commit → repin ClawRouter → release → repin Franklin → release
6a790eb ("retire unavailable seed fallback") is that path being walked for real, and seed-oss-36b had already been retargeted once before that. This is not a rare event.
Worth considering
- A host-supplied override for fallback chains, so a consumer can retarget a dead rung without waiting on a core release (capabilities and pricing are already injected this way).
- Or: treat a
hidden: true model as ineligible for an ultimate backstop slot specifically, since that rung is the one with nothing behind it.
- At minimum, document that chain entries must be
available: true regardless of catalog visibility, so the invariant is explicit rather than discovered.
Filed against core because that is where the chains now live; the consumer-side follow-up is the repin cadence, not a code change.
Follow-up from the Router Core extraction review. Not a bug today — everything below resolves correctly right now. It is a note about how much slower recovery got.
The dependency
Several load-bearing routing targets are
hidden: truein blockrun's catalog — deliberately excluded from/v1/models, but stillavailable: trueand therefore callable by direct ID:nvidia/gpt-oss-120bconfig.ts, set by 6a790eb)nvidia/gpt-oss-20bnvidia/qwen3-next-80b-a3b-instructmoonshot/kimi-k2.5/k2.6/k2.7VISION_MODELS(re-added in Franklin#122)They work only because
available: true. The catalog hides them for a real reason — NVIDIA's free tier reserves the right to use prompts for service improvement — so the flag they depend on is one that gets revisited.This exact class already caused breakage before:
hidden: truestrips a model from/v1/modelsand silently breaks router primaries targeting it.What the extraction changed
Before, retargeting a dead free model was one commit in ClawRouter. Now the chains live here, pinned by immutable commit SHA in two consumers:
6a790eb("retire unavailable seed fallback") is that path being walked for real, andseed-oss-36bhad already been retargeted once before that. This is not a rare event.Worth considering
hidden: truemodel as ineligible for an ultimate backstop slot specifically, since that rung is the one with nothing behind it.available: trueregardless of catalog visibility, so the invariant is explicit rather than discovered.Filed against core because that is where the chains now live; the consumer-side follow-up is the repin cadence, not a code change.