企業把 AI Agent 接進工作流程之後，帳單往往是第一個說不清楚的東西：花費一路上漲，團隊卻答不出來到底是哪一個 Agent、哪一種模型、哪一筆請求把成本推高的。OpenRouter 8 月 17 日上線的 Activity 儀表板與測試版 Analytics API，瞄準的正是這個問題。
新功能把用量拆到 Agent、模型與單筆請求層級。管理者可以先從總花費、請求數、Token 用量、快取命中率、每百萬 Token 綜合成本這五項指標看起，再一路點進去看到最底層的日誌。OpenRouter 並沒有承諾要幫團隊省錢，它提供的是一套能追到責任邊界的用量視角。
從總額一路看到一筆請求
OpenRouter 的官方說明列出了可以拆分的維度：模型、供應商、API 金鑰、應用程式、使用者、工作區、對話、上下文長度與資料區域等。圖表既能按分鐘、小時、天、週或月彙總，也能一路下鑽到單一筆生成紀錄。
點進日誌之後，一筆紀錄就能顯示推論、快取、網頁搜尋與檔案處理各自的費用，還有延遲、吞吐量、首個 Token 出現的時間、路由與備援資訊。對同時用多個模型、多家供應商的團隊來說，這些欄位把「成本異常」變成一個真的可以查下去的問題：是某個 Agent 的系統提示詞太長，還是快取前綴被打斷，又或者是路由切換拉高了延遲。
Every company that spent the last two years deploying agents is now asking the same question: what are they costing us, and which ones are worth it?
OpenRouter 是這麼說的。儀表板的目的，就是要讓這個問題能落到具體的應用程式與具體的請求上，而不是一直停留在抽象層次。
看得到不等於自動管得住
產品裡還有一個 Guardrails 視圖，用來檢視提示注入與敏感資訊規則攔截、遮蔽或標記請求的情況；Analytics API 則讓團隊可以把同一份數據接進自己的看板。這些工具解決的是可視性，並不是替企業設定預算或審批規則。
這個區分很重要。Agent 一旦被允許呼叫工具，Token 成本就只是支出的其中一層而已；工具呼叫次數、檢索範圍、檔案處理與外部服務的延遲，都會一起改變實際花費。先把數據按 Agent、模型、請求歸位，團隊才有辦法替高成本任務設上限，或是判斷快取與路由策略到底有沒有效。
OpenRouter 這次的更新，把 AI 用量分析從一張總帳單，推進成一條可以被追溯的交易紀錄。對開發主管來說，接下來要看的不是一張漂亮的彙總圖，而是哪些異常請求能被穩定重現、解釋清楚，並且壓回預算之內。
參考來源：OpenRouter 產品公告；核驗 Activity 儀表板、Analytics API 與日誌欄位；CocoLoop。