Економія токенів як транспортна задача

Враховувати треба всю траєкторію агента

Я б рахував не токени одного запиту, а очікувану вартість усієї траєкторії агента. В початковому обговоренні користувач 1497575255 порівняв мінімізацію токенів із транспортною задачею: результат має потрапити з точки А до точки Б з мінімальними витратами ресурсу. Це точніше за звичне «зробімо промпт коротшим».

Для кожного кроку відома або оцінюється вартість входу й виходу. Вхід охоплює інструкцію, історію, схеми інструментів і знайдені документи. Вихід залежить від типу задачі, обраної моделі, бюджету генерації та потреби повторити виклик.

На рівні пайплайна змінних стає більше:

• яку модель призначити планувальнику, виконавцю та перевіряльнику;
• які фрагменти контексту зберегти або стиснути;
• скільки ітерацій і повторів дозволити;
• коли викликати інструмент, а коли завершувати гілку.

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

Є й окрема підзадача вибору контексту. Кожен фрагмент має розмір і очікувану корисність, а загальне вікно обмежене бюджетом. За структурою це нагадує задачу про рюкзак, поєднану з маршрутизацією моделей у спільній схемі оптимізації.

Точну довжину входу зазвичай можна отримати до надсилання запиту. З виходом складніше: потрібен прогноз за класом задачі й моделлю, а для агента треба враховувати імовірність додаткових кроків. Станом на 6 листопада 2026 року це не новина про конкретний реліз, а корисна інженерна постановка проблеми.

Економія не починається з дешевої моделі

Найбільший виграш дає керування рішеннями агента, а не механічна заміна сильної моделі слабшою. Дорогий виклик може бути вигіднішим, якщо усуває кілька повторів, зайвий пошук або довгу гілку міркувань.

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

Слабке місце очевидне: помилка прогнозу якості коштує дорожче за зекономлені токени. Тому я б передусім стежив за повторними викликами, розростанням історії та передаванням повних результатів інструментів. Саме там агентні пайплайни часто непомітно спалюють бюджет.

У такій системі токени стають не лічильником після виконання, а ресурсом планування. Залишається одне питання: наскільки добре маршрутизатор здатен передбачити ціну помилки до того, як дешевий шлях стане дорогим обхідним маршрутом?

Раніше ми розбирали, як конфігурації Claude Opus 4.6, розширене міркування та довжина контексту впливають на вартість запитів. Це доповнює погляд на токен-оптимізацію як на розподіл обмеженого бюджету між частинами контексту.