Як 12 воркерів з'їли 5-годинне вікно Opus за 25 хвилин

Увечері я запустив дванадцять паралельних воркерів claude -p --model opus на диску D:, кожен у власному git worktree. Вони мали обробити беклог з 802 відкритих пунктів за допомогою конвеєра: тріаж → кодер → критик → фіксер → автомердж. Мета була використати близько 50% тижневої квоти Opus на двох підписках Max ($200) до ресету о 05:20, щоб закрити якнайбільше задач з реальною цінністю. За 25 хвилин дванадцять воркерів вичерпали 5-годинне вікно акаунта 2 — це виміряно, а не оцінено. Акаунт 1 не дійшов до ліміту, але застряг через протухлу OAuth-сесію headless-комірки, яку лікує лише ручний логін.

Що хотіли

Ми хотіли максимізувати корисну роботу за межами тижневої квоти Opus, не виходячи за межі двох підписок Max. Конкретно — використати близько 50% тижневої квоти на обробку беклогу з 802 пунктів, щоб закрити якнайбільше задач з оцінкою цінності 1–5 і розміром, перетворюючи їх у автономні ТЗ. План полягав у використанні флоту headless-воркерів claude -p --model opus у власних git worktrees, з оркестрацією через окрему модель Fable 5.1 у десктопі. Конвеєр мав йти від тріажу (8 воркерів, що перетворюють 802 пунктів у ~200 автономних ТЗ) до кодера (бандли 2–4 пунктів одного файлового кластера), потім до адверсарного критика (мандат «спростуй PR», читає файл цілком), потім до фіксера (закриває знахідки або відхиляє з доказом файл:рядок), і на завершення — автомердж після зеленого CI або ребейзер при конфлікті. Ціль полягала в отриманні якнайбільшої кількості PR у main до ранку, з фокусом на цінність, а не на кількість. Ми розраховували, що паралелізм прискорить доставку, не зважаючи на те, що квота є спільним ресурсом.

Що виявилось про ліміти

Виміряно: 12 паралельних Opus-воркерів з'їдають 5-годинне вікно акаунта за ~25 хвилин. Це означає, що вікно становить приблизно 5–6 воркеро-годин, а не 12. Отже, корисно тримати 3–4 воркери безперервно, а не 12, щоб не вичерпати ліміт за короткий час. Акаунт 2 вперся у session-limit о 00:30 (ресет 05:20), а акаунт 1 не дійшов до ліміту, але застряг через протухлу OAuth-сесію headless-комірки, яку лікує лише ручний логін. Це показує, що лімітів два: є 5-годинне вікно (швидке вичерпання при паралелізмі) і тижневе (загальне обмеження на використання). Паралелізм не додає квоти — він лише швидше з'їдає спільний пул. Тому ефективність слід міряти не як «кількість воркерів», а як «змерджені PR / витрачена квота» і «частка переробок». Якщо витрачати квоту на конфлікти та повторну роботу, то навіть якщо ви зробите багато PR, корисна вихідна одиниця буде низькою.

Конвеєр кодер→критик→фіксер і чому критик окупається

Конвеєр працював так: тріаж беклогу (8 воркерів) створював автономні ТЗ з оцінкою цінності 1–5 і розміром; кодер брав бандли 2–4 пунктів одного файлового кластера; потім приходив адверсарний критик з мандатом «спростуй PR» — він читав кожен файл цілком, шукаючи проблеми; фіксер закривав знахідки або відхиляв їх з доказом файл:рядок; на завершення — автомердж після зеленого CI або ребейзер при конфлікті. Критик дав вердикт «спершу виправ» у ~95% PR. Це виглядало як надмірна робота, але воно окупилося: знайдено були критичні вади, такі як перевипуск інвайту, що обходив перевірку ролі (куратор міг підняти себе до HR), безстелевий запис лідів у CRM, замок кронів, що крав власність, CSV-ін'єкція у 4 експортах, і десятки «близнюків» (той самий дефект у другому місці). Без критика ці проблеми потрапили б у main, створюючи технічний борг або ризики безпеки. Його витрати — частина оркестратора — виявились виправдані, бо запобігли дорогому виправленню пізніше.

Помилки ночі

Помилки ночі: воркери правили спільний файл BACKLOG.md → після кожного мерджу решта PR ставали конфліктними (12 ребейзерів); TaskStop зупиняв лише обгортку, а процес claude.exe жив орфаном і палив квоту (лікування — вбивати процес за змінною середовища); читання у headless-режимі обмежене робочою текою (--add-dir); перший запуск за «гарячим контекстом», а не за цінністю; звіт «коду не міняли» про PR на 11 файлів — втрата довіри координатора. Це означало, що кожен новий PR вимагав ручного розв'язання конфліктів,оркестратор витрачав токени на сповіщення, а орфанські процеси продовжували споживати квоту без користі. Читання у headless-режимі обмежувало доступ до файлів поза --add-dir, що призвело до неповного аналізу. Запуск за «гарячим контекстом» означав, що воркери починали з попереднього стану, а не з чистої оцінки цінності, що призвело до неправильного пріоритизування. Звіт «коду не міняли» підірвав довіру, бо координатор не міг переконатися, чи фіксер дійсно виправив проблему.

Що кажуть інші

Офіційна документація Claude Code (docs.anthropic.com, «Manage costs effectively», «CLI reference»): кеш промпту для підписки живе 1 годину; ліміти — 5-годинне вікно + тижневе, спільні для всіх моделей; окремі ліміти по сімействах моделей; агентні команди споживають ~7× токенів; головні причини несподіваних витрат — довгий контекст і промахи кешу; є нативні claude agents --json, claude attach/logs/stop/respawn, claude daemon для фонових сесій. Патерн Ralph loop (github.com/snarktank/ralph): кожна ітерація зі свіжим контекстом, стан живе у файлах (prd.json, git, журнал прогресу); варіант із PR — github.com/AnandChowdhary/continuous-claude. Claude Squad (github.com/smtg-ai/claude-squad): TUI-менеджер сесій на tmux + git worktrees, ~8,4k зірок; CC-Manager (github.com/agent-next/cc-manager): REST-черга задач, worktree, бюджети, автомердж — але розрахований на API-ключ, а не на підписку. Політика продовження сесій (--resume): та сама задача + короткий проміжок → продовжити; довгий проміжок або холодний кеш → новий воркер + короткий HANDOFF.md + diff; інша задача → завжди свіжий. Не будити велику сесію заради «як справи» — одне речення тягне всю історію. Паралелізм не додає квоти — лише швидше з'їдає спільний пул; 2–3 ізольовані воркери часто найкращі за часом доставки; ефективність міряти як «змерджені PR / витрачена квота» і «частка переробок».

Чого це коштує оркестратору

Чат-оркестратор на Fable: контекст 680 тисяч токенів × ~150 прокидань за ніч (кожне сповіщення про фініш воркера будить чат) = ~27% тижневого ліміту Fable — найдорожчий елемент системи, хоча ~90% його дій були детермінованими («вердикт FIX-FIRST → поставити фіксера»). Це означало, що більше чверти тижневого ліміту оркестратора витрачалося не на прийняття рішень, а на обробку сповіщень, які могли б бути оброблені детермінованим логікою. Якщо б оркестратор був реалізований як демон з чергою та слотами, він би лишив LLM лише для трьох ключових точок: тріаж беклогу, вибір бандлів, ранковий звіт координатору.

Що я зміню наступного разу

Наступного разу я зменшу кількість паралельних воркерів до 3–4 на акаунт, щоб уникнути швидкого вичерпання 5-годинного вікна. Введу детермінований оркестратор-демона з чергою задач, слотами на лімітах, автоматичними паузами при наближенні до ліміту та файлом STATUS.md для стану. Зберігатиму LLM лише в тріажі, виборі бандлів та ранковому звіті, перенісши всі інші функції (сповіщення, маршрутизація, обробка конфліктів) на правила. Використаю --add-dir явно для кожного worktree, щоб уникнути обмежень читання. Заблокую запуск за «гарячим контекстом» — кожен воркер починатиме зі свіжого контексту та оцінки цінності. Введу автоматичну перевірку, що фіксер дійсно змінив код (за діфом PR, а не за словами звіту), щоб уникнути звітів «коду не міняли». Зменшу сповіщення оркестратора, використовуючи вебхуки або файлові події замість постійного чату.

Кому це не потрібно

Цей підхід не потрібен, якщо у вас менше 50 відкритих задач у беклогу — простіше обробити їх вручну або з одним AI-агентом за день. Він також не підходить для команд, які не мають доступу до двох платних підписок Claude Max, оскільки ефективність залежить від розподілу навантаження між акаунтами для уникнення session-limit. Нарешті, якщо ваш беклог містить переважно документи або конфігураційні файли без коду (наприклад, маркетинговий текст або політики), тоді конвеєр кодер→критик→фіксер не дасть значної користі, бо критик і фіксер орієнтовані на виявлення та виправлення помилок у коді.