Claude Code: model-catalog drift detection via ~/.claude.json caches (spike) #157

New issue

Open

opened 2026-07-13 14:22:33 +02:00 by dominik.polakovics · 0 comments

dominik.polakovics commented

2026-07-13 14:22:33 +02:00

Owner

Problem

The claude-code model catalog is pinned as family aliases in internal/provider/claudecode/claudecode.go (opus[1m], sonnet, fable, haiku). Unlike codex (#156), the claude binary has no machine-readable model listing — no models subcommand, nothing in --help, and the /model picker is TUI-only. Verified on 2.1.206 (2026-07-13). So the catalog can silently drift from what the binary actually offers.

Decision (grill 2026-07-13, split from #156)

Claude-code stays pinned; TUI picker scraping for catalog data was rejected (login-dependent, slow, fragile-recipe budget already spent on dialog driving — compat §7). Instead: drift detection, warning a human to re-pin.

Candidate signal (needs verification — this is why it's a spike): ~/.claude.json contains undocumented cache fields written by the binary after phoning home:

additionalModelOptionsCache — observed populated with exactly our {value,label,description} option shape (e.g. claude-fable-5[1m]).
modelAccessCache — observed empty on the lab box; population conditions unknown.

Spike questions

When does the binary write/refresh these caches? (Interactive session required? Logged-out behavior? Staleness?)
Are the values stable enough to diff against our pinned family aliases (alias vs pinned-id mismatch: cache had claude-fable-5[1m], our catalog has fable)?
Where does the warning surface — boot-time log like the codex fallback warning, doctor-style check, or provider status?
Compat note: these are undocumented internals; pin observed shapes + version in internal/compat/claude/.

Out of scope

Any dynamic catalog for claude-code; the pinned list stays the source of truth.
The per-model-efforts seam adaptation (done in #156).

## Problem The claude-code model catalog is pinned as family aliases in `internal/provider/claudecode/claudecode.go` (`opus[1m]`, `sonnet`, `fable`, `haiku`). Unlike codex (#156), the claude binary has **no machine-readable model listing** — no `models` subcommand, nothing in `--help`, and the `/model` picker is TUI-only. Verified on 2.1.206 (2026-07-13). So the catalog can silently drift from what the binary actually offers. ## Decision (grill 2026-07-13, split from #156) Claude-code stays pinned; TUI picker scraping for catalog data was **rejected** (login-dependent, slow, fragile-recipe budget already spent on dialog driving — compat §7). Instead: **drift detection**, warning a human to re-pin. Candidate signal (needs verification — this is why it's a spike): `~/.claude.json` contains undocumented cache fields written by the binary after phoning home: - `additionalModelOptionsCache` — observed populated with exactly our `{value,label,description}` option shape (e.g. `claude-fable-5[1m]`). - `modelAccessCache` — observed empty on the lab box; population conditions unknown. ## Spike questions - When does the binary write/refresh these caches? (Interactive session required? Logged-out behavior? Staleness?) - Are the values stable enough to diff against our pinned family aliases (alias vs pinned-id mismatch: cache had `claude-fable-5[1m]`, our catalog has `fable`)? - Where does the warning surface — boot-time log like the codex fallback warning, doctor-style check, or provider status? - Compat note: these are undocumented internals; pin observed shapes + version in `internal/compat/claude/`. ## Out of scope - Any dynamic catalog for claude-code; the pinned list stays the source of truth. - The per-model-efforts seam adaptation (done in #156).

dominik.polakovics added the

needs-triage

label

2026-07-13 14:22:33 +02:00

dominik.polakovics referenced this issue

2026-07-13 15:13:30 +02:00

feat: codex dynamic model catalog from codex debug models + per-model efforts seam #158