昨天大概想了一下 Heimdall 的分層架構與資料流。在前端呈現上，為了方便身處終端機的 AI Agent 跟我可以在同一個工作空間併行觀測，所以決定第一版先做成終端介面（TUI），並選擇 Go 語言以及 Bubble Tea 框架。

在所有觀測面向中，我想我們最好奇跟關心的應該是「這次任務花了多少錢？Prompt Caching 能省多少成本？」 因此，Heimdall 我們就從 Dashboard（成本與快取統計） 開始吧。

一、Dashboard 成本與快取統計

經過資料 Pipeline 與 TUI 渲染整合，這是 Heimdall Dashboard 在終端機中的實際執行畫面，當把 Heimdall 執行起來就會看到這個頁面：

這個 Dashboard 正在呈現的是 Antigravity CLI 某一個 Session 的分析畫面，包含兩個部分，「全局統計」與「當前 Step 分析」。整個畫面垂直切分成上下兩個獨立的資訊面板：

1. 上方面板（Session Dashboard & Cost Telemetry）：專注於「整個 Session」的累計統計，包含總 Token 規模、全域快取命中率、估算成本，以及多模型消耗拆解等。
2. 下方面板（Step Token Telemetry & Cloud Generation）：專注於「當前關注的 Step」，預設是關注最新的 Step。展示該次推論時的 Context、快取與生成 Token 分佈、以及 TTFT 等即時遙測數據。在下方的這一頁，我們是可以透過 Vim 指令 j, k, gg, shift+g 等做到查看上一個 Step 資料，或是查看第一筆或最新一筆等。在 Tool Calling 等 Local Step，則會顯示本地呼叫了什麼工具，以及調用工具的結果。

在這個 Dashboard 頁面中，我們既能隨時掌握整個 Session 的累積資訊，也能透過 Vim 指令切換 Step，看單一個 step 內執行的資源消耗。

二、上方面板：Session 統計

上方面板主要呈現這個 Session 的累計數據，分為頂部的「四大核心指標」與下方的「模型明細表格」。

1. 四大核心指標

• TOTAL INPUT：整個 Session 累計送入模型的 Token 總數（圖中為 321.78M Tok，底下標註 2029 observed turns）。這裡的 2029 Observed Turns 指的並不是 Session 只有 2029 個 Steps，而是其中共有 2029 個 Steps 有實際發送 Request 給 AI 模型（像執行本地 Bash 指令或檔案讀寫等 Local Step 不會調用模型；這也是為什麼下方選中的是 STEP #4120，但雲端推論輪數是 2029 輪）。
• TOTAL OUTPUT：模型實際產出的 Token 總數（圖中為 1.42M Tok），包含模型回覆的內容與思考過程。
• CACHE HIT RATE：快取命中率（圖中為 92.3%，快取了 297.02M Token）。代表有超過九成的輸入直接命中快取，不用重新計算。
• ESTIMATED COST：預估累積費用（圖中為 $47.600 USD），依照官方標準 API 定價計算當前累積的花費。

2. 各模型明細（Multi-Model Usage & Cost Breakdown）

當一個 Session 用了多個模型時，這張表會把每個模型的用量拆開來看：

• Model Name：模型名稱（如 gemini-3.8-flash、gemini-3.7-flash、claude-sonnet-4-6）。
• Turns：呼叫次數。可以看出哪顆模型是主力（例如主力 gemini-3.8-flash 跑了 1,754 輪）。
• Input：各模型輸入 Token 數（如 gemini-3.8-flash 累積了 277.18M）。
• Cached：各模型各自的快取命中率（例如主力模型快取率達到 93.0%）。
• Output：各模型生成的 Token 數（如主力模型產出 1.15M）。
• Est. Cost：各模型各自花費的預估金額（例如主力模型花費 $38.211 USD，第二多的是 gemini-3.7-flash 的 $7.558 USD）。

這樣就能快速看出用了哪些模型？哪種模型在這個 Session 最花錢？

三、下方面板：單一 Step 資訊

下方面板呈現的是目前選中的單一 Step（圖中為 STEP #4120），包含基本資訊、Token 分佈與延遲時間。

1. 步驟基本資訊

• STEP 編號與類型：如 STEP #4120 · CLOUD GENERATION，代表這是一次雲端模型推論。
• Event / Time：事件類型與時間戳記（如 MODEL_RESPONSE · 2026-09-16 13:39:03）。
• Agent / Model：當前步驟的角色與模型（如 [MAIN] gemini-3.8-flash）。

2. Token 分佈與長條圖

用長條圖直觀呈現該步驟的 Token 結構與組成比例，分為輸入（Context）與輸出（Output）兩大層次：

• Context Tokens：當前 Context 累積長度與模型窗口上限（如 242.7k / 256.0k，佔 94.8%）。此時上下文即將達到窗口上限，長條圖會自動呈現黃色高負載警戒，提醒我們 Context 快要滿了。輸入端細分為兩大部分：

  • Cached Content：命中快取的 Token 數量與比例（如 244.1k，佔輸入的 98.6%，綠色長條），代表這一步絕大多數 Context 都是直接讀取快取的。
  • Uncached Prompt：這次新增、沒命中快取的 Token（如 3.5k，僅佔 1.4%），通常就是本次送入模型的新增對話差量。

• Output Tokens：這次推論生成的總 Token 數（如 2.2k，佔總用量的 0.9%），輸出端同樣拆分為兩大成分：

  • Thinking Output：模型在給出回答前進行內部思考與推理的 Token 量。此處為 0 [inferred]（0.0%），代表該步並未產生獨立的思考 Token。
  • Content Output：模型真正輸出給使用者的回覆內容 Token 量（如 2.2k，佔輸出的 100.0%，白色長條），即模型完整回覆的文字長度。

3. 延遲與快取折扣

• Catalog cache discount：該模型的官方快取折扣率（如 90.0%）。
• TTFT (First Token)：首字延遲時間（Time To First Token，如 2477 ms），也就是我們在 Day11 提到的，發出請求到收到第一個 Token 的反應時間（約 2.5 秒）。
• Streaming Duration：串流完整輸出的耗時（如 8185 ms，約 8.2 秒）。

透過這兩個面板，上方看整體累積的花費與模型分佈，下方看單一 Step 的快取與延遲狀態。有了整體的數據摘要後，接下來我們可能會想細部知道模型在各 Step 之間到底做了什麼？尤其是 Local 呼叫了哪些工具？思考脈絡是什麼？雖然下方面板也有寫是單一 Step 的資訊，但如果 Tool Calling 回傳結果太長，其實很難在下方面板呈現。明天我們接著看一下 Heimdall 第二個畫面：Step Timeline 步驟軌跡。