了解 token 使用情況
TypeScript 和 Python SDK 使用不同的欄位名稱公開相同的使用資料:- TypeScript 在每個助手訊息上提供每步 token 細分(
message.message.id、message.message.usage),通過結果訊息上的modelUsage提供每個模型的成本,以及結果訊息上的累積總計。 - Python 在每個助手訊息上提供每步 token 細分(
message.usage、message.message_id),通過結果訊息上的model_usage提供每個模型的成本,以及結果訊息上的累積總計(total_cost_usd和usage字典)。
query()呼叫: SDK 的query()函數的一次調用。單次呼叫可能涉及多個步驟(Claude 回應、使用工具、獲取結果、再次回應)。每次呼叫在末尾產生一個result訊息。- 步驟:
query()呼叫中的單個請求/回應週期。每個步驟產生帶有 token 使用情況的助手訊息。 - 會話: 由會話 ID 連結的一系列
query()呼叫(使用resume選項)。會話中的每個query()呼叫獨立報告其自己的成本。
query() 呼叫的訊息流,在每個步驟報告 token 使用情況,並在末尾顯示累積估計:
每個步驟產生助手訊息
當 Claude 回應時,它發送一個或多個助手訊息。在 TypeScript 中,每個助手訊息包含一個嵌套的
BetaMessage(通過 message.message 存取),具有 id 和一個 usage 物件,其中包含 token 計數(input_tokens、output_tokens)。在 Python 中,AssistantMessage 資料類別通過 message.usage 和 message.message_id 直接公開相同的資料。當 Claude 在一個回合中使用多個工具時,該回合中的所有訊息共享相同的 ID,因此按 ID 去重以避免重複計數。結果訊息提供累積估計
當
query() 呼叫完成時,SDK 發出一個結果訊息,其中包含 total_cost_usd 和累積 usage。這在 TypeScript(SDKResultMessage)和 Python(ResultMessage)中都可用。如果您進行多個 query() 呼叫(例如,在多回合會話中),每個結果只反映該個別呼叫的成本。如果您只需要估計的總計,您可以忽略每步使用情況並讀取此單一值。取得查詢的總成本
結果訊息(TypeScript、Python)標記query() 呼叫的代理迴圈的結束。它包含 total_cost_usd,即該呼叫中所有步驟的累積估計成本。這適用於成功和錯誤結果。如果您使用會話進行多個 query() 呼叫,每個結果只反映該個別呼叫的成本。
以下範例遍歷來自 query() 呼叫的訊息流,並在 result 訊息到達時列印總成本:
追蹤每步和每個模型的使用情況
本節中的範例使用 TypeScript 欄位名稱。在 Python 中,等效欄位是AssistantMessage.usage 和 AssistantMessage.message_id 用於每步使用情況,以及 ResultMessage.model_usage 用於每個模型的細分。
追蹤每步使用情況
每個助手訊息包含一個嵌套的BetaMessage(通過 message.message 存取),具有 id 和 usage 物件,其中包含 token 計數。當 Claude 並行使用工具時,多個訊息共享相同的 id 和相同的使用資料。追蹤您已經計數的 ID,並跳過重複項以避免膨脹的總計。
以下範例累積所有步驟中的輸入和輸出 token,每個唯一訊息 ID 只計數一次:
按模型細分使用情況
結果訊息包含modelUsage,一個模型名稱到每個模型 token 計數和成本的映射。當您執行多個模型(例如,子代理使用 Haiku,主代理使用 Opus)並想查看 token 的去向時,這很有用。
以下範例執行查詢並列印每個使用的模型的成本和 token 細分:
累積多個呼叫的成本
每個query() 呼叫返回其自己的 total_cost_usd。SDK 不提供會話級別的總計,因此如果您的應用程式進行多個 query() 呼叫(例如,在多回合會話中或跨不同使用者),請自行累積總計。
以下範例順序執行兩個 query() 呼叫,將每個呼叫的 total_cost_usd 加到運行總計中,並列印每個呼叫和合併的成本:
處理錯誤、快取和 token 差異
為了準確的成本追蹤,請考慮失敗的對話、快取 token 定價和偶爾的報告不一致。解決輸出 token 差異
在罕見情況下,您可能會觀察到具有相同 ID 的訊息的不同output_tokens 值。當發生這種情況時:
- 使用最高值: 一組中的最終訊息通常包含準確的總計。
- 優先使用結果訊息: 結果訊息中的
total_cost_usd反映 SDK 在所有步驟中的累積估計,因此比自己求和每步值更可靠。它仍然是一個估計值,可能與您的實際帳單不同。 - 報告不一致: 在 Claude Code GitHub 儲存庫 提交問題。
追蹤失敗對話的成本
成功和錯誤結果訊息都包含usage 和 total_cost_usd。如果對話在中途失敗,您仍然消耗了到失敗點為止的 token。無論其 subtype 如何,始終從結果訊息讀取成本資料。
追蹤快取 token
Agent SDK 自動使用 prompt caching 來減少重複內容的成本。您不需要自己配置快取。使用物件包含兩個額外的欄位用於快取追蹤:cache_creation_input_tokens:用於建立新快取項目的 token(按比標準輸入 token 更高的費率計費)。cache_read_input_tokens:從現有快取項目讀取的 token(按降低的費率計費)。
input_tokens 分開追蹤以了解快取節省。在 TypeScript 中,這些欄位在 Usage 物件上輸入。在 Python 中,它們作為 ResultMessage.usage 字典中的鍵出現(例如,message.usage.get("cache_read_input_tokens", 0))。
將 prompt 快取 TTL 延長至一小時
當您使用 API 金鑰進行身份驗證或在 Amazon Bedrock、Google Cloud Vertex AI 或 Microsoft Foundry 上執行時,SDK 寫入的快取項目預設使用 5 分鐘的 TTL。如果您的工作負載針對相同的系統提示和上下文執行許多短會話,且它們之間的間隔超過 5 分鐘,快取會在會話之間過期,每個新會話都會支付完整的輸入價格。 要請求快取寫入的 1 小時 TTL,請設定ENABLE_PROMPT_CACHING_1H 環境變數。您可以在 shell 或容器環境中匯出它,或通過 options.env 傳遞它。
以下範例為在 Bedrock 上執行的代理啟用 1 小時 TTL:
相關文件
- TypeScript SDK 參考 - 完整的 API 文件
- SDK 概述 - SDK 入門
- SDK 權限 - 管理工具權限