mathias/hyperguild
1
0
Fork 0
Code Issues 30 Pull Requests 3 Actions Packages Projects Releases Wiki Activity

Routing pod: HYPERGUILD_CLAUDE_MODEL is a dead env key — thinking tier runs on default (offline iguana/gemma4-26b) #72

New Issue
Closed
opened 2026-06-29 19:52:57 +00:00 by mathias · 1 comment
mathias commented 2026-06-29 19:52:57 +00:00
Owner
Copy Link
Copy Source

Found while promoting qwen36 (#35, 2026-06-29)

The routing pod manifest (infra k3s/apps/routing/deployment.yaml) sets:

- 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

## 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`
mathias commented 2026-07-26 21:39:10 +00:00
Author
Owner
Copy Link
Copy Source

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.
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
agent/ready
Meets the agent-ready contract; authorizes unattended execution
 blocked/client
Waiting on the client
 blocked/supplier
Waiting on a supplier
 blocked/upstream
Waiting on an upstream project or vendor
 risk/high
Irreversible, security-relevant, or control plane
 risk/low
Reversible, local, test-covered
 risk/medium
Touches shared state, deploys or data
 size/l
Too big - split it
 size/m
Under two days
 size/s
Under half a day
 size/xs
Under an hour
 status:dispatch
status:dispatched
status:review
status:reviewing
type/chore
Maintenance, no behaviour change
 type/decision
Human decision required; never agent/ready
 type/docs
Documentation only
 type/feat
New capability
 type/fix
Corrects broken behaviour
 type/ops
Infrastructure, deploy, runtime
 type/research
Investigate; output is a finding, not code
 type/test
Test coverage only
No labels
Milestone
No items
No Milestone
Projects
Clear projects
No projects
Assignees
Clear assignees
renovate-bot mathias
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: mathias/hyperguild#72