Vercel AI Gateway 新增 Sessions 檢視：看清快取命中率

**摘要：**Vercel 在 2026 年 10 月 18 日為 AI Gateway logs 加入 Sessions 檢視，把零散的請求按 session 分組，並顯示 session affinity 實際把每一筆請求路由到哪個 provider。對於在 gateway 上跑 coding agent 或多輪對話應用的團隊，這代表你終於可以直接看到快取命中率、成本和每一輪的路徑，而不必自己拼湊 log。

為什麼這個檢視值得打開

Session affinity 的核心問題是：prompt cache 存在「實際服務該請求的 provider 帳號」上。如果同一個對話的下一筆請求被路由到別家，cache 是冷的，你得為整個 prompt 再付一次全額。Session affinity 的做法是把對話固定在已持有 cache 的 provider 上，而且在文字和 chat 請求上預設開啟，既有流量不用改程式碼就受益。

但這件事一直有個盲點：行為發生在 gateway 內部，你只能從帳單和延遲間接推測它有沒有生效。新的 Sessions 檢視補上這一塊。每一列顯示跑這個 session 的 client（例如 Claude Code、Codex 或 Cursor）、成本、使用的模型與 provider，以及整個對話中輸入被快取的比例。

點開一個 session 能看到什麼

根據 Vercel 的 changelog，打開單一 session 後可以看到快取命中率、時間長度，以及完整路徑：每一輪用了哪個模型、花了多少時間，以及目前和先前的 provider 是誰。也可以按輪數、client、模型、provider、認證方式或成本過濾；單輪 session 預設隱藏，要清除最小輪數篩選才會出現。

對除錯很實用的一點：如果某個 session 的快取命中率異常低，路徑會直接告訴你是因為中途換了 provider，還是 prompt 前綴被改寫。

要怎麼確保請求被正確分組

Session affinity 預設會嘗試識別 session，但最可靠的方式是自己在每筆請求帶上相同的 session ID。依官方文件，gateway 依序檢查多個來源：providerOptions.gateway 裡的 sessionId、x-session-id header、x-session-affinity header、OpenAI 的 prompt_cache_key 欄位，以及 Claude Code 自動帶的 x-claude-code-session-id。

用 AI SDK 的話是這樣：

import { streamText } from 'ai';

const result = streamText({
  model: 'anthropic/claude-sonnet-5',
  prompt: 'Hello world',
  providerOptions: {
    gateway: {
      sessionId: 'sess_8f3KQ2vXr9mT',
    },
  },
});

如果用 OpenAI 或 Anthropic 的相容 API，把 x-session-id 設成 SDK client 的預設 header 即可。session ID 要用不透明、不超過 256 字元的值，不要放個人資料，也不要跨不相關的對話重用。

沒帶 session ID 的請求，gateway 會對對話開頭做 fingerprint（混入 team ID 的 SHA-256 雜湊）自動分組。要注意：兩個以相同 system prompt、工具集和第一則訊息開場的對話會共享 fingerprint，所以用模板訊息開場的腳本可能被併進同一個 session。

它不會覆蓋你的路由規則

Session affinity 是在你既有的篩選之後才運作：被 only 排除的 provider 不會被拉回來，被判定為不健康的 provider 不會被優先。如果你想完全保留自己的 order，可以設 sessionAffinity: false。這點在合規設定（例如零資料保留）特別重要——文件明確指出篩選永遠先於 affinity。

另外，affinity 只適用於文字和 chat 請求；embedding、圖片和 realtime session 沒有 prompt cache 可保溫，不在範圍內。

實際的下一步

如果你已經像先前介紹過的那樣把流量集中到 Vercel AI Gateway，值得做的事很具體：檢查你的 agent 是否穩定帶上 session ID，然後到 Sessions 檢視確認快取命中率。命中率低但路徑顯示 provider 沒換，問題通常出在 prompt 中段被改寫，這時可以參考文件中的 cache anchor 機制，而不是先怪路由。

參考來源

原始貼文

在 X 上查看原貼文