作者： Paritok 能讓 coding agent 帳單更便宜嗎？
Paritok 是位於 coding agent 與 model API 之間的 token gateway，專案宣稱可減少 74% token。了解壓縮機制與損益平衡計算。
Paritok 如何處理請求
Paritok 是 token gateway：位於 coding agent 與 model API 之間的 proxy，會先壓縮每個請求，再轉送給 API。你的 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。weights 與 gateway code 採用 Apache 2.0 授權。壓縮模型是以 Qwen3-4B-Instruct-2507 為基礎的 LoRA（low-rank adaptation）adapter，使用取自真實 coding-agent trajectories 的 45,000 筆 teacher-distilled samples 進行訓練。
這不是內容裁剪
裁剪會刪除內容。當 agent 接近內容上限而丟棄最早的回合時，它在第 3 回合讀取的檔案就不見了。如果第 20 回合需要再次使用該檔案，就必須重新讀取，因此這些 token 會再次產生費用。這項節省只是暫時借用。
Paritok 會將一個區段替換成較短的內容與標籤 [REF:id]，並將完整文字保留在 proxy 上。模型可透過呼叫 read_original 或 expand_context 還原該區段。這會改變失敗模式。裁剪器因遺忘而失效，而且不會告知你。壓縮器則可能提供有損摘要；當摘要不足時，模型可以要求原始內容。
工具篩選器的行為也相同。篩選後的工具 schema 會以 stub 取代，而不是移除，模型可透過呼叫 gateway_search_tools 還原其中一個工具。這一點很重要，因為永久隱藏工具的篩選器會改變 agent 能執行的工作，而你只能從某項工作在沒有明顯錯誤的情況下失敗，才發現這件事。
三個槓桿，以及其中一個不需付費
第一個槓桿是工具 schema 篩選器。每個請求都會帶上完整的 tools 陣列。在掛接數個 MCP（model context protocol）伺服器的 Claude Code 回合中，這個區塊約占 29,000 個 token。篩選器使用 BAAI/bge-small-en-v1.5（一個 130 MB 的 embedding model）嵌入使用者請求與每個工具說明，保留相符的工具，並將其餘工具替換為 stub。這會將區塊縮減至約 8,000 個 token。該 embedding model 在 CPU 上執行。
第二個槓桿是內容壓縮，這部分需要 GPU 上的 4B model。檔案讀取結果、工具輸出與歷史內容會被重寫為原始大小的 25.7%。74% 這個標題數字就是由此而來。請仔細理解：74% 是遭到壓縮之內容的壓縮率，不是帳單的減幅。
第三個槓桿是歷史摘要。當 context 預算用滿後，較早且超出近期視窗的回合會被摘要，讓長時間工作階段得以持續執行，而不會碰到上限。
只有第二個槓桿需要 GPU。這是本頁最重要的一句話。pip install "paritok[toolselect]" 讓你能在一般 CPU VPS 上使用工具篩選器，而且這是該產品中每月不需付費的部分。先試用它，再考慮租用 GPU。
專案測量的內容，以及使用的測試框架
The data behind this chart
[
{
"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%；換句話說，為了節省 frontier 價格，你仍須支付 frontier 價格。
請如實解讀品質欄位。保留 86.5% 的解題率，表示壓縮執行失敗的問題中，有些是未壓縮執行成功解決的，接近每 7 題少解決 1 題。在基準測試中，這只是表格裡的一個數字。但在你的 repository 中，這代表你必須執行兩次的工作。
The data behind this chart
[
{
"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 的成本？
這種大小的模型通常使用 24 GB 顯示卡租用方案。截至 2026 年 8 月 7 日，24 GB RTX 4090 的公開隨選租用價格中位數為每小時 $0.44，最便宜的方案接近 $0.20。以下採用 $0.44 計算。整月持續執行為 730 小時，因此是 $321。若只在工作時間執行，每天 8 小時、每月 22 天，則為 176 小時，也就是 $77。
接著將 token 減少量換算成金額減少量。減少量只適用於輸入 token。輸出 token 會原樣通過 proxy，因此完全不變。假設輸入 token 占總金額的 80%，這對 coding agent 而言很常見；請再以自己的帳單核對此假設。如此一來，節省金額就是 token 減少量乘以 0.8。
The data behind this chart
[
{
"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 的支出，租用顯示卡才值得。
有兩點讓實際結果優於表格所示。模型不需要 24 GB：q4 build 約需 2.5 GB，bf16 build 約需 8 GB。因此，使用較小的顯示卡，或使用原本就為其他用途執行的 GPU box，都能降低圖表中的每個數值。另一個關鍵是沒有人撰寫程式時就停止 instance，因為這會讓租用成本減少約四分之三。
有一點會讓結果變差。壓縮流程確實需要運算。4B model 壓縮的每個 token 都必須先讀取，再寫入，因此會增加每次 agent 回合的延遲。若按小時租用顯示卡，這項成本會以等待時間呈現，而不會出現在帳單的明細中，因此直到實際感受到延遲前，很容易忽略它。
如果你正在一般性比較租用 GPU 時數與 API token，GPU VPS 與 API token 的損益平衡會以相同方式計算推論本身的成本。
在 VPS 上執行 Paritok gateway
需要 Python 3.10 或更新版本。Ubuntu 24.04 隨附 Python 3.12，因此純 VPS 映像檔已足以執行僅使用 CPU 的部分。
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"固定版本。該 repository 於 29 July 2026 標記了 v1.2.8，並於 5 August 2026 標記了 v1.3.0。專案若以這種速度變更，會在不同版本之間重新命名設定鍵。直接使用 pip install paritok，或使用 main 的 git clone，下週就可能取得不同的 gateway，也無法追溯產生測量數據的版本。
預設 backend 是 Ollama。先下載 model，再使用 proxy 尋找的簡短名稱為它命名。
ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1在旁邊寫上 paritok.yaml。use_gpu_server: false 會讓壓縮作業留在你自己的硬體上執行。
use_gpu_server: false
local_model:
base_url: http://localhost:11434paritok proxy --port 8080 --config-file paritok.yamlparitok up 是上述操作的快捷方式：如果 model 尚未存在，就先下載它，然後在 port 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 的使用量頁面上交叉確認。
若重視 throughput 而非便利性，vLLM 會在 base model 上提供 adapter。
vllm serve Qwen/Qwen3-4B-Instruct-2507 \
--enable-lora \
--lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
--port 8000Ollama 較快即可部署完成。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:8080Codex 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 等同於該 key 的 open relay：任何找到該 port 的人都能花費你的資金，而不必看見 key 本身。請改用 SSH tunnel 或 VPN 從 laptop 連線，不要開放該 port。
使用 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。若 unit 啟動後立即結束，通常表示設定檔路徑錯誤；journalctl -u paritok -n 50 會顯示原因。
代管方案及其代價
該專案也以服務形式提供壓縮功能。使用 API key 設定 use_gpu_server: true 後，4B model 會在其硬體上執行；依其官方文件，費用為每處理 1 million tokens 收費 $0.30，並免費提供至 2026 年 8 月底。這可免除上述 GPU 租用費與所有維運工作。
但這也表示，在送達 model provider 之前，您的提示與 agent 讀取的檔案會先離開您的機器並傳送至第三方。Self-hosting 的目的正是避免這個中繼環節。設定該 flag 前，請先決定要優先考量哪一項，因為 flag 只需修改一行，但其影響並非如此。
如何量測自己的前後差異
已發布的數字是該專案在 SWE-bench Lite 上，使用該專案測試工具所取得的數字。你的 repository 並不是 SWE-bench Lite。請量測自己的結果。
- 先正常執行一週，且不要在路徑中加入 proxy。從供應商的用量頁面，將 input tokens、cache-read tokens 和 output tokens 分別記錄在不同的行中，不要只記錄一個美元總額。
- 下一週在前方加入 proxy，執行相同類型的工作，並採用相同的記錄方式。
- 比較 input 和 cache-read 的數值。output 應大致持平，因為壓縮不會影響它。如果 output 變動很大，表示除了 proxy 之外還有其他因素改變。
- 統計必須重做的工作數量。這是取捨中的品質部分，任何 dashboard 都不會回報這項數據。
- 比較總額前，先將第二週的 GPU hours 加入成本。
分開計算 input 和 output 很重要，因為兩者的定價差異很大，而 compressor 只會處理其中一項。截至 August 2026，Claude Sonnet 4.6 的費用為每 1 million 個 input tokens $3、每 1 million 個 output tokens $15；prompt-cache read 則為 input rate 的 10%，即每 1 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 可按每 1 million 個 $0.30 的價格節省 21,000 個 tokens，約為 $0.006，而不是未快取價格所估算的 $0.063。該專案會在整個 session 中固定 filtered block，因此 cached prefix 不會變更。若每個 turn 都重新選取 tools，便會使該 prefix 失效，成本反而高於節省的金額。
仍未驗證的事項
以上每一項效能數據都來自專案本身。目前沒有獨立重現 SWE-bench Lite 結果的資料；而且第一批 tags 的日期是 July 2026，這份程式碼幾乎沒有足夠的實際運作歷史可供參考。壓縮率與保留品質數據都是由能從良好結果中受益的一方測量。這不代表數據錯誤，而是代表它們尚未獲得確認。你應以不同於自行產生數據的方式看待這些數字。
在將問題歸咎於自己的設定前，請先了解一項已記錄的行為。工具的 filter 所使用的 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，這是一個 130 MB、可在 CPU 上執行的 embedding model。在一般 VPS 上安裝 paritok[toolselect]，只需少量 RAM 的成本即可取得 tool-block reduction。
如果 compressor 移除了 agent 需要的內容，會發生什麼事？
不會移除任何內容。壓縮區段會帶有 [REF:id] 標籤，而模型可使用 read_original 或 expand_context 還原完整文字。遭篩選的 tool schemas 會以 stub 取代，而非刪除；模型可使用 gateway_search_tools 還原其中一個。真正的風險比檔案遺失更不明顯：模型會根據有損摘要工作，卻不會察覺自己應要求取得原文。SWE-bench Lite 上 86.5% 的品質保留率，衡量的就是這項情況。
為什麼我的第一個請求需要 15 秒？
tool filter 背後的 embedding model 會在第一個請求時載入，而不是在啟動時載入。專案文件指出，預熱時間為 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 都留在你自己的主機上。