狀態列 context 分母卡在 200k:1M session 的 window 沒有任何可讀訊號（#95 的 settings.json 路徑為空）

[kiki830621]

Problem

Original text:
「還有一個issue 是 [截圖] 這邊不知道為什麼會以為是200k，剛開始應賅就要先蒐集詢問一次吧」
— Source: user, live session 2026-08-03（附截圖，見下方「Screenshot」）

狀態列的 context 計量顯示 97k/200k，但同一個 session 的 Claude Code header 寫的是
Opus 5 (1M context)。context max 被當成 200k，實際上是 1M。使用者的提案：session 一開始就先主動取一次真正的 context window，而不是靠推論。

Screenshot（無法上傳原檔，逐字描述）

截圖是 Logos 內的 Claude Code session：header 顯示
Claude Code v2.1… / Opus 5 (1M conte… / ~/Developer/logo…，
最底下的狀態列顯示訊號圖示 + 綠色進度條 + 97k/200k + 沙漏 5h 6…。
（此 issue 由 CLI session 建立，貼上的圖片沒有可讀的本機路徑可上傳到 attachments release；如需原圖請重新提供檔案。）

Type

bug

Expected

Context 計量的分母等於該 session 真正的 context window。此例應為 97k/1M。

Actual

分母固定落在 200k，直到用量真的超過 200k 才會自我修正。

觀察（不是 diagnosis） —— 現有三個訊號在這個 session 全部失效：

• ClaudeUsageReader.baseWindow(forModel:)（Sources/Logos/Services/ClaudeUsageReader.swift:46-49）
  對所有 family 回傳 200_000（註解寫「opus / sonnet / haiku / fable all ship a 200k
  base window today; the 1M is a beta on top」）。
• 訊號 (2)：selectedModel(inConfigDir:) 讀 <configDir>/settings.json 的 model 欄位找
  [1m] 後綴。實測此帳號的 settings.json 根本沒有 model key
  （keys 只有 enabledPlugins / extraKnownMarketplaces /
  skipDangerousModePermissionPrompt / theme）→ 回傳 nil。
• 訊號 (3)：observedTokens > base 的 fallback 要等實際用量破 200k 才會跳成 1M ——
  在那之前分母一路是錯的，而且「剩餘」被嚴重低估。
• transcript 裡最新一筆 assistant 的 message.model 是 claude-opus-5（不帶 [1m]）；
  transcript 也沒有任何 context-window 欄位。
• 掃過 <configDir>/.claude.json：唯一帶 [1m] 的字串是
  additionalModelOptionsCache[0].value = claude-fable-5[1m]（那是選單快取，不是本 session 的選擇）；
  clientDataCacheSlots/*/model 是 claude-opus-5，同樣不帶後綴。

也就是說：目前 Logos 讀得到的檔案裡，沒有任何一處記錄了「這個 session 是 1M」。#95 的
[1m]-from-settings.json 機制對「使用者沒把 model 寫進 settings.json」的帳號是空的。

Impact

Context 計量是決定「還能不能繼續、要不要換帳號 / 開新 session」的主要依據。分母錯 5 倍
會讓人在還有 90% 空間時就以為快滿了；反過來，若之後有 family 真的低於預設值，同一條
fail-open 邏輯也會過度樂觀。這條計量錯了，狀態列就從資訊變成雜訊。

Open questions（留給 diagnose）

• 使用者提的「剛開始先蒐集詢問一次」具體要問誰？可能的來源：
  (a) claude CLI 有沒有可查詢的 session/model metadata（例如某個 --print / status 之類的
  一次性查詢）；(b) 是否有官方 API 可依 model id 取得 context window；
  (c) 在 spawn 時由 Logos 主動指定 model（含 [1m]），這樣選擇就在 Logos 手上、不必反推。
• 若確實無法取得權威值，退路是把 per-family base window 建成可設定表（baseWindow 目前
  hardcode 單一常數），並讓使用者在設定裡覆寫。
• 一次性 probe 要放在哪一層？WindowUsageModel 每次刷新都重算（:176-182），probe 的結果
  要 cache 在 session 層級，不能每秒問一次。

[kiki830621]

Diagnosis

Root Cause

不是「200k 這個數字寫死了」——baseWindow 回 200k 對沒有 [1m] 的 session 是正確的。真正的缺陷是：判斷 [1m] 的訊號源，讀的是一個在常態下不存在的欄位。

contextWindow(sessionModel:selectedModel:observedTokens:)（ClaudeUsageReader.swift:83-95）有四個分支：

#	條件	結果
1	base = baseWindow(sessionModel)	恆 200_000
2	selectedModel 帶 [1m] 且家族相符	1_000_000
3	observedTokens > base	1_000_000
4	其餘	base

分支 2 的 selectedModel 來自 selectedModel(inConfigDir:)（:56-63），讀 <configDir>/settings.json 的 model key。這台機器上 10 個帳號 + 全域 settings.json 全部沒有這個 key，該函式恆回 nil，分支 2 永不觸發。

[1m] 的來源其實有三條，Logos 只讀得到其中一條：

來源	本 session 實測	Logos 讀得到？
settings.json 的 model key（使用者用 /model 明確 pin 時才寫入）	不存在	✅ 唯一讀的
ANTHROPIC_DEFAULT_OPUS_MODEL 等環境變數	未設定	❌
CLI 自身／伺服器端帳號預設	這是生效中的那條（本 session 為 claude-opus-5[1m]）	❌ 磁碟上完全不可見

第三條的不可見性是窮舉搜尋後的結論，不是推測：.claude.json 裡出現的 [1m] 字串全都是靜態目錄（tengu_auto_mode_config.severityByModel 的 key、additionalModelOptionsCache 的選單項），不是 per-session 狀態；orgModelDefaultCache 與 autoCompactWindowsCache 在橫跨一小時的 5 份輪替備份中全為 null；clientDataCacheSlots[…].model 是不帶後綴的 "claude-opus-5"。

Transcript 也沒有：對 922 筆記錄做結構性掃描（比對 key 路徑而非字串內容），context_window / contextWindow / max_input_tokens 的結構性命中為 0。（字串命中有 1 筆，是本次診斷對話自己的內容 —— 這正是不能用 grep 字串當證據的理由。）

所以 #95 的機制在結構上看不見常態情況。這不是表過期，是訊號源選錯。

為什麼使用者的直覺是對的

「剛開始應賅就要先蒐集詢問一次吧」

分支 3（observedTokens > base → 1M）是事後自我修正：要先燒掉 200k 才會觸發。也就是說 1M session 的前 200k 全程分母都是錯的 —— 不是邊角情況，是每個 session 的開頭，而且正是使用者最需要判斷「還能寫多少」的階段。WindowUsageModel.swift:179-182 的 pre-transcript 路徑（sessionModel: nil）更是直接在開窗那一刻就回 200k。

這個 bug 被綠燈測試鎖住

Tests/LogosTests/ClaudeUsageReaderTests.swift 有兩個目前綠燈的測試在認證錯誤的行為：

• contextWindowBase（:54-58）：sessionModel: "claude-opus-4-8" + 同名 selected → 斷言 200_000
• contextWindowFamilyMismatch（:60-65）：同樣以 200k 為 base

它們斷言的是「沒有 [1m] 訊號時退回 200k」，就分支 4 而言仍然正確；但任何改動若讓分母在缺訊號時不同，這兩個測試會紅。修 #113 必須顯式處理它們，不可默默改掉。

唯一的權威訊號：statusLine（push，非 pull）

窮舉 CLI 2.1.221 的全部 12 個 subcommand 後確認：沒有任何唯讀指令能查詢 session 的 context window。 claude config / claude models / claude status 不存在；claude doctor、claude auth status 無此欄位；claude agents --json（唯一能從外部列出其他 session 的指令）刻意不含 model / contextWindow / usage 欄位（官方 agent-view.md 明載）。

該資料確實存在，但只以 push 形式送給使用者設定的 statusLine script，欄位包含：

model.id, model.display_name
context_window.{ context_window_size, total_input_tokens, total_output_tokens,
                 used_percentage, remaining_percentage, current_usage }
cost.*, rate_limits.*

context_window_size 的值正是 200000 或 1000000 —— 這就是 #113 要的那個數字，由 session 自己回報，開場即有，不必等燒過 200k。

Strategy

• 建立 statusLine 通道：Logos 在隔離帳號的 <configDir>/settings.json 寫入 statusLine，指向 Logos 自有的 helper；helper 把收到的 JSON 落到該帳號目錄下一個已知路徑，WindowUsageModel 既有的 FileWatcher 直接吃
• contextWindow(...) 新增最高優先分支：statusLine 回報的 context_window_size 存在 → 直接用（權威值，取代所有推論）
• 保留現有四個分支作為 fallback 階梯（statusLine 尚未回報的第一瞬間、或使用者關掉該功能）
• 顯式更新 contextWindowBase / contextWindowFamilyMismatch 兩個測試，並在測試註解寫明它們守的是 fallback 而非權威路徑
• 系統預設（Main）帳號的處置（見 Risks 1）

Conflict Class

A_parallel_safe 相對 #111 / #112（ClaudeUsageReader.swift / WindowUsageModel.swift 與帳號用量的檔案不相交）。

與 #116 共用機制（見下）—— 兩者應相鄰處理。

Complexity

Plan —— 新增跨程序通道（寫 claude config + helper + 檔案協定）、觸及既有紅線、概念散佈 ≥5 檔。

Risks

1. 系統預設帳號可能整條路不通（最高風險）。設定 statusLine 需要寫入 claude 的 settings.json。這不是憑證操作（Extract LogoSwitch — a first-party-safe Swift module for claude multi-account switching + auth #34 紅線是憑證，不是設定），但 per-account gateway 的設計文件記載 Support a "main" account that reuses the system ~/.claude login (spawn with configDir == nil) instead of an isolated re-login #54 禁止寫入系統預設帳號的 settings，且「settings 檔的 env 項優先於 process env」——同一個不對稱會讓 Main 帳號被排除在外，就像 gateway 把它排除在 pool 外一樣。Main 帳號很可能只能退回 fallback 階梯，這點必須誠實呈現在 UI 上，不能假裝它也有權威值。

2. 寫入使用者的 claude 設定是新的邊界。Logos 至今只讀 claude 的產物、只在 process env 注入。第一次寫入對方的設定檔需要：既有 statusLine 設定的偵測與保留（不可覆蓋使用者自己的）、移除時的還原、以及使用者可關閉的開關。

3. helper 的存在形式。statusLine 是 claude 執行的 shell 指令，其 stdout 會顯示在 claude 自己的狀態列上。Logos 的 helper 必須同時滿足「輸出對人類有意義」與「把 JSON 落給 Logos」，否則會弄髒使用者的終端機畫面。

4. 測試鎖（見上）。

Residue

• [1m] 的語意已用實測釐清：它是 /model opus[1m] 這類選擇器（binary 內含 opus[1m]、sonnet[1m]、顯示字串 "Sonnet 4.6 (1M context)"），對應 context_window_size 的 200000 vs 1000000。所以「現行世代都是 1M、把 base 表改掉就好」是錯的 —— 同一個模型家族兩種 window 並存，base 200k 對非-[1m] session 正確。
• 未採用的路線（記錄理由）：(a) 讀磁碟 —— 已窮舉證明訊號不存在；(b) 攔 stdout banner —— TeedLocalProcessTerminalView 的 byte tap + RollingTerminalBuffer + 兩個既有 passive detector 的架構已經存在，加一個 detector 是同形狀擴充；但 claude 是否真的印出可辨識模型的 banner 未經證實，不能把策略建立在假設的輸出上。若 statusLine 路線因風險 1 受阻，這是第一備案。
• Logos 可以改為自己決定模型：ClaudeProcessConfig.extraArgs 已經在傳 --dangerously-skip-permissions，同一個縫加 --model <id> 只要一行（應掛在 Account 而非全域 AdvancedSettings，因為它與 upstream 同屬 per-account 概念）。那會讓分母變成 Logos spawn 時就知道的值，整條事後推論鏈消失。但這改變了產品語意（Logos 開始替使用者決定模型），屬獨立決策，另開議題。

對 #116 的影響：解除封鎖

#116（狀態列顯示 model / effort / version / gitBranch）原判定為被 #113 阻擋。實測推翻：transcript 的頂層結構性欄位已經帶了其中三個，而那正是 ClaudeUsageReader 已經在解析的檔案 ——

欄位	transcript 實測值	記錄數
version	"2.1.220"	637
gitBranch	"main"	637
effort	"high" / "xhigh"	348

只有 model 的顯示粒度依賴本 issue：message.model 給的是 "claude-opus-5"（可直接渲染成 Opus 5），(1M) 後綴才需要 #113 的 context_window_size。

→ #116 可以先做三個欄位 + Opus 5，(1M) 後綴接在 #113 之後補上。兩者共用同一條 statusLine 通道，應相鄰排程。