Bởi Paritok token gateway có giúp giảm phí coding agent?
Paritok nén file read và tool output trước khi gửi lên model API, project tuyên bố giảm 74% token. Xem cơ chế và cách tính điểm hòa vốn.
Paritok làm gì với một request
Paritok là một token gateway: một proxy nằm giữa coding agent và model API, nén từng request trước khi chuyển tiếp. Agent của bạn giao tiếp với http://127.0.0.1:8080 thay vì provider. Proxy viết lại tool schema, nội dung đọc từ file, output của tool và các lượt trao đổi cũ, gửi payload nhỏ hơn lên upstream, rồi trả reply về nguyên trạng.
Provider tính phí dựa trên dữ liệu nhận được tại provider, nên payload nhỏ hơn sẽ giúp hóa đơn thấp hơn. Đó là toàn bộ ý tưởng. Điều này khác với tuyên bố rằng “context của bạn tồn tại lâu hơn”, và đó là lý do công cụ này đáng quan tâm chứ không chỉ giúp dữ liệu gọn hơn.
Project này còn mới. Các tag public đầu tiên có ngày tháng 7 năm 2026 và tag hiện tại là v1.3.0, phát hành ngày 5 tháng 8 năm 2026. Weights và gateway code được cấp phép theo Apache 2.0. Model nén là một adapter LoRA (low-rank adaptation) trên Qwen3-4B-Instruct-2507, được train bằng 45,000 mẫu do teacher chắt lọc từ các trajectory thực tế của coding agent.
Vì sao đây không phải là cắt bớt context
Cắt bớt là xóa. Khi agent gần chạm giới hạn context và loại bỏ các lượt trao đổi cũ nhất, file mà nó đã đọc ở lượt 3 sẽ biến mất. Nếu cần file đó ở lượt 20, nó phải đọc lại file, nên bạn phải trả phí cho các token đó lần thứ hai. Khoản tiết kiệm chỉ là một khoản vay.
Paritok thay một segment bằng dạng ngắn hơn kèm tag [REF:id], đồng thời giữ toàn bộ văn bản trên proxy. Model khôi phục segment bằng cách gọi read_original hoặc expand_context. Cách này thay đổi kiểu lỗi. Trimmer lỗi do quên và không bao giờ báo cho bạn. Compressor lỗi do cung cấp cho model một bản tóm tắt bị mất thông tin; khi bản tóm tắt không đủ, model có thể yêu cầu lại bản gốc.
Tool filter cũng hoạt động theo cách tương tự. Các tool schema bị filter được thay bằng stub thay vì bị xóa, và model khôi phục một schema bằng cách gọi gateway_search_tools. Điều này quan trọng vì filter ẩn vĩnh viễn một tool sẽ thay đổi những gì agent có thể thực hiện, và bạn chỉ biết điều đó qua một task âm thầm thất bại.
Ba đòn bẩy và đòn bẩy miễn phí
Đòn bẩy thứ nhất là bộ lọc tool schema. Mỗi request chứa toàn bộ mảng tools. Trong một lượt Claude Code có gắn vài MCP (model context protocol) server, project đo được block này ở khoảng 29,000 token. Bộ lọc dùng BAAI/bge-small-en-v1.5, một embedding model 130 MB, để tạo embedding cho request của người dùng và mô tả của từng tool, giữ lại các tool phù hợp rồi thay phần còn lại bằng stub. Block giảm xuống khoảng 8,000 token. Embedding model này chạy trên CPU.
Đòn bẩy thứ hai là nén nội dung. Đây là phần cần model 4B chạy trên GPU. Nội dung đọc từ file, output của tool và history được rút gọn còn 25.7% kích thước ban đầu. Đây là nguồn gốc của con số 74% được nêu. Hãy đọc kỹ: 74% là tỷ lệ nén trên phần nội dung được nén, không phải mức giảm trên hóa đơn của bạn.
Đòn bẩy thứ ba là tóm tắt history. Khi context budget đầy, các lượt nằm ngoài cửa sổ gần đây sẽ được tóm tắt để session dài tiếp tục chạy thay vì chạm giới hạn.
Chỉ đòn bẩy thứ hai cần GPU. Đây là câu quan trọng nhất trên trang này. pip install "paritok[toolselect]" cung cấp bộ lọc tool trên một CPU VPS thông thường, và đây là một nửa sản phẩm không làm bạn phát sinh chi phí hằng tháng. Hãy thử nó trước khi thuê một card.
Các chỉ số dự án đo được và harness được sử dụng
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
}
]Đây là các số liệu do chính dự án công bố, được đo bằng harness của dự án trên SWE-bench Lite. Paritok-4B-v1 nén nội dung xuống còn 25.7% kích thước ban đầu, đồng thời giữ lại 86.5% tỷ lệ giải thành công so với khi không nén. Dùng gpt-5 làm bộ nén giữ lại chất lượng cao hơn, 93.6%, nhưng chỉ nén xuống còn 61.9%, nghĩa là bạn phải trả mức giá frontier để tiết kiệm chi phí frontier.
Hãy đọc trung thực cột chất lượng. Giữ lại 86.5% tỷ lệ giải thành công nghĩa là các lượt chạy đã nén thất bại ở những bài toán mà các lượt chạy không nén giải được, gần tương đương 1 trên 7 bài. Trên benchmark, đó là một con số trong bảng. Trong repository của bạn, đó là một task phải chạy lại 2 lần.
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
}
]Mức tiết kiệm đầu cuối tăng theo thời gian chạy session, vì history tích lũy và history là phần được nén. Dự án báo cáo mức tiết kiệm khoảng 25% ở một turn, 39% ở turn 5 và 63% ở turn 20. Dự án cũng nêu rõ khi mức tăng dừng lại: với budget 200,000 token, mức tiết kiệm tuyệt đối ổn định ở khoảng 48,000 token mỗi turn, vào khoảng turn 8 đến 12, vì khi context đầy thì history không còn tăng. Con số thường được trích dẫn là "trên 85%" mô tả các session đã bão hòa context. Đây là trường hợp tốt nhất, vì vậy không nên lập kế hoạch dựa trên con số này.
Một GPU 24GB có đáng để chạy Paritok không?
Card 24GB là loại máy thường được thuê để chạy model có kích thước này. Tính đến ngày 7 tháng 8 năm 2026, giá on-demand trung vị được công bố cho RTX 4090 24GB là $0.44 mỗi giờ, còn các listing rẻ nhất ở mức gần $0.20. Lấy mức $0.44. Nếu chạy liên tục cả tháng, tổng thời gian là 730 giờ, tương đương $321. Nếu chỉ chạy trong giờ làm việc, 8 giờ mỗi ngày trong 22 ngày, tổng thời gian là 176 giờ, tương đương $77.
Bây giờ quy đổi mức giảm token thành mức giảm chi phí. Mức giảm chỉ áp dụng cho input token. Output token đi qua proxy mà không bị thay đổi, nên chi phí của chúng không thay đổi. Giả sử input token chiếm 80% tổng chi phí của bạn, đây là mức thường thấy với coding agent, rồi đối chiếu giả định này với hóa đơn thực tế. Khoản tiết kiệm của bạn khi đó bằng mức giảm token nhân với 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
}
]Ở mức 85% khi session chạy bão hòa, bạn giữ lại 68% hóa đơn. Vì vậy, card chạy liên tục sẽ tự hoàn vốn khi chi phí agent hàng tháng vượt khoảng $472, hoặc khoảng $114 nếu bạn dừng instance ngoài giờ làm việc. Ở mức 63% tại turn-20, các ngưỡng này lần lượt là $637 và $154. Ở mức 39% tại turn-5, tương ứng với các session ngắn trong thực tế, bạn cần chi khoảng $1,030 mỗi tháng thì việc thuê card mới đáng thực hiện.
Có 2 yếu tố khiến kết quả thực tế tốt hơn bảng trên. Model không cần 24GB: bản q4 khoảng 2.5GB, còn bản bf16 khoảng 8GB. Vì vậy, card nhỏ hơn hoặc GPU box bạn đã chạy cho một mục đích khác sẽ làm giảm mọi con số trong biểu đồ đó. Ngoài ra, dừng instance khi không có ai coding là đòn bẩy lớn nhất, vì việc này giảm chi phí thuê khoảng ba phần tư.
Có một yếu tố khiến kết quả xấu hơn. Bước compression thực sự tiêu tốn tài nguyên. Mỗi token mà model 4B compress phải được model đọc rồi ghi lại, làm tăng latency của mỗi agent turn. Với card được thuê theo giờ, chi phí này xuất hiện dưới dạng thời gian chờ chứ không hiện thành một dòng trên hóa đơn. Vì vậy, bạn dễ bỏ qua nó cho đến khi trực tiếp cảm nhận được độ trễ.
Nếu bạn đang so sánh số giờ thuê GPU với API token nói chung, phần tính điểm hòa vốn giữa GPU VPS và API token thực hiện phép tính tương tự cho chính quá trình inference.
Chạy Paritok gateway trên VPS
Cần Python 3.10 trở lên. Ubuntu 24.04 đi kèm Python 3.12, nên image VPS mặc định là đủ cho phần chỉ dùng 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"Cố định version. Repository gắn tag v1.2.8 vào ngày 29 July 2026 và v1.3.0 vào ngày 5 August 2026. Một project thay đổi với tốc độ đó có thể đổi tên config key giữa các release. Một pip install paritok trống, hoặc một git clone của main, sẽ đưa cho bạn một gateway khác vào tuần sau và không lưu lại gateway nào đã tạo ra các số liệu bạn đo.
Backend mặc định là Ollama. Pull model, sau đó đặt cho model short name mà proxy đang tìm.
ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1Vì local model tạo một bản rewrite cho từng segment mà nó nén, một compression pass chạy quá lâu sẽ biểu hiện thành một agent turn bị treo. Giới hạn num_predict của Ollama đối với độ dài output là tham số giới hạn thời gian này.
Viết paritok.yaml bên cạnh nó. use_gpu_server: false là thứ giữ quá trình compression chạy trên phần cứng của chính bạn.
use_gpu_server: false
local_model:
base_url: http://localhost:11434paritok proxy --port 8080 --config-file paritok.yamlparitok up là shortcut cho toàn bộ các bước trên: nó pull model nếu model chưa có và khởi động proxy trên port 8080. Kiểm tra proxy trước khi trỏ agent vào đó.
curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats/health trả về một JSON object nhỏ chứa "status":"ok" và một version string. /stats trả về tổng số compression cùng với ước tính riêng của proxy về lượng dữ liệu đã tiết kiệm. Hãy xem ước tính đó là proxy tự đánh giá kết quả của mình, rồi đối chiếu với trang usage của provider.
Nếu ưu tiên throughput thay vì sự tiện lợi, vLLM sẽ serve adapter trên base model.
vllm serve Qwen/Qwen3-4B-Instruct-2507 \
--enable-lora \
--lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
--port 8000Ollama dễ triển khai nhanh hơn. vLLM xử lý concurrent request tốt hơn nhiều. Điều này bắt đầu quan trọng ngay khi có nhiều hơn một agent dùng chung máy. Khác biệt thực tế giữa Ollama và vLLM sẽ quyết định lựa chọn trong trường hợp này.
Trỏ agent vào proxy bằng các biến môi trường base URL.
export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080Codex CLI bỏ qua OPENAI_BASE_URL, nên project sẽ ghi ~/.codex/config.toml cho bạn khi codex.enabled: true được đặt trong paritok.yaml. Chỉ export biến này sẽ khiến Codex kết nối thẳng đến provider. Dấu hiệu là counter /stats không bao giờ tăng trong lúc bạn làm việc.
Giữ listener trên 127.0.0.1, tuyệt đối không dùng 0.0.0.0. Proxy forward provider API key của bạn lên upstream. Vì vậy, proxy có thể truy cập từ Internet sẽ trở thành open relay cho key đó: bất kỳ ai tìm thấy port đều có thể tiêu tiền của bạn mà không cần thấy chính key. Thay vì mở port, hãy truy cập proxy từ laptop qua SSH tunnel hoặc VPN.
Chạy proxy dưới systemd để proxy vẫn hoạt động sau reboot. Điều chỉnh các path cho đúng với bản cài đặt của bạn.
[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.targetEnable service bằng sudo systemctl enable --now paritok, sau đó curl /health lần nữa. Một unit khởi động rồi thoát ngay thường có nghĩa là path đến config file bị sai. journalctl -u paritok -n 50 sẽ in ra nguyên nhân.
Tùy chọn hosted và chi phí phải trả
Project này cũng cung cấp tính năng compression dưới dạng service. Cấu hình use_gpu_server: true bằng một API key để model 4B chạy trên phần cứng của họ. Chi phí là $0.30 cho mỗi triệu token được xử lý. Theo tài liệu của project, dịch vụ này miễn phí đến hết tháng 8 năm 2026. Cách này loại bỏ chi phí thuê GPU và toàn bộ công việc vận hành nêu trên.
Tuy nhiên, prompt và các file agent đọc sẽ rời khỏi máy của bạn và được gửi đến bên thứ ba trước khi đến model provider. Self-hosting tồn tại để tránh chính bước trung chuyển đó. Hãy quyết định trước bạn muốn tối ưu yếu tố nào trong hai yếu tố này rồi mới bật flag. Thay đổi flag chỉ cần một dòng, nhưng hệ quả thì không đơn giản như vậy.
Cách đo lường trước và sau trên hệ thống của bạn
Các con số được công bố là số liệu của project, được đo bằng harness của project trên SWE-bench Lite. Repository của bạn không phải SWE-bench Lite. Hãy tự đo lường.
- Chạy một tuần bình thường, không có proxy trên đường đi. Ghi input tokens, cache-read tokens và output tokens thành các dòng riêng từ trang usage của provider, không gộp thành một tổng tiền.
- Chạy tuần tiếp theo với proxy đứng trước, thực hiện cùng loại công việc.
- So sánh các dòng input và cache-read. Output phải gần như không đổi vì không có gì nén được output. Nếu output thay đổi nhiều, đã có yếu tố khác ngoài proxy thay đổi.
- Đếm số task bạn phải làm lại. Đây là phần chất lượng của sự đánh đổi, và không dashboard nào báo cáo được.
- Cộng số giờ GPU vào tuần thứ hai trước khi so sánh tổng chi phí.
Tách input khỏi output rất quan trọng vì hai loại token này có mức giá rất khác nhau, trong khi compressor chỉ tác động đến một loại. Tính đến August 2026, Claude Sonnet 4.6 có giá $3 cho mỗi million input tokens và $15 cho mỗi million output tokens; cache read của prompt có giá bằng 10% mức giá input, tức $0.30 cho mỗi million token. Chênh lệch chi phí giữa input token và output token quyết định input-side compressor có đáng dùng với bạn hay không. Token của Claude Code thực sự được dùng ở đâu cho biết phần nào trong context đủ lớn để đáng nén.
Prompt caching đặc biệt làm phức tạp việc tính toán tool-filter. Tool block nằm ở đầu request, nên sau turn đầu tiên, block này thường là cache hit với mức giá bằng 10% giá input. Việc cắt 21,000 token khỏi một block đã được cache chỉ tiết kiệm 21,000 token với giá $0.30 cho mỗi million token, tương đương khoảng $0.006 mỗi turn, thay vì $0.063 nếu tính theo mức giá khi chưa cache. Project giữ nguyên filtered block trong suốt session để cached prefix không thay đổi. Nếu filter chọn lại tool ở mỗi turn, filter sẽ làm mất hiệu lực của prefix đó và chi phí phát sinh sẽ cao hơn phần tiết kiệm.
Những gì vẫn chưa được xác minh
Mọi số liệu hiệu năng ở trên đều lấy từ chính project. Chưa có bên độc lập nào tái hiện kết quả SWE-bench Lite, và vì các tag đầu tiên có ngày tháng vào tháng 7 năm 2026, code cũng chưa có nhiều lịch sử vận hành. Tỷ lệ nén và con số chất lượng được giữ lại đều do chính bên được lợi nếu các số liệu này trông tốt thực hiện đo lường. Điều đó không có nghĩa là chúng sai. Chỉ là chúng chưa được xác nhận, và bạn nên đánh giá chúng khác với một số liệu do chính bạn tạo ra.
Có một hành vi đã được ghi lại mà bạn nên biết trước khi đổ lỗi cho setup của mình. Embedding model mà tool filter sử dụng chỉ được load ở request đầu tiên, không phải lúc startup. Vì vậy, project ghi nhận thời gian warm-up từ 10 đến 15 giây, sau đó mỗi lần gọi mất khoảng 15 ms. Hãy gửi một request bỏ đi sau khi proxy khởi động. Khi đó, lượt agent thực tế đầu tiên sẽ không có vẻ bị treo.
Bạn có thể tự kiểm tra 4 điều trong một buổi chiều: proxy có khởi động và duy trì hoạt động hay không, /stats có thay đổi trong khi bạn làm việc hay không, dòng input-token của provider có thực sự giảm hay không, và agent có vẫn hoàn tất công việc hay không. Những điều này quyết định mức độ phù hợp với setup của bạn tốt hơn nhiều so với bất kỳ benchmark được công bố nào.
Về vị trí của công cụ này bên cạnh các tooling khác: một LiteLLM gateway tự host định tuyến và đo lường request mà không thay đổi nội dung, nên hai công cụ giải quyết 2 vấn đề khác nhau và có thể chạy nối tiếp, trong đó Paritok nằm gần agent nhất. Nếu mục tiêu thực sự là giảm hóa đơn thay vì dùng cụ thể tool này, tập hợp rộng hơn các biện pháp kiểm soát chi phí cho agent trên VPS bao gồm một số thay đổi mà bạn có thể thử trước và không tốn chi phí.
FAQ
Paritok có giảm hóa đơn API hay chỉ giảm mức sử dụng context?
Nó giảm hóa đơn, vì proxy viết lại request trước khi request đến provider, và provider tính phí dựa trên dữ liệu nhận được. Mức giảm thực tế nhỏ hơn con số nổi bật được công bố. Con số 74% là tỷ lệ nén trên phần nội dung được nén. Tính từ đầu đến cuối, project báo cáo mức giảm khoảng 25% ở một lượt và 63% ở lượt 20; chỉ input token mới thay đổi. Output token được chuyển tiếp nguyên trạng.
Tôi cần GPU bao nhiêu để tự host model nén?
Bản build q4 có kích thước khoảng 2.5 GB, còn bản build bf16 khoảng 8 GB. Vì vậy model chạy thoải mái trên card 24 GB. Card nhỏ hơn vẫn dùng được và còn giúp bài toán hòa vốn có lợi hơn. Bộ lọc tool-schema không cần GPU: nó dùng BAAI/bge-small-en-v1.5, một embedding model 130 MB chạy trên CPU. Cài paritok[toolselect] trên một VPS thông thường là bạn có thể giảm tool-block với chi phí chỉ là thêm một ít RAM.
Nếu compressor xóa nội dung mà agent cần thì sao?
Không có nội dung nào bị xóa. Các đoạn đã nén mang tag [REF:id], và model khôi phục toàn bộ văn bản bằng read_original hoặc expand_context. Tool schema bị lọc được thay bằng stub thay vì xóa, và model khôi phục schema bằng gateway_search_tools. Rủi ro thực sự khó nhận biết hơn một file bị thiếu: model làm việc dựa trên bản tóm tắt mất mát thông tin và không nhận ra rằng nó cần yêu cầu bản gốc. Đó là điều mà con số giữ lại 86.5% chất lượng trên SWE-bench Lite đang đo lường.
Vì sao request đầu tiên mất 15 giây?
Embedding model phía sau tool filter được load ở request đầu tiên thay vì lúc startup. Project ghi nhận thời gian warm-up từ 10 đến 15 giây, sau đó mỗi lần gọi mất khoảng 15 ms. Sau khi khởi động proxy, hãy gửi một request bỏ đi bằng curl. Như vậy lượt agent thực tế đầu tiên sẽ không bị chậm.
Tôi có nên dùng GPU server được host thay vì tự host không?
Cách này loại bỏ chi phí thuê GPU và công việc bảo trì, với mức giá $0.30 cho mỗi triệu token được xử lý tính đến August 2026. Tuy nhiên, nó cũng gửi prompt và các file agent đọc đến một bên thứ ba trước khi chuyển chúng đến provider của model. Nếu bạn tự host để giữ code trên infrastructure do mình kiểm soát, tùy chọn này đi ngược lại lý do bạn bắt đầu. Tự host giữ cả context và API key của provider trên chính máy của bạn.