Paritok token gateway 能省 coding agent 帳單嗎？

Paritok 如何處理請求

Paritok 是 token gateway，也就是位於 coding agent 與模型 API 之間的 proxy。它會先壓縮每個請求，再轉送出去。您的 agent 會與 http://127.0.0.1:8080 通訊，而不是直接與 provider 通訊。proxy 會改寫工具 schema、檔案讀取內容、工具輸出及較早的對話回合，將較小的 payload 傳送至上游，然後原封不動地交回回應。

Provider 會根據抵達 provider 的內容向您計費，因此 payload 越小，帳單越低。這就是整個概念。這與「context 可以維持更久」是不同的主張，也正是這項工具值得關注的原因，而不只是讓內容更整齊。

這個專案仍處於早期階段。它最初的公開 tags 日期為 July 2026，目前的 tag 是 v1.3.0，日期為 5 August 2026。權重與 gateway 程式碼採用 Apache 2.0 授權。壓縮模型是 Qwen3-4B-Instruct-2507 上的 LoRA（low-rank adaptation）adapter，使用取自真實 coding-agent 軌跡的 45,000 筆 teacher-distilled samples 進行訓練。

為何這不是內容截斷

截斷會刪除內容。當代理程式接近內容限制而捨棄最早的回合時，它在第 3 回合讀取的檔案就不見了。如果第 20 回合需要該檔案，就必須再次讀取，因此這些 token 會再次計費。節省的成本只是延後支付。

Paritok 會將一個區段替換成較短的形式及標籤 [REF:id]，並在 proxy 上保留完整文字。模型可透過呼叫 read_original 或 expand_context 還原區段。這會改變失敗模式。截斷器會因遺忘而失敗，而且不會告知你。壓縮器則會將可能遺失資訊的摘要交給模型；當摘要不足時，模型可以要求原始內容。

工具篩選器的行為也相同。篩選後的工具結構描述會被替換為 stub，而不是移除；模型可透過呼叫 gateway_search_tools 還原其中一個工具。這一點很重要，因為永久隱藏工具的篩選器會改變代理程式能執行的操作，而你只能從某個悄悄出錯的工作中得知這件事。

三個控制項，以及其中一個可免費使用

第一個控制項是工具結構描述篩選器。每個請求都會攜帶完整的 tools 陣列。在附加數個 MCP (model context protocol) 伺服器的 Claude Code 回合中，專案測得這個區塊約為 29,000 個 token。篩選器使用 BAAI/bge-small-en-v1.5 這個 130 MB 的嵌入模型，將使用者請求與每個工具描述轉換為嵌入向量，保留相符的工具，並為其餘工具建立 stub。這會將區塊縮減至約 8,000 個 token。該嵌入模型在 CPU 上執行。

第二個控制項是內容壓縮，這部分需要 GPU 上的 4B 模型。檔案讀取內容、工具輸出與歷程記錄會被重寫為原始大小的 25.7%。74% 這個標題數字就是由此而來。請仔細解讀：74% 是遭到壓縮之內容的壓縮率，不是帳單的減幅。

第三個控制項是歷程摘要。內容資訊預算填滿後，較早且超出近期視窗的回合會被摘要，讓長時間工作階段能持續執行，而不會達到上限。

只有第二個控制項需要 GPU。這是本頁最重要的一句話。pip install "paritok[toolselect]" 可讓你在一般 CPU VPS 上使用工具篩選器，而且這是產品中每月不會產生費用的部分。租用 GPU 前，先試試這項功能。

專案測量了什麼，以及使用誰的測試框架

[
  {
    "label": "Paritok-4B-v1",
    "compressed_to_pct": 25.7,
    "quality_retained_pct": 86.5
  },
  {
    "label": "gpt-4.1-mini",
    "compressed_to_pct": 50.2,
    "quality_retained_pct": 85.6
  },
  {
    "label": "gpt-5",
    "compressed_to_pct": 61.9,
    "quality_retained_pct": 93.6
  }
]

這些是專案自行發布的數據，使用自有測試框架，在 SWE-bench Lite 上測量。Paritok-4B-v1 將內容壓縮至原始大小的 25.7%，同時保留未壓縮解題率的 86.5%。使用 gpt-5 作為壓縮器可保留較高的品質，達到 93.6%，但只能壓縮至 61.9%；換句話說，你必須支付前沿模型的價格，才能節省前沿模型的價格。

請如實解讀品質欄位。保留 86.5% 的解題率，表示壓縮執行未能解決原本未壓縮執行所解決的問題，接近每 7 題少解 1 題。在基準測試中，這只是表格裡的一個數字。在你的儲存庫中，這代表一項必須執行兩次的工作。

[
  {
    "label": "Turn 1",
    "saved_pct": 25
  },
  {
    "label": "Turn 5",
    "saved_pct": 39
  },
  {
    "label": "Turn 12",
    "saved_pct": 57
  },
  {
    "label": "Turn 20",
    "saved_pct": 63
  }
]

工作階段持續執行時，端到端節省量會增加，因為歷史內容會累積，而被壓縮的正是歷史內容。專案報告指出，單一回合可節省約 25%，第 5 回合時為 39%，第 20 回合時為 63%。專案也說明了增長停止的位置：在 200,000 token 的預算下，絕對節省量會在每回合約 48,000 token 時趨於平穩，大約落在第 8 至 12 回合之間，因為 context 填滿後，歷史內容便不再增加。廣泛引用的「超過 85%」數字描述的是 context 已飽和的工作階段。這是最佳情況，因此不要以此作為規劃基準。

24GB GPU 能否讓 Paritok 回本？

這種大小的模型通常租用 24GB 顯示卡。以 2026 年 8 月 7 日為準，RTX 4090 24GB 的公開隨選價格中位數為每小時 $0.44，最便宜的方案接近 $0.20。以下採用 $0.44 計算。整月持續執行為 730 小時，因此費用是 $321。若只在工作時間執行，每天 8 小時、每月 22 天，共 176 小時，費用則是 $77。

接著將 token 減少量換算成金額節省。這項減少只套用於輸入 token。輸出 token 會原封不動地通過 proxy，因此完全不受影響。假設輸入 token 佔總費用的 80%，這對 coding agent 而言很常見，並請以自己的帳單驗證這項假設。如此一來，節省金額就是 token 減少比例乘以 0.8。

[
  {
    "label": "Turn 5 (39% saved)",
    "bill_always_on_usd": "1,030",
    "bill_workday_only_usd": 248
  },
  {
    "label": "Turn 20 (63% saved)",
    "bill_always_on_usd": 637,
    "bill_workday_only_usd": 154
  },
  {
    "label": "Saturated (85% saved)",
    "bill_always_on_usd": 472,
    "bill_workday_only_usd": 114
  }
]

在飽和工作階段的 85% 數值下，您可保留帳單的 68%。因此，若 GPU 持續執行，當每月 agent 支出超過約 $472 時即可回本；若在工作時間以外停止 instance，則約為 $114。在第 20 輪的 63% 數值下，這兩個金額分別為 $637 和 $154。在第 5 輪的 39% 數值下，也就是短工作階段的實際情況，您每月需要約 $1,030，租用這張 GPU 才值得。

有兩點讓實際結果優於表格顯示的數值。模型不需要 24GB：q4 build 約佔 2.5GB，bf16 build 約佔 8GB。因此，使用較小的 GPU，或使用您原本就為其他用途持續執行的 GPU 主機，都能降低表中的每個數值。另一個最有效的做法，是在沒有人撰寫程式時停止 instance，因為這會讓租用費降低約四分之三。

有一點會讓結果變差。壓縮階段確實需要運算資源。4B model 壓縮的每個 token 都必須先讀取，再寫出，因此會增加每個 agent 輪次的延遲。若 GPU 按小時租用，這項成本會表現為等待時間，而不是帳單上的獨立項目，因此在實際感受到之前很容易被忽略。

如果您一般是在比較租用 GPU 時數與 API token，GPU VPS 與 API token 之間的損益平衡會以相同方式計算推論本身的成本。

在 VPS 上執行 Paritok gateway

需要 Python 3.10 或更新版本。Ubuntu 24.04 隨附 Python 3.12，因此僅使用 CPU 的部分只需要標準 VPS 映像檔即可。

sudo apt update && sudo apt install -y python3-venv curl
python3 -m venv /opt/paritok/venv
source /opt/paritok/venv/bin/activate
pip install "paritok[proxy]==1.3.0"
pip install "paritok[toolselect]==1.3.0"

固定版本。此儲存庫在 29 July 2026 標記了 v1.2.8，並在 5 August 2026 標記了 v1.3.0。專案以這種速度更新時，不同版本之間可能會重新命名設定金鑰。單獨使用 pip install paritok，或使用 main 的 git clone，下週就可能取得不同的 gateway，也不會留下當時產生測量數據的版本紀錄。

預設後端是 Ollama。先拉取模型，再為它指定 proxy 尋找的簡短名稱。

ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1

由於本機模型會為壓縮的每個區段產生改寫內容，執行時間過長的壓縮程序會表現為 agent 回合停滯；Ollama 對輸出長度設定的 num_predict 上限是限制執行時間的選項。

在旁邊寫入 paritok.yaml。use_gpu_server: false 可確保壓縮工作在自己的硬體上執行。

use_gpu_server: false
local_model:
  base_url: http://localhost:11434

paritok proxy --port 8080 --config-file paritok.yaml

paritok up 是上述操作的捷徑：如果模型不存在，就先拉取模型，然後在 8080 埠啟動 proxy。將 agent 指向 proxy 之前，先檢查 proxy 是否正常運作。

curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats

/health 會傳回包含 "status":"ok" 和版本字串的小型 JSON 物件。/stats 會傳回壓縮總量，以及 proxy 自行估算的節省量。將這項估算視為 proxy 對自身工作的評分，並在 provider 的用量頁面確認數據。

如果重視處理量而非便利性，vLLM 會在基礎模型上提供 adapter 服務。

vllm serve Qwen/Qwen3-4B-Instruct-2507 \
  --enable-lora \
  --lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
  --port 8000

Ollama 較快完成初始設定。vLLM 處理並行請求的能力好得多；只要有多個 agent 共用同一台主機，這項差異就會開始產生影響。Ollama 與 vLLM 的實際差異會決定適合你的方案。

使用 base URL 環境變數，將 agent 指向 proxy。

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080

Codex CLI 會忽略 OPENAI_BASE_URL，因此當 codex.enabled: true 設定在 paritok.yaml 中時，專案會替你寫入 ~/.codex/config.toml。只匯出該變數會讓 Codex 直接與 provider 通訊；工作期間 /stats 計數器始終不變，就是這種情況的徵兆。

讓 listener 只使用 127.0.0.1，不要使用 0.0.0.0。proxy 會將 provider API key 轉送到上游，因此可從網際網路連線的 proxy 等同於該金鑰的公開中繼站：任何找到該埠的人都能使用你的費用，卻不必取得金鑰本身。請透過 SSH tunnel 或 VPN 從筆記型電腦連線，不要開放該埠。

使用 systemd 執行，讓服務在重新開機後仍能持續運作。請依照實際安裝位置調整路徑。

[Unit]
Description=Paritok compression proxy
After=network-online.target

[Service]
User=paritok
WorkingDirectory=/opt/paritok
ExecStart=/opt/paritok/venv/bin/paritok proxy --port 8080 --config-file /opt/paritok/paritok.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

使用 sudo systemctl enable --now paritok 啟用服務，然後再次執行 curl /health。服務單元啟動後立即結束，通常表示設定檔路徑錯誤；journalctl -u paritok -n 50 會列出原因。

託管方案及其代價

該專案也將壓縮功能作為服務提供。設定 use_gpu_server: true 並提供 API key 後，4B model 會在其硬體上執行，費用為每處理 1 million tokens 收取 $0.30；依其文件說明，服務免費提供至 2026 年 8 月底。如此可免除 GPU 租用費，以及上述所有維運工作。

但這也表示，您的 prompts 和 agent 讀取的檔案會離開您的機器，先傳送至第三方，之後才送達 model provider。自架服務的目的正是避免這個中繼環節。設定該 flag 前，請先決定要優先考量哪一項，因為修改 flag 只需變更一行，但其後果並非如此。

如何衡量自己的前後差異

已發布的數據是該專案在 SWE-bench Lite 上，使用該專案測試工具取得的數據。你的儲存庫不是 SWE-bench Lite。請衡量自己的結果。

• 正常執行一週，且不在請求路徑中使用 proxy。從供應商的用量頁面分別記錄 input tokens、cache-read tokens 與 output tokens，各自列出，不要只記錄一個美元總額。
• 下一週在前方加入 proxy，執行相同類型的工作。
• 比較 input 與 cache-read 的數值。Output 應大致持平，因為沒有任何壓縮器會處理 output。如果 output 變動很大，表示除了 proxy 之外還有其他條件改變。
• 計算需要重做的工作數量。這是取捨中的品質部分，但任何 dashboard 都不會回報這項數據。
• 比較總額前，先將第二週的 GPU hours 加入計算。

分開記錄 input 與 output 很重要，因為兩者的定價差異很大，而壓縮器只會處理其中一項。截至 August 2026，Claude Sonnet 4.6 的費用為每 million input tokens $3、每 million output tokens $15；prompt-cache read 則是 input rate 的 10%，也就是每 million $0.30。Input 與 output token 成本的差距決定 input-side compressor 對你是否有價值。Claude Code 的 tokens 實際用在哪裡則能讓你知道 context 的哪一部分大到值得壓縮。

Prompt caching 尤其會讓 tool-filter 的計算變得複雜。Tool block 位於 request 的前端，因此在第一個 turn 之後，通常會以 input price 的 10% 成為 cache hit。從 cached block 中刪除 21,000 tokens 時，每個 turn 可節省 21,000 tokens × $0.30 per million，約為 $0.006，而不是未快取費率所顯示的 $0.063。該專案會在 session 期間固定 filtered block，因此 cached prefix 不會變更。如果每個 turn 都重新選取 tools，便會使該 prefix 失效，成本也會高於節省的金額。

仍未驗證的部分

以上所有效能數據都來自該專案本身。目前沒有 SWE-bench Lite 結果的獨立重現，而第一批 tags 的日期是 July 2026，這份程式碼幾乎沒有實際運作歷史可供參考。壓縮率與保留品質的數據，都是由能從較佳結果中受益的一方所測量。這不代表數據錯誤，只代表它們尚未獲得確認。你應該以不同於自行產生數據的方式看待這些數字。

在責怪自己的設定之前，先了解一項已記錄的行為。工具篩選器使用的 embedding model 會在第一次請求時載入，而不是在啟動時載入。因此，專案文件記載的預熱時間為 10 到 15 秒，之後每次呼叫約需 15 ms。proxy 啟動後先送出一次無作用的請求，第一次真正的 agent 回合就不會看起來像卡住。

你可以在一個下午自行確認 4 件事：proxy 是否能啟動並持續運作、工作期間 /stats 是否持續變動、provider 顯示的 input-token 數值是否確實下降，以及 agent 是否仍能完成工作。對你的設定而言，這些結果比任何已發布的 benchmark 都更具決定性。

至於它與其他工具的關係：自架的 LiteLLM gateway 會在不修改請求內容的情況下進行路由與用量統計，因此兩者解決的是不同問題，也可以串接使用，並讓 Paritok 位於最接近 agent 的位置。如果真正目標是降低帳單，而不是使用這項特定工具，VPS 上 agent 的完整成本控制選項 還包括多項無須付費、可以優先嘗試的變更。

FAQ

Paritok 會降低我的 API 費用，還是只降低 context 使用量？

它會降低費用，因為 proxy 會在請求送達 provider 前先改寫請求，而 provider 會依收到的內容計費。但實際降幅小於標題所暗示的數字。74% 是被壓縮內容的壓縮率。以端到端結果來看，專案回報單一回合約降低 25%，到第 20 回合則約降低 63%；只有輸入 tokens 會變動，輸出 tokens 會原封不動地通過。

要自行代管壓縮模型，需要多少 GPU？

q4 build 約 2.5 GB，bf16 build 約 8 GB，因此模型可放入 24 GB 顯示卡，且仍有充足餘裕。較小的顯示卡也能使用，且會讓損益平衡計算更有利於你。tool-schema filter 完全不需要 GPU：它使用 BAAI/bge-small-en-v1.5，這是可在 CPU 上執行的 130 MB embedding model。在一般 VPS 上安裝 paritok[toolselect]，只需少量 RAM 的成本，就能取得 tool-block reduction。

如果 compressor 移除了 agent 需要的內容，會發生什麼事？

不會移除任何內容。壓縮區段會帶有 [REF:id] 標籤，模型可透過 read_original 或 expand_context 還原完整文字。被 filter 的 tool schemas 會以 stub 取代，而不是刪除；模型可透過 gateway_search_tools 還原其中一個。真正的風險比檔案遺失更不易察覺：模型依據有損摘要運作，卻始終不知道應該要求原始內容。SWE-bench Lite 上 86.5% 的 quality-retained 數據，衡量的就是這項情況。

為什麼我的第一個請求需要 15 秒？

tool filter 背後的 embedding model 會在第一個請求時載入，而不是在啟動時載入。專案文件指出，warm-up 需要 10 到 15 秒；此後每次呼叫約需 15 ms。啟動 proxy 後，使用 curl 傳送一個無關緊要的請求，第一個實際的 agent 回合就不會停滯。

我應該使用代管的 GPU server，而不是自行代管嗎？

這會免除 GPU 租用與維護成本；截至 August 2026，費用為每處理 1 million tokens $0.30。但在請求送達你的 model provider 前，系統也會先將你的 prompts 與 agent 讀取的檔案傳送給第三方。如果你自行代管是為了將程式碼保留在自己控制的基礎架構上，這項設定就違背了你當初開始自行代管的理由。自行代管可讓 context 與 provider API key 都留在你自己的主機上。