這裡算的是你貼上的內容。真正的 API 呼叫還會為對話格式本身花掉 token——每則訊息的角色標記與分隔符各佔幾個——再加上你附帶的 tool 或 function schema，以及模型自己的回覆。把這裡的數字當成輸入的下限，而不是最終帳單。

會，而且差距常常不小。GPT-4o 世代用 o200k_base，GPT-4 與 GPT-3.5 用 cl100k_base；新的詞彙表對中日韓文字明顯更有效率。Anthropic 與 Llama 使用完全不同的 tokenizer，這也是本工具不提供它們的原因——與其給一個錯的數字，不如不給。

取決於是誰在管理這段對話。直接呼叫 API 會直接失敗、回一個 context length 錯誤。框架與聊天客戶端通常會先裁切——最常見的是丟掉最舊的訊息，有時會把 system prompt 釘住，有時則改成做摘要。這裡的策略切換就是讓你用自己的對話看見這幾種結果。

沒有固定比例，這正是用猜的會出錯的原因。常見詞常常會合併成一個 token，罕見字則可能要花上好幾個，而 o200k_base 在這方面比 cl100k_base 有效率得多。貼一段有代表性的樣本再切換編碼，看你自己文字上的差異，比套用經驗法則可靠。

算。就預算而言它就是一則普通訊息，而且很長的 system prompt 會和對話歷史搶同一塊空間。它唯一特別的地方只在於多數客戶端不願意丟掉它，這正是這裡「保留 system」策略在模擬的事——釘住它的代價，是得丟掉更多歷史。

不會。編碼詞彙表會下載到你的瀏覽器，計算在你機器上的 Web Worker 內完成。沒有任何帶著你文字的請求、沒有記錄、也沒有任何模型供應商介入——這件事很重要，因為 prompt 裡經常夾帶憑證與客戶資料。