But internal/config/routing.go (since commit 5b20742, "rename local/claude to fast/thinking model pair") reads HYPERGUILD_THINKING_MODEL, default iguana/gemma4-26b. So HYPERGUILD_CLAUDE_MODEL is a dead key — the pod ignores it and runs the thinking tier on the default.
This is the same drift class as the fast-model key, which was fixed in infra c66a195 (HYPERGUILD_LOCAL_MODEL → HYPERGUILD_FAST_MODEL). The fast key was caught and corrected; this sibling was left as a separate ticket to keep that commit surgical.
Why it matters
The intended thinking model (claude-sonnet-4-6) is not what's running. The default iguana/gemma4-26b is in play, and per the brain, iguana has been offline — so the thinking/Claude route may be silently broken or erroring, not falling back to Sonnet as the manifest implies.
Fix
Decide the intended thinking tier, then in infrak3s/apps/routing/deployment.yaml:
Rename HYPERGUILD_CLAUDE_MODEL → HYPERGUILD_THINKING_MODEL, value = the intended model (claude-sonnet-4-6 if that's the call), commit to main, flux reconcile.
Prevention
Manifest env keys silently drift from code after a rename with zero error signal — the pod just uses defaults. Worth a CI check that asserts every HYPERGUILD_* key in the deployment manifest is actually read by config/routing.go.
## Found while promoting qwen36 (#35, 2026-06-29)
The routing pod manifest (`infra` `k3s/apps/routing/deployment.yaml`) sets:
```yaml
- name: HYPERGUILD_CLAUDE_MODEL
value: "claude-sonnet-4-6"
```
But `internal/config/routing.go` (since commit `5b20742`, "rename local/claude to fast/thinking model pair") reads **`HYPERGUILD_THINKING_MODEL`**, default **`iguana/gemma4-26b`**. So `HYPERGUILD_CLAUDE_MODEL` is a dead key — the pod ignores it and runs the thinking tier on the default.
This is the same drift class as the fast-model key, which was fixed in infra `c66a195` (`HYPERGUILD_LOCAL_MODEL` → `HYPERGUILD_FAST_MODEL`). The fast key was caught and corrected; this sibling was left as a separate ticket to keep that commit surgical.
### Why it matters
- The intended thinking model (`claude-sonnet-4-6`) is **not** what's running. The default `iguana/gemma4-26b` is in play, and per the brain, **iguana has been offline** — so the thinking/Claude route may be silently broken or erroring, not falling back to Sonnet as the manifest implies.
### Fix
Decide the intended thinking tier, then in `infra` `k3s/apps/routing/deployment.yaml`:
- Rename `HYPERGUILD_CLAUDE_MODEL` → `HYPERGUILD_THINKING_MODEL`, value = the intended model (`claude-sonnet-4-6` if that's the call), commit to main, flux reconcile.
### Prevention
Manifest env keys silently drift from code after a rename with zero error signal — the pod just uses defaults. Worth a CI check that asserts every `HYPERGUILD_*` key in the deployment manifest is actually read by `config/routing.go`.
Refs: #35, infra `c66a195`
Stale — superseded by #75/#76 (merged 0785f14, "Consolidate to single harness: icebox cmd/routing"). cmd/routing and its k3s deployment (k3s/apps/routing/deployment.yaml) were deleted entirely; Dockerfile.routing removed; cd.yml no longer builds a routing image. Checked ~/dev/AI/infra: no routing app dir exists anymore, and no HYPERGUILD_* env vars appear in any live k3s manifest (only ingestion-deployment.yaml exists under k3s/apps/supervisor/, unrelated env keys).
cmd/hyperguild (the CLI harness, kept post-consolidation) still reads HYPERGUILD_THINKING_MODEL (internal/config/routing.go) — but it isn't deployed as a k8s pod, so there's no manifest env key to rename. If the thinking-tier model still needs pinning wherever cmd/hyperguild actually runs (host shell env, systemd unit, etc.), that's a different, currently-unfiled concern — I didn't find a repo-tracked place to fix it.
One related paper cut found while checking: infra/tools/homelab-map/internal/parse/routing.go + internal/model/model.go still parse/model a field named ClaudeModel (HYPERGUILD_CLAUDE_MODEL) rather than ThinkingModel (HYPERGUILD_THINKING_MODEL) — same naming drift, in a doc-generation tool, filed separately since it's unrelated to this issue's original (now-removed) manifest. Closing this one as stale.
Stale — superseded by #75/#76 (merged 0785f14, "Consolidate to single harness: icebox cmd/routing"). `cmd/routing` and its k3s deployment (`k3s/apps/routing/deployment.yaml`) were deleted entirely; `Dockerfile.routing` removed; `cd.yml` no longer builds a routing image. Checked `~/dev/AI/infra`: no `routing` app dir exists anymore, and no `HYPERGUILD_*` env vars appear in any live k3s manifest (only `ingestion-deployment.yaml` exists under `k3s/apps/supervisor/`, unrelated env keys).
`cmd/hyperguild` (the CLI harness, kept post-consolidation) still reads `HYPERGUILD_THINKING_MODEL` (`internal/config/routing.go`) — but it isn't deployed as a k8s pod, so there's no manifest env key to rename. If the thinking-tier model still needs pinning wherever `cmd/hyperguild` actually runs (host shell env, systemd unit, etc.), that's a different, currently-unfiled concern — I didn't find a repo-tracked place to fix it.
One related paper cut found while checking: `infra/tools/homelab-map/internal/parse/routing.go` + `internal/model/model.go` still parse/model a field named `ClaudeModel` (`HYPERGUILD_CLAUDE_MODEL`) rather than `ThinkingModel` (`HYPERGUILD_THINKING_MODEL`) — same naming drift, in a doc-generation tool, filed separately since it's unrelated to this issue's original (now-removed) manifest. Closing this one as stale.
Blocking a user prevents them from interacting with repositories, such as opening or commenting on pull requests or issues. Learn more about blocking a user.
Found while promoting qwen36 (#35, 2026-06-29)
The routing pod manifest (
infrak3s/apps/routing/deployment.yaml) sets:But
internal/config/routing.go(since commit5b20742, "rename local/claude to fast/thinking model pair") readsHYPERGUILD_THINKING_MODEL, defaultiguana/gemma4-26b. SoHYPERGUILD_CLAUDE_MODELis a dead key — the pod ignores it and runs the thinking tier on the default.This is the same drift class as the fast-model key, which was fixed in infra
c66a195(HYPERGUILD_LOCAL_MODEL→HYPERGUILD_FAST_MODEL). The fast key was caught and corrected; this sibling was left as a separate ticket to keep that commit surgical.Why it matters
claude-sonnet-4-6) is not what's running. The defaultiguana/gemma4-26bis in play, and per the brain, iguana has been offline — so the thinking/Claude route may be silently broken or erroring, not falling back to Sonnet as the manifest implies.Fix
Decide the intended thinking tier, then in
infrak3s/apps/routing/deployment.yaml:HYPERGUILD_CLAUDE_MODEL→HYPERGUILD_THINKING_MODEL, value = the intended model (claude-sonnet-4-6if that's the call), commit to main, flux reconcile.Prevention
Manifest env keys silently drift from code after a rename with zero error signal — the pod just uses defaults. Worth a CI check that asserts every
HYPERGUILD_*key in the deployment manifest is actually read byconfig/routing.go.Refs: #35, infra
c66a195Stale — superseded by #75/#76 (merged
0785f14, "Consolidate to single harness: icebox cmd/routing").cmd/routingand its k3s deployment (k3s/apps/routing/deployment.yaml) were deleted entirely;Dockerfile.routingremoved;cd.ymlno longer builds a routing image. Checked~/dev/AI/infra: noroutingapp dir exists anymore, and noHYPERGUILD_*env vars appear in any live k3s manifest (onlyingestion-deployment.yamlexists underk3s/apps/supervisor/, unrelated env keys).cmd/hyperguild(the CLI harness, kept post-consolidation) still readsHYPERGUILD_THINKING_MODEL(internal/config/routing.go) — but it isn't deployed as a k8s pod, so there's no manifest env key to rename. If the thinking-tier model still needs pinning wherevercmd/hyperguildactually runs (host shell env, systemd unit, etc.), that's a different, currently-unfiled concern — I didn't find a repo-tracked place to fix it.One related paper cut found while checking:
infra/tools/homelab-map/internal/parse/routing.go+internal/model/model.gostill parse/model a field namedClaudeModel(HYPERGUILD_CLAUDE_MODEL) rather thanThinkingModel(HYPERGUILD_THINKING_MODEL) — same naming drift, in a doc-generation tool, filed separately since it's unrelated to this issue's original (now-removed) manifest. Closing this one as stale.