Context bar shows 200k max for a 1M-context model — derive the max from the model, not a hardcoded default

[kiki830621]

Problem

The status-bar context bar shows a 200k maximum (0 / 200k) even when the running model is
Opus 4.8 with a 1M context window (Claude Code's header reads "Opus 4.8 (1M context)"). The
context-window maximum should be determined by the model's actual context window (i.e. from the
model's specs / "model cards"), not defaulted to 200k.

User: 「這個 model 明明就是 1M，你的顯示需要依照 model cards 來決定吧」

(Observed on Claude Code v2.1.207, model "Opus 4.8 (1M context)", fresh session → the HUD context
bar read 0 / 200k. Screenshot not attached — it also shows personal plan-usage figures and this is
a public repo; the load-bearing facts are quoted here instead.)

Current behavior (grounded)

ClaudeUsageReader.contextMax(forModel:observedTokens:)
(Sources/Logos/Services/ClaudeUsageReader.swift:48-51) ignores the model argument entirely:

static func contextMax(forModel model: String?, observedTokens: Int = 0) -> Int {
    if observedTokens > 200_000 { return 1_000_000 }
    return 200_000
}

So the max is 200k until the used count actually crosses 200k, at which point it jumps to 1M. A
1M-context session therefore under-reports its window as 200k for the entire first 200k of use (and
a fresh session always shows 200k). The existing doc comment (:44-48) states the original rationale:

"The model id alone — e.g. claude-opus-4-8 — does NOT encode the 1M-context beta, so a 1M session
reads 200k here until it actually crosses 200k…"

The catch (diagnosis hint)

That rationale may be stale. The actual model id for this session is claude-opus-4-8[1m] — the
[1m] suffix does encode the 1M-context variant. So if the session transcript's usage.model
field carries that suffix (to be verified in diagnosis), contextMax could parse it and return 1M
without waiting to cross 200k. The open question is exactly what string the transcript records
(claude-opus-4-8 vs claude-opus-4-8[1m] vs something else).

Direction

• Derive the context-window maximum from the model, via a model → context-window mapping ("model
  cards"): recognise the 1M-context models/variants (parse a [1m]/[1M] suffix, and/or a known-id
  table) and return 1M for them up front.
• Keep the observed-tokens heuristic (> 200k → 1M) only as a fallback for genuinely unknown /
  suffix-less model ids, so the display never under-reports once usage proves a larger window.
• A fresh 1M session should then read 0 / 1M, not 0 / 200k.

Scope

• Sources/Logos/Services/ClaudeUsageReader.swift — contextMax(forModel:observedTokens:) +
  whatever parses usage.model from the transcript.
• Tests: ClaudeUsageReaderTests — a claude-opus-4-8[1m] model → 1M without needing observed
  tokens; a bare/unknown id → 200k default; the > 200k fallback preserved.

Relation

Affects the context bar shipped in #47 / #49 / #90 (the HUD). Orthogonal to #89 (fresh session shows
empty) — this is about the bar's maximum, not its used value.

Source: dogfooding of the HUD build (2026-07-12); the user compared the 0 / 200k context bar
against Claude Code's own "Opus 4.8 (1M context)" header.

[kiki830621]

Diagnosis

Type

bug (incorrect display — hardcoded context-window maximum)

Root Cause / Analysis

ClaudeUsageReader.contextMax(forModel:observedTokens:)
(Sources/Logos/Services/ClaudeUsageReader.swift:48-51) ignores its model argument and returns
200_000 unless the observed token count already exceeds 200k (then 1_000_000):

static func contextMax(forModel model: String?, observedTokens: Int = 0) -> Int {
    if observedTokens > 200_000 { return 1_000_000 }
    return 200_000
}

So a fresh 1M-context session reads 0 / 200k and only "discovers" its real window reactively,
after 200k of use.

Why the model id alone can't fix it — verified against real transcripts. I checked what
usage.model actually records. Both a generic transcript and this very session (a confirmed
claude-opus-4-8[1m] 1M session) record the model as:

"model":"claude-opus-4-8" — no [1m] suffix.

And the transcript carries no other 1M signal: assistant records expose only
model / id / type / role / content / stop_reason / stop_details / usage, and there is no betas,
context-window, or beta-flag field anywhere in the JSONL. So the code comment (:44-48) is
correct — from the transcript alone, a 1M session is indistinguishable from a 200k one. A pure
"model cards" lookup keyed on claude-opus-4-8 would return the base 200k, not 1M, and the bug
would persist.

Where the 1M signal DOES live. Claude Code persists the beta selection in its config, not
the transcript. Grepping the config files:

~/.claude/settings.json → "model": "claude-fable-5[1m]"
~/.claude.json → contains "claude-opus-4-8[1m]", "claude-fable-5[1m]", "claude-sonnet-5[1m]", …

So the [1m] suffix — the exact signal needed — is readable from the account's settings.json
model field, and Logos already resolves each account's CLAUDE_CONFIG_DIR. That is the missing
input: derive the window from (session model family, from the transcript) × (is [1m] selected,
from settings.json), rather than from a hardcoded default.

Impact

• Sources/Logos/Services/ClaudeUsageReader.swift — contextMax(...) + a new read of the account's
  selected model.
• Sources/Logos/App/WindowUsageModel.swift — currently defaults contextMax = 200_000 and only
  fills it from contextMax(forModel:observedTokens:) on a real read; it would need the selected
  model threaded in (data-flow change), so the default before any read also reflects the account.
• User-facing: every 1M-context session under-reports its window as 200k until it crosses 200k; a
  fresh session always shows 0 / 200k. Cosmetic but misleading (the bar looks ~5× fuller than it is).

Strategy

• Add a small model → base context window map ("model cards"): opus / sonnet / fable → 200k
  base (parameterised so a future model with a different base is one edit), and a [1m]/[1M]
  suffix → 1M override.
• Read the account's selected model from <configDir>/settings.json (model field; already
  have the configDir) and detect the [1m] suffix. Thread it into contextMax so a 1M account's
  window is 1M up front, before any tokens are read.
• Match on family: apply [1m] only when the settings.json model family matches the
  session's transcript model family (e.g. settings=claude-opus-4-8[1m] + transcript
  claude-opus-4-8 → 1M; a mismatched default does not bleed across families).
• Keep the observed-tokens heuristic (> base → 1M) as a fallback so the window never
  under-reports once usage proves a larger one (covers a per-session /model override the
  saved default doesn't reflect).
• Tests (ClaudeUsageReaderTests): [1m] selected → 1M without observed tokens; base id → 200k;
  family mismatch → base; observed-tokens fallback preserved.

Approach note (for the plan): reading settings.json's model is the most direct signal, but it
is the account's saved default, not necessarily the current session's model (a mid-session
/model switch changes the transcript but not the saved default). Alternatives to weigh in the plan:
(A) settings.json model [recommended], (B) ~/.claude.json per-project/global model, (C) an explicit
Logos per-account "context window" setting, (D) heuristic-only + a "≥200k" hint. (A)+fallback covers
the reported case with a real persisted signal; the rest are the plan's design choice.

Conflict Class

C_shared_module_coord — the change centres on the shared ClaudeUsageReader (used by
WindowUsageModel + the cost path) plus the reader→model data-flow. Named shared resource:
ClaudeUsageReader.contextMax + the usage.model extraction. Serialize against any other
ClaudeUsageReader change; here it runs alone.

Complexity

Plan — Layer P signals: (1) decision-heavy, 2+ valid approaches (which 1M signal source:
settings.json vs ~/.claude.json vs explicit setting vs heuristic-only — the choice shapes the data
flow); (2) touches 2+ files with a data-flow dependency (ClaudeUsageReader window logic +
WindowUsageModel threading the selected model in, ordered). Not Spectra — no published API /
contract for external callers; it's an internal display-derivation fix.

Risks

• Saved-default vs current-session drift: settings.json records the account default; a
  per-session /model override isn't reflected. Mitigated by the observed-tokens fallback (never
  under-reports) and family matching (never cross-applies).
• Parsing settings.json: must be lenient (absent file / no model key / unknown suffix →
  fall back to base + heuristic), never throw.
• Base-window map staleness: a new model family with a non-200k base needs a map entry; unknown
  family → default 200k base + heuristic (fail-open, never wrong-high).

Residue

The window's true source of truth is the live API's context limit for the exact (model, beta)
in force this session, which the transcript does not record — so any local derivation
(settings.json default, or the observed-tokens heuristic) is a best-effort inference, not an
authoritative read. Fully resolving that would need the CLI to persist the active window per
session (upstream, out of Logos's scope). Noted, not silently dropped.

[kiki830621]

Implementation Plan (Plan tier)

Decision Points

Which 1M signal source (the diagnosis surfaced 4 candidates). Chosen: (A) read the account's
settings.json model field + observed-tokens fallback.

• (A) <configDir>/settings.json model ✅ — it persists the [1m] suffix
  ("model":"claude-fable-5[1m]"), Logos already resolves each account's configDir, and it's a
  read-only config read consistent with the existing transcript read (no credentials, no red-line).
• (B) ~/.claude.json — rejected: project-keyed + global mixed, messier to parse, not per-account.
• (C) an explicit Logos per-account "context window" setting — deferred to a future issue (adds UI
  surface; (A) already covers the reported case from a real persisted signal).
• (D) heuristic-only — rejected: it's the current behavior and doesn't give the 1M window up front.

Fallback stays the observed-tokens heuristic (used > base → 1M) so the window can only ever be
corrected upward, never under-reported.

Files & Changes

• Sources/Logos/Services/ClaudeUsageReader.swift
  • Add a model → base context window map (claude-opus-* / claude-sonnet-* / claude-fable-*
    → 200_000; unknown family → 200_000 default), keyed by family prefix like the existing
    pricing(forModel:) at :112.
  • Add selectedModel(inConfigDir:) -> String? — reads <configDir>/settings.json, returns its
    model field (e.g. claude-opus-4-8[1m]) or nil (absent / malformed / no key). Lenient,
    never throws — same discipline as the transcript read.
  • Add a [1m]/[1M] suffix detector + family extractor (strip the [..] suffix to get the
    base family for matching).
  • Replace contextMax(forModel:observedTokens:) with
    contextWindow(sessionModel:selectedModel:observedTokens:):
    1. base = baseWindow(forFamily: sessionModel) (from the map; 200k default).
    2. If selectedModel has a [1m] suffix and its family == sessionModel's family → return
       1_000_000.
    3. Else if observedTokens > base → return 1_000_000 (fallback, unchanged semantics).
    4. Else return base.
• Sources/Logos/App/WindowUsageModel.swift
  • track(configDir:): after setting configDir, set the initial contextMax =
    contextWindow(sessionModel: nil, selectedModel: <read from settings.json>, observedTokens: 0),
    so a fresh 1M account shows 0 / 1M immediately (not the hardcoded 200k). Reset path
    (:140-141) uses this instead of the literal 200_000.
  • defaultRead: read selectedModel(inConfigDir:) alongside the transcript, and compute the
    Snapshot's contextMax via contextWindow(sessionModel: usage.model, selectedModel:, observedTokens:).
    On a fresh session with no transcript but a [1m] settings.json, return a Snapshot with
    contextTokens: 0 + the derived max (instead of nil), so the bar reads 0 / 1M — consistent
    with Status bar shows a large token count + cost on a fresh session, before any activity #89 (0 used, correct max), not a stale/foreign read.

Sequencing & Dependencies

1. ClaudeUsageReader first — the pure baseWindow map, selectedModel(inConfigDir:), suffix
   detector, and contextWindow(...). These are self-contained + unit-testable.
2. WindowUsageModel second — it depends on the new reader functions (selectedModel,
   contextWindow) to thread the selected model into track + defaultRead.
3. Tests last (or RED-first per function).

Decision Points → answered above (settings.json + fallback).

Risks & Mitigations

• Saved-default vs current-session drift: settings.json is the account default; a mid-session
  /model switch changes the transcript but not the saved default. → the observed-tokens fallback
  never under-reports, and family matching prevents cross-applying (settings=fable[1m] +
  session=opus → opus base 200k, not 1M).
• Malformed / absent settings.json: selectedModel returns nil → contextWindow falls to
  base + heuristic. Lenient parse, never throws (mirror the transcript read's try?).
• Base-map staleness: a new family with a non-200k base needs a map entry; unknown family →
  200k default + heuristic (fail-open, never wrong-high).
• Fresh-session snapshot change: defaultRead returning a max-only Snapshot (contextTokens 0)
  instead of nil must not resurrect the Status bar shows a large token count + cost on a fresh session, before any activity #89 foreign-transcript bug — the 0 is a genuine
  no-usage read, and the transcript resolution is still id-addressed (Status bar shows a large token count + cost on a fresh session, before any activity #89 untouched). Guard: only
  return the max-only snapshot when there is genuinely no transcript for the bound session, not when
  a read failed.

Test Plan (Tests/LogosTests/ClaudeUsageReaderTests.swift + WindowUsageModelTests.swift)

• contextWindow: sessionModel=claude-opus-4-8, selectedModel=claude-opus-4-8[1m], observed 0
  → 1_000_000 (the core fix — RED against today's contextMax).
• contextWindow: selectedModel=claude-opus-4-8 (no suffix), observed 0 → 200_000.
• contextWindow: family mismatch selectedModel=claude-fable-5[1m], sessionModel=claude-opus-4-8
  → 200_000 (opus base, no cross-apply).
• contextWindow: selectedModel=nil, observed 250_000 → 1_000_000 (fallback preserved).
• selectedModel(inConfigDir:): a temp dir with settings.json {"model":"claude-opus-4-8[1m]"} →
  returns that; absent file / no model key → nil.
• WindowUsageModel: track(configDir:) on a config dir whose settings.json selects [1m], with
  no transcript → contextMax == 1_000_000, contextTokens == 0.

Out-of-scope (will NOT be touched)

• An explicit Logos per-account "context window" UI setting (candidate C) — separate future issue.
• The cost path (pricing/sessionCost) — unaffected.
• The 帳號用量 window — it shows plan usage, not the context window.
• #89's id-addressed transcript resolution — untouched (only the max derivation changes).

Family-wide scope (shared-abstraction hard-gate)

n/a — hard gate not the trigger; Plan came from the decision-heavy + data-flow Layer P signals.

Tangential Observations (filed mid-plan, v2.42.0+ #524)

none surfaced — the diagnosis + plan stayed within the single ClaudeUsageReader context-window
derivation; no sister bug or unrelated quality issue was discovered while tracing it.

[kiki830621]

Implementation Complete

Landed per the approved Implementation Plan (Plan tier). Direct-commit path.

Checklist

• ClaudeUsageReader: added baseWindow(forModel:) (family → base window, prefix-keyed like
  pricing(forModel:); 200k default), selectedModel(inConfigDir:) (lenient read of
  <configDir>/settings.json model, nil on absent/malformed/no-key), a [1m]/[1M] suffix
  detector + familyBase extractor, and contextWindow(sessionModel:selectedModel:observedTokens:).
  Removed the old contextMax(forModel:observedTokens:) (no remaining callers).
• contextWindow derivation: base from the session model; [1m] selected → 1M up front
  when the session model isn't known yet, or when its base id matches (so fable[1m] never
  cross-applies to an opus session); observed-tokens > base → 1M kept as the upward-only fallback.
• WindowUsageModel: defaultRead computes the Snapshot's contextMax via contextWindow
  (reading selectedModel off-main alongside the transcript); track(configDir:) seeds the initial
  contextMax from the account's settings.json so a fresh 1M account reads 0 / 1M immediately
  (a nil configDir keeps the plain 200k default).
• Tests (RED-first): the [1m] → 1M up front case proven RED against the stub before the family
  step, GREEN after; a TDD-caught edge (nil session model on a fresh session failed the family
  match) fixed by trusting the selection when the session model is unknown. Coverage:
  contextWindow (up-front with/without transcript, no-suffix base, family-mismatch, observed-tokens
  fallback), selectedModel(inConfigDir:) (reads / nil), and WindowUsageModel fresh-1M-account
  end-to-end (0 / 1M from settings.json).
• #89 untouched: the fresh-session up-front max comes from track's settings-derived seed, not
  from changing defaultRead's nil/foreign-transcript semantics.

Residue (carried from Diagnosis)

settings.json is the account's saved default, not necessarily this session's live model (a
mid-session /model switch isn't reflected); the authoritative window is the live API's limit for
the exact (model, beta), which the transcript does not record. Family matching + the observed-tokens
fallback bound the risk (never under-reports, never cross-applies), but this remains a best-effort
inference, not an authoritative read — noted, not silently dropped.

[kiki830621]

Closing Summary

Problem

The status-bar context bar showed 0 / 200k even for an Opus 4.8 (1M context) session — the maximum was wrong. A 1M session under-reported its window until used tokens crossed 200k, and a fresh session always read 200k.

Root Cause

ClaudeUsageReader.contextMax(forModel:observedTokens:) ignored its model argument and returned 200_000 unless observed tokens already exceeded it. The [1m] context-beta signal is not in the transcript at all (turns record only the base id, e.g. claude-opus-4-8); it is persisted in <configDir>/settings.json's model field (e.g. claude-opus-4-8[1m]). A plain model-card lookup on the transcript id could never distinguish 200k from 1M, so the bug persisted.

Solution

Derive the window from the model, reading the [1m] signal from the account's settings.json:

• baseWindow(forModel:) — family → base window (prefix-keyed like pricing(forModel:); 200k default, fail-open).
• selectedModel(inConfigDir:) — lenient read of <configDir>/settings.json's model (nil on absent/malformed/no-key), same read-only discipline as the transcript read (no credentials).
• contextWindow(sessionModel:selectedModel:observedTokens:) — base from the session model; a [1m] selected model → 1M up front when the session model is unknown (fresh session) or its base id matches (so fable[1m] never cross-applies to an opus session); observed-tokens > base → 1M kept as an upward-only fallback.
• WindowUsageModel seeds the initial contextMax from settings.json in track(configDir:) (fresh 1M account reads 0 / 1M immediately) and computes it via contextWindow in defaultRead. The old contextMax(forModel:observedTokens:) was removed (no remaining callers). #89's transcript-resolution semantics were left untouched.

Verification

• TDD, RED-first: the [1m] → 1M up front case was proven RED against the stub before the family step, GREEN after; a TDD-caught edge (nil session model on a fresh session failed the family match) was fixed by trusting the selection when the session model is unknown. Coverage added for contextWindow (up-front with/without transcript, no-suffix base, family-mismatch, observed-tokens fallback), selectedModel(inConfigDir:), and WindowUsageModel fresh-1M-account end-to-end (0 / 1M from settings.json).
• Full swift test green (only the known loadAsync timing test tolerated); built and installed.
• Known caveat (see Residue): settings.json is the account's saved default, not necessarily the live session model — a mid-session /model switch is not reflected. Family matching + the observed-tokens fallback bound the risk (never under-reports, never cross-applies).

Changes

• d3c550d — fix: derive the context-window max from the model, not a hardcoded 200k (Context bar shows 200k max for a 1M-context model — derive the max from the model, not a hardcoded default #95)
  • Sources/Logos/Services/ClaudeUsageReader.swift, Sources/Logos/App/WindowUsageModel.swift
  • Tests/LogosTests/ClaudeUsageReaderTests.swift, Tests/LogosTests/WindowUsageModelTests.swift

Residue Acknowledgement

Acknowledged as still residue: the window's true source of truth is the live API's context limit for the exact (model, beta) in force this session, which the transcript does not record — so any local derivation (settings.json default, or the observed-tokens heuristic) is a best-effort inference, not an authoritative read. Fully resolving it would require the claude CLI to persist the active window per session (upstream, out of Logos's scope). No follow-up issue is filed because the resolution is not implementable within this repository; the derivation's guardrails (family matching + upward-only fallback) keep it from ever under-reporting or cross-applying.