AIREITER2026 年 8 月 17 日，OpenRouter 揭露自家其中一個預覽模型一直在默默燒錢：每月成本約 6,200 美元，約是該組織混合平均費率的 25 倍；其中 98% 更集中在一組批次管線 API 金鑰上。同日推出的 Activity 儀表板，就是為了讓這類錯誤從幾個月後才被發現，變成幾分鐘內就能揪出。儀表板本身相當實用，能在同一個地方查看支出、Token、快取命中率，以及逐筆請求的詳細資料；底層的 Beta Analytics API 則還有不少毛邊，以下一次整理。
一堂價值 6,200 美元的課：OpenRouter Activity 儀表板能抓出什麼
官方發布文章中的內部案例，正好呈現這套工具要處理的典型問題。某個預覽模型一個月消耗了 6,185 美元、共 2.5 億個 Token（每百萬 Token 約 24.7 美元，快取命中率 7.6%）。進一步依 API 金鑰查看後，發現其中一組名為 batch-pipeline 的金鑰就占了 6,067 美元，涵蓋 1.27 億個 Token 和 37,000 次請求；換算下來，高流量、低複雜度的批次工作竟然要價約每百萬 Token 48 美元。最後只改了一行程式，把模型換掉即可解決（成本控管教學中的完整拆解）。
與儀表板一同推出的功能還包括：可自訂查詢的 Explore、用來找出變化的 Trends、偵測提示注入與敏感資料事件的 Guardrails、請求層級記錄、Beta Analytics API，以及 GitHub 上可安裝、供程式設計代理使用的 openrouter-analytics 技能。
Activity 各分頁，分別能回答什麼問題
OpenRouter Activity 儀表板不是單純把功能塞進幾個選單，而是圍繞不同問題來設計。真正與成本分析最相關的有三個分頁，各自負責回答不同問題。
Overview：我們花了多少錢？
Overview 一開啟就會顯示五項核心指標：總支出、請求數、Token 用量、快取命中率，以及每百萬 Token 的混合平均成本；每項指標都附有迷你趨勢圖和前一期間的比較。下方則會列出支出最高的使用者與應用程式、各模型支出、OpenRouter 點數與估算 BYOK 支出的比例，以及提示與完成 Token 的數量。當你只想先知道「到底花了多少」時，這就是該看的分頁。
Trends：和上一個期間相比，哪裡變了？
Trends 著重的是變化幅度，而不是絕對數字，能依模型、使用者、API 金鑰和應用程式排列變化。它適合用來抓出失控的代理、新近爆紅的模型，或某個內部工具突然從實驗用途變成預設選項的情況。Overview 告訴你哪裡貴，Trends 則告訴你哪裡是最近才開始變貴。
Explore：我想自己切資料，該怎麼看？
Explore 就是查詢建立器。可用指標包括支出、請求數、多種 Token 類別、快取命中率、每百萬 Token 的混合平均成本、BYOK 與點數支出，還有 P50／P90／P99 延遲和吞吐量。
最多可以同時用兩個維度分組，選項包括模型、供應商、API 金鑰、應用程式、使用者、工作區、國家、地區、上下文長度、工作階段、生成、 自訂 ID 和分類器。時間彙整範圍從分鐘到月份，圖表可選長條圖、折線圖或點圖；任何圖表都能儲存為私人檢視或組織共用檢視。要注意兩件事：第三個分組維度會直接被拒絕；而記錄中的提示與完成內容，只有在請求執行之前就啟用私人輸入／輸出記錄時才會顯示。
不用碰 API，也能匯出 CSV 或 PDF
會計人員和試算表使用者不需要 API。Activity 頁面可以直接把相同的彙整數據匯出成摘要或詳細報告，支援兩種格式，全程不用寫程式。官方匯出流程只有五步：
- 開啟 Activity 頁面。
- 選擇時間範圍和分組方式（模型、API 金鑰或建立者）。
- 開啟右上角的選項選單。
- 選取 Export to…。
- 選擇 CSV 或 PDF。
預設匯出的是摘要報告，會把支出、Token 和請求數放在一起。如果要產生詳細報告，先開啟特定的指標卡片，再執行匯出；詳細版本會依你選擇的分組方式拆解該項指標。時間範圍選定後，子區間會自動固定：
| 時間篩選 | 子區間 |
|---|---|
| 1 小時 | 每分鐘 |
| 1 天 | 每小時 |
| 1 個月 | 每天 |
| 1 年 | 每月 |
文件還有兩個容易被忽略的細節：報告中的 BYOK 支出，是按照供應商市場費率計算的估算值；由於沒有納入供應商個別折扣，可能和你收到的實際外部帳單不同。推理 Token 已計入完成 Token，但報告會另外列出，因此你可以看見帳單中用於「思考」的部分，又不會重複計算。
五分鐘完成第一次 Analytics API 查詢
Analytics API 透過兩個端點，提供與 Explore 相同的資料。不過它明確標示為 Beta，所以正確流程應該先探索支援內容，再開始寫查詢。
先過管理金鑰這一關
Analytics 端點要求使用管理金鑰；如果拿一般推論金鑰呼叫，會收到 HTTP 403。反過來也一樣，根據成本控管教學，管理金鑰不能用來發出模型請求。這能在金鑰外洩時縮小影響範圍，但它仍然可以查看整個組織的完整支出明細。教學中的建議很直接：把它當成任何其他憑證一樣保護。
先讀 Meta，再送出查詢
GET /api/v1/analytics/meta 會回傳目前支援的指標、維度、篩選運算子和粒度。由於 Beta 支援內容可能變動，最好在每次自動化執行前都先查一次。實際查詢使用 POST /api/v1/analytics/query。文件提供的 cURL 範例如下：
curl -X POST https://openrouter.ai/api/v1/analytics/query \
-H "Authorization: Bearer <management-key>" \
-H "Content-Type: application/json" \
-d '{
"metrics": ["request_count"],
"dimensions": ["model"],
"granularity": "day",
"limit": 100,
"time_range": {
"start": "2026-08-01T00:00:00Z",
"end": "2026-08-08T00:00:00Z"
}
}'回應會把資料列放在 data.data 底下，並附上 metadata 區塊，其中包含 query_time_ms、row_count 和 truncated。教學中的單列查詢範例耗時 17 毫秒，代表這類呼叫相當輕量；文件也將整套流程描述為唯讀，除了既有用量成本外不會額外收費。已列出的錯誤狀態包括 400（查詢錯誤）、401（未驗證）、403（金鑰類型錯誤）、408 和 500。
四組查詢，快速找出多花的錢
官方教學提供五組配方。重新排列後，可以把它們組成一套可重複執行的成本追查流程。
1. 哪個模型最會燒錢？ 教學的第一組查詢會依 model 分組，要求回傳 total_usage、request_count、tokens_total 和 cache_hit_rate，再依支出排序：
{
"metrics": ["total_usage", "request_count", "tokens_total", "cache_hit_rate"],
"dimensions": ["model"],
"order_by": { "metric": "total_usage", "direction": "desc" },
"limit": 10,
"time_range": { "start": "2026-07-01T00:00:00Z", "end": "2026-08-01T00:00:00Z" }
}接著計算每百萬 Token 的實際成本：total_usage / tokens_total × 1e6。再拿它和整體混合平均費率比較，也就是不指定維度時用同一公式計算的結果。教學的判斷準則是：某模型價格如果是混合平均費率的大幅倍數，就最值得優先追查；那個 25 倍的預覽模型異常就是這樣被找出來的。
2. 到底是哪組 API 金鑰造成的？ 在精確的模型 slug 上加篩選，並改用 api_key_id 分組。結果會把 ID 對應成容易辨識的名稱，因此才能看出 batch-pipeline 占了問題總額 6,185 美元中的 6,067 美元。分組時應使用 api_key_id，不要用解析後的金鑰名稱做篩選；接著利用回傳的 user_email，把支出和內部紀錄對起來。
3. 這些錢實際買了什麼？ 把每日支出拆成以下幾個部分：
| 指標 | 含義 |
|---|---|
usage_upstream | 原始推論成本 |
usage_cache | 快取節省金額（或寫入快取的成本） |
usage_data | 折扣，通常是負值 |
usage_web | 網路搜尋附加費 |
usage_file | 檔案處理附加費 |
提示與完成內容的比例如果接近 20:1，通常表示上下文過大；推理 Token 占比很高，則代表你可能正在為不需要的思考過程付費。最值得優先改善快取的，是提示內容很多、但快取命中率偏低的流量；如果命中率本來就高，就該回頭檢查模型組合。提示內容偏重其實是常態，不是異常：一份分析 OpenRouter 公開程式設計類別資料的研究測得其中 93.4% 的 Token 都是輸入。
4. 修改真的奏效了嗎？ 把第一組查詢改成按週的時間序列，並依 api_key_id 分組重新執行。在官方範例中，batch-pipeline 金鑰的週支出從 5 月 31 日當週的 1,402.50 美元，降到 6 月 7 日當週的 11.20 美元。模型切換成功時，圖表應該會像懸崖一樣急降，而不是緩慢下坡。
如果第一組查詢的下一步是換用更便宜的模型，決策最終會落在 OpenRouter 自己的路由層。自動路由與固定路由各自的取捨，請參考我們的 OpenRouter 自動路由指南。
文件沒明講的六個 Beta 毛邊
只要查詢寫對，API 基本上會照文件運作；以下問題其實也有文件依據，只是散落在教學的註腳裡。
- 三個維度會回傳 400。 上限是兩個；
model × key × day必須拆成多次查詢，或改用時間粒度處理。 group_limit可能讓時間區間無聲無息地被截斷。 不設定時，OpenRouter 會自動計算安全值；設得太低，時間序列中的數週資料可能直接消失。若完全沒有指定維度，這個參數則會被忽略。- 計數指標有時會以字串回傳。 參考文件顯示的是數字，但 API 可能回傳字串，程式應該兩種格式都能解析。
- 時間序列的欄位名稱不固定。 同一個時間桶，會依查詢形狀顯示為
date__day或created_at__day。 - 未使用的成本元件會回傳
null，不是零。 任何彙整腳本都應加入 null 檢查。 metadata.truncated: true代表總數不完整。 提高limit（預設為 1,000），或縮短時間範圍後重新執行。
該用儀表板、API，還是自己建管線？
原生工具已經能處理帳戶層級的問題。只有在需求超出這個範圍後，自建系統才真正值得：
| 你的需求 | 適合使用 |
|---|---|
| 快速查看支出、Token、快取命中率 | Activity Overview |
| 了解哪些地方變了、哪裡正在暴增 | Trends |
| 臨時切分資料與分享 | Explore + CSV／PDF 匯出 |
| 排程報告、警示、內部儀表板 | Analytics API |
| 多供應商彙整、依使用者分配預算、自訂異常偵測 | 以用量記錄和 Webhook 建立自訂管線 |
自己架設成本追蹤並不是什麼罕見做法。一位 r/FinOps 發文者就說：
「因為某個模型的價格一夜之間從幾美分跳到 3 歐元，所以我在 Obsidian 裡自己做了 AI 成本追蹤器。」
那篇文章，以及 r/openrouter 上題為「長上下文定價應該更透明」的討論，背後其實是同一個原因：路由、快取、推理 Token 和長上下文定價，都會讓本地估算逐漸偏離實際帳單。Activity 儀表板記錄的用量才是權威數字；如果你選擇自建系統，應該拿它來核對，而不是只相信自己維護的價格表。
一位使用這個平台六個月的開發者還分享了一個更簡單的歸因方法：在請求加上 X-Title 標頭，讓每個應用程式或實驗都能以自己的名稱出現在 Activity 裡。如果你的支出早已分散在多家供應商，而不是集中於單一路由器，使用統一 API 的服務（包括 AIReiter）則能在問題一開始就先把彙整工作整合起來。
常見問題
使用 Activity 儀表板需要管理金鑰嗎？
不需要。儀表板在一般帳戶登入狀態下就能使用；只有 Analytics API 端點（/api/v1/analytics/meta 和 /api/v1/analytics/query）需要管理金鑰。
呼叫 OpenRouter Analytics API 需要付費嗎？
教學將 Analytics 流程描述為唯讀且免費：你查詢的是自己的用量記錄，不是按呼叫次數付費。不過，這些記錄所代表的推論費用仍然要照付。
OpenRouter 的 Activity 資料可以追溯多久？
較舊的 /api/v1/activity 端點涵蓋前 30 個已完成的 UTC 日。新版 Analytics API 文件沒有說明資料保留期限（範例查詢涵蓋一個月），因此長期歷史資料仍應視為未經確認；需要保留的內容，請匯出 CSV。
為什麼我在 Activity 記錄裡看不到提示和回應？
只有在請求當下已啟用私人輸入／輸出記錄，才會保存提示與完成內容的詳細資料——官方公告說得很清楚，未啟用這項功能就無法取得歷史提示內容。用量總數會被記錄，內容則必須主動選擇是否記錄。
別忘了把這項取捨算進去
以上功能今天都能直接使用，光是第一組查詢就足以證明花五分鐘設定是值得的。真正需要留意的是規格漂移：這是一個標示為 Beta 的功能，支援的指標和維度可能改變；OpenRouter 也要求自動化流程先重新讀取 /meta，再相信回傳結構。與其把欄位名稱硬編碼，不如在排程工作中加入 Meta 檢查，這樣即使 API 還在成長，儀表板帶來的可見性也不會跟著失效。
延伸閱讀： OpenRouter 自動路由指南 · 最適合程式設計的免費 OpenRouter 模型 · OpenRouter 價格指南