Paritok: чи справді токенів для coding agent на 74% менше?

Що Paritok робить із запитом

Paritok — це шлюз токенів: проксі, розташований між вашим coding agent і API моделі, який стискає кожен запит перед пересиланням. Ваш агент взаємодіє з http://127.0.0.1:8080, а не безпосередньо з провайдером. Проксі переписує схеми інструментів, читання файлів, вивід інструментів і попередні ходи діалогу, надсилає менший payload провайдеру та повертає відповідь без змін.

Провайдер виставляє рахунок за дані, які надходять до нього, тому менший payload означає менший рахунок. У цьому полягає вся ідея. Це інше твердження, ніж «ваш контекст працює довше», і саме тому цей інструмент цікавий, а не просто акуратний.

Проєкт ще молодий. Перші публічні теги датовані July 2026, а поточний тег — v1.3.0 від 5 August 2026. Ваги моделі та код шлюзу поширюються за ліцензією Apache 2.0. Модель стиснення — це адаптер LoRA (low-rank adaptation) для Qwen3-4B-Instruct-2507, навчений на 45,000 дистильованих учителем прикладах, отриманих із реальних траєкторій coding agent.

Чому це не є обрізанням контексту

Обрізання видаляє дані. Коли агент наближається до ліміту контексту й відкидає найстаріші ходи, файл, який він прочитав на ході 3, зникає. Якщо на ході 20 цей файл знову потрібен, агент читає його повторно, і ви вдруге сплачуєте за ці токени. Економія була лише позикою.

Paritok замінює сегмент коротшою формою з тегом [REF:id] і зберігає повний текст на проксі. Модель відновлює сегмент викликом read_original або expand_context. Це змінює сценарій збою. Обрізання призводить до того, що модель забуває дані, і ви ніколи про це не дізнаєтеся. Компресія передає моделі стислий текст із втратою даних, а модель може запросити оригінал, якщо стислого тексту недостатньо.

Фільтр інструментів працює так само. Відфільтровані схеми інструментів замінюються заглушками, а не видаляються. Модель відновлює схему викликом gateway_search_tools. Це важливо, оскільки фільтр, який назавжди приховує інструмент, змінює можливості агента, а ви дізнаєтеся про це лише через завдання, яке непомітно завершилося неправильно.

Три важелі та безкоштовний із них

Перший важіль — фільтр схем інструментів. Кожен запит містить увесь масив tools. Під час сеансу Claude Code із підключеними кількома MCP (model context protocol) серверами цей блок займає приблизно 29,000 токенів. Фільтр кодує запит користувача й опис кожного інструмента за допомогою BAAI/bge-small-en-v1.5 — embedding-моделі розміром 130 MB, — залишає відповідні інструменти, а для решти створює заглушки. Розмір блока зменшується приблизно до 8,000 токенів. Ця embedding-модель працює на CPU.

Другий важіль — стиснення вмісту. Саме для нього потрібна модель 4B на GPU. Вміст файлів, вивід інструментів та історія перезаписуються до 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%. У результаті ви платите за frontier-модель, щоб заощадити на frontier-моделі.

Інтерпретуйте стовпчик якості без прикрас. Якщо збережено 86.5% частки розв’язаних задач, це означає, що стиснені запуски не розв’язали задачі, які розв’язали нестиснені запуски, — майже одну задачу із семи. На бенчмарку це число в таблиці. У вашому репозиторії це задача, яку вам доведеться запускати двічі.

[
  {
    "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% за один хід, 39% до 5-го ходу та 63% до 20-го ходу. Також указано, де зростання припиняється: за бюджету 200,000 токенів абсолютна економія стабілізується на рівні близько 48,000 токенів за хід, приблизно між 8-м і 12-м ходами, оскільки після заповнення контексту історія перестає зростати. Часто цитоване значення «понад 85%» описує сесії з повністю заповненим контекстом. Це найкращий сценарій, тому не плануйте роботу, виходячи з нього.

Чи окупається 24GB GPU для Paritok?

Карта на 24 GB — типовий варіант оренди для моделі такого розміру. Станом на 7 August 2026 медіанна опублікована погодинна ставка on-demand для RTX 4090 з 24 GB становила $0.44, а найдешевші пропозиції — близько $0.20. Візьмімо $0.44. Якщо залишати GPU увімкненим увесь місяць, це 730 годин, тобто $321. Якщо запускати його лише в робочі години — 8 годин на день протягом 22 днів, — це 176 годин, тобто $77.

Тепер переведімо скорочення кількості токенів у скорочення витрат. Скорочення стосується вхідних токенів. Вихідні токени проходять через proxy без змін, тому їхня кількість не змінюється. Припустімо, що вхідні токени становлять 80% вашої суми в доларах. Для coding agent це типове співвідношення, але перевірте це припущення за власним рахунком. Отже, економія в доларах дорівнює скороченню кількості токенів, помноженому на 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% суми рахунку. Тому карта, залишена увімкненою, окупається, коли щомісячні витрати на agent перевищують приблизно $472, або приблизно $114, якщо зупиняти instance поза робочими годинами. За показника 63% для 20-го ходу ці значення становлять $637 і $154. За показника 39% для 5-го ходу, що відповідає типовому вигляду коротких сесій, потрібно витрачати приблизно $1,030 на місяць, перш ніж оренда карти взагалі стане виправданою.

Два чинники роблять результат кращим, ніж показано в таблиці. Моделі не потрібно 24 GB: збірка q4 займає приблизно 2.5 GB, а збірка bf16 — приблизно 8 GB. Тому менша карта або GPU box, який ви вже використовуєте для іншого завдання, зменшує всі значення в цій діаграмі. А зупинення instance, коли ніхто не пише код, є найефективнішим заходом, оскільки зменшує витрати на оренду приблизно на три чверті.

Один чинник робить результат гіршим. Compression pass потребує реальних обчислень. Кожен токен, який стискає модель 4B, вона спочатку зчитує, а потім записує. Це збільшує затримку кожного ходу agent. На карті, яку ви орендуєте погодинно, ці витрати проявляються як очікування, а не як окремий рядок у рахунку. Тому їх легко не помітити, доки ви не відчуєте затримку.

Якщо ви загалом порівнюєте орендовані години GPU з API-токенами, порівняння точки беззбитковості між GPU VPS і API-токенами виконує такий самий розрахунок для самого inference.

Запуск gateway Paritok на VPS

Потрібен Python 3.10 або новішої версії. Ubuntu 24.04 постачається з Python 3.12, тому для CPU-only частини достатньо стандартного образу 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"

Зафіксуйте версію. У репозиторії було позначено v1.2.8 29 July 2026 і v1.3.0 5 August 2026, а проєкт, що розвивається такими темпами, перейменовує ключі конфігурації між випусками. Простий pip install paritok або git clone для main наступного тижня надасть вам інший gateway, і не залишиться запису про те, який саме варіант створив виміряні показники.

Типовим бекендом є Ollama. Завантажте модель, а потім призначте їй коротке ім’я, яке очікує proxy.

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

Оскільки локальна модель створює rewrite для кожного сегмента, який стискає, надто довгий compression pass проявляється як завислий agent turn. Параметр num_predict в Ollama, що обмежує довжину вихідних даних визначає це обмеження.

Додайте поруч paritok.yaml. Саме use_gpu_server: false забезпечує виконання compression на вашому обладнанні.

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

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

paritok up — скорочена команда для всіх описаних дій: вона завантажує модель, якщо її ще немає, і запускає proxy на порту 8080. Перевірте proxy, перш ніж підключати до нього agent.

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

/health повертає невеликий об’єкт JSON, що містить "status":"ok" і рядок версії. /stats повертає загальні показники compression і власну оцінку proxy щодо обсягу зекономлених даних. Сприймайте цю оцінку як самоперевірку proxy і підтверджуйте її на сторінці використання вашого провайдера.

Для пропускної здатності, а не для зручності, 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 визначає вибір у цьому випадку.

Підключіть agent до proxy за допомогою змінних середовища базової URL-адреси.

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/config.toml, коли codex.enabled: true задано в paritok.yaml. Якщо експортувати змінну окремо, Codex продовжить звертатися безпосередньо до провайдера. Ознакою цього є лічильник /stats, який не змінюється під час роботи.

Залиште listener на 127.0.0.1, а не на 0.0.0.0. Proxy передає ваш API key провайдеру, тому доступний з інтернету proxy стає відкритим relay для цього key: той, хто знайде порт, зможе витрачати ваші кошти, навіть не отримавши сам key. Підключайтеся з laptop через 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. Якщо unit запускається і одразу завершує роботу, зазвичай це означає неправильний шлях до config file. journalctl -u paritok -n 50 виводить причину.

Варіант із розміщенням у хмарі та його вартість

Проєкт також надає компресію як сервіс. Задайте use_gpu_server: true за допомогою API key, і модель 4B запускатиметься на його обладнанні. Вартість становить $0.30 за мільйон оброблених токенів. Згідно з документацією проєкту, до кінця August 2026 послуга безкоштовна. Це усуває витрати на оренду GPU та всі операційні завдання, описані вище.

Водночас ваші промпти та файли, які читає агент, залишають вашу машину й потрапляють до третьої сторони, перш ніж їх отримає ваш постачальник моделі. Self-hosting потрібен саме для уникнення такого передавання. Перед установленням цього flag вирішіть, що для вас важливіше. Зміна flag займає один рядок, але її наслідки — ні.

Як виміряти власні результати до та після

Опубліковані показники належать проєкту. Їх отримано за допомогою harness проєкту на SWE-bench Lite. Ваш репозиторій — не SWE-bench Lite. Виконайте власні вимірювання.

• Протягом одного звичайного тижня працюйте без proxy у ланцюжку. Запишіть окремими рядками з розділу usage вашого провайдера кількість вхідних токенів, токенів, прочитаних із кешу, і вихідних токенів. Не записуйте лише загальну суму в доларах.
• Наступного тижня працюйте з proxy перед застосунком, виконуючи той самий тип роботи.
• Порівняйте рядки для вхідних токенів і токенів, прочитаних із кешу. Обсяг вихідних токенів має залишитися приблизно незмінним, оскільки його нічого не стискає. Якщо він суттєво змінився, змінилося щось інше, крім proxy.
• Порахуйте завдання, які довелося виконати повторно. Це складова якості в цій компромісній оцінці, і жодна dashboard не показує її.
• Додайте GPU hours другого тижня до витрат, перш ніж порівнювати підсумки.

Розділяти вхідні та вихідні токени важливо, оскільки їхня вартість суттєво відрізняється, а compressor впливає лише на один із цих показників. Станом на August 2026 Claude Sonnet 4.6 коштує $3 за мільйон вхідних токенів і $15 за мільйон вихідних токенів, а читання prompt cache коштує 10% від ставки для вхідних токенів — $0.30 за мільйон. Різниця у вартості вхідних і вихідних токенів визначає, чи дасть input-side compressor для вас будь-яку економію. Куди насправді спрямовуються токени Claude Code показує, яка частина контексту достатньо велика, щоб її варто було стискати.

Prompt caching особливо ускладнює розрахунок економії від фільтрації tool. Блок tool розташований на початку запиту, тому після першого ходу зазвичай потрапляє в кеш і оплачується за ставкою 10% від вартості вхідних токенів. Видалення 21,000 токенів із кешованого блоку заощаджує оплату 21,000 токенів за ставкою $0.30 за мільйон, тобто близько $0.006 за хід, а не $0.063, як можна було б припустити за ставкою без кешу. Проєкт залишає відфільтрований блок незмінним протягом сесії, щоб кешований префікс не змінювався. Фільтр, який повторно обирав би tools на кожному ході, інвалідовував би цей префікс і коштував би дорожче, ніж заощаджував.

Що досі не перевірено

Усі наведені вище показники продуктивності походять із самого проєкту. Незалежного відтворення результатів SWE-bench Lite немає, а через те, що перші теги датовано July 2026, код також має дуже коротку історію експлуатації. І коефіцієнт стиснення, і показник збереження якості вимірює сторона, зацікавлена в тому, щоб вони виглядали якомога краще. Це не означає, що вони неправильні. Це означає, що вони не підтверджені, тому їх слід сприймати інакше, ніж показник, який ви отримали самостійно.

Перед тим як звинувачувати свою конфігурацію, варто знати про одну задокументовану особливість. Модель embedding, яку використовує фільтр інструмента, завантажується під час першого запиту, а не під час запуску. Тому проєкт вказує час прогрівання 10–15 секунд, після чого один виклик займає приблизно 15 мс. Надішліть один тестовий запит після запуску проксі, і перший справжній цикл агента не виглядатиме як зависання.

За один день ви можете самостійно перевірити чотири речі: чи запускається проксі та продовжує працювати, чи змінюється /stats під час роботи, чи справді зменшується рядок input tokens у рахунку вашого провайдера і чи завершує агент роботу. Для вашої конфігурації саме це має значно більше значення, ніж будь-який опублікований benchmark.

Щодо взаємодії з іншими інструментами: self-hosted шлюз LiteLLM маршрутизує запити та веде їх облік, не змінюючи вміст. Тому ці рішення призначені для різних завдань і можуть використовуватися разом, причому Paritok розташовується найближче до агента. Якщо справжня мета — зменшити витрати, а не використати саме цей інструмент, ширший набір засобів контролю витрат для агента на VPS містить кілька змін, які спочатку можна спробувати безкоштовно.

FAQ

Чи зменшує Paritok мій рахунок за API, чи лише використання контексту?

Рахунок зменшується, оскільки проксі переписує запит до того, як він надходить до провайдера, а провайдер стягує плату за отримані дані. Розмір зменшення менший, ніж випливає із заявленого показника. Показник 74% — це рівень стиснення вмісту, який стискається. Для повного циклу проєкт повідомляє приблизно про 25% за один хід і 63% до 20-го ходу; змінюються лише вхідні токени. Вихідні токени передаються без змін.

Яка GPU потрібна для self-hosting моделі стиснення?

Збірка q4 займає приблизно 2.5 GB, а збірка bf16 — приблизно 8 GB, тому модель із великим запасом поміщається на карті обсягом 24 GB. Підійде й менша карта, що покращує розрахунок точки беззбитковості на вашу користь. Фільтру для схем інструментів GPU взагалі не потрібна: він використовує BAAI/bge-small-en-v1.5 — embedding-модель обсягом 130 MB, яка працює на CPU. Встановіть paritok[toolselect] на звичайному VPS і отримайте зменшення блоків інструментів за рахунок невеликого обсягу RAM.

Що станеться, якщо компресор вилучить дані, потрібні агенту?

Нічого не вилучається. Стиснуті сегменти містять тег [REF:id], а модель відновлює повний текст за допомогою read_original або expand_context. Відфільтровані схеми інструментів замінюються заглушками, а не видаляються; модель відновлює схему за допомогою gateway_search_tools. Справжній ризик непомітніший за відсутній файл: модель працює з неповним підсумком і не розуміє, що потрібно запросити оригінал. Саме це вимірює показник збереження якості 86.5% у SWE-bench Lite.

Чому мій перший запит виконується п’ятнадцять секунд?

Embedding-модель, яка використовується фільтром інструментів, завантажується під час першого запиту, а не під час запуску. У документації проєкту зазначено, що початкове прогрівання триває від 10 до 15 секунд, після чого один виклик займає приблизно 15 ms. Після запуску проксі надішліть один тестовий запит за допомогою curl, і перший реальний хід агента не затримуватиметься.

Чи варто використовувати hosted GPU server замість self-hosting?

Це усуває витрати на оренду GPU та обслуговування. Станом на August 2026 вартість становить $0.30 за мільйон оброблених токенів. Водночас ваші промпти та файли, які читає агент, передаються третій стороні до того, як вони надходять до вашого провайдера моделі. Якщо ви використовуєте self-hosting, щоб зберігати код на інфраструктурі під власним контролем, цей параметр нівелює причину такого вибору. Self-hosting зберігає і контекст, і API key провайдера на вашому власному сервері.