4 способи не спалювати токени в Claude Code
Автор XDA Developers ділиться прийомами економії ліміту Claude Code: обмежувати контекст конкретною частиною репозиторію замість пошуку по всьому проєкту; ставити effort на Medium для рутинних задач і підвищувати лише для складного дебагу; стабільні правила проєкту тримати в CLAUDE.md, а не повторювати в кожному промпті; великі PDF спершу стискати дешевшою моделлю до 20-30% обсягу, зберігаючи факти й цифри, і лише потім віддавати основній моделі.
Причина проста: більшість токенів іде не на саме рішення, а на дослідження коду й повторення тих самих інструкцій.
Де саме зникають токени
Автор XDA Developers звертає увагу: більшість витрат стається ще до того, як Claude Code щось виправить. Коли завдання сформульоване розпливчасто у великому проєкті, модель мусить сама шукати, де лежить потрібний код — переглядає функції, помилки, ключові слова, відкриває кілька файлів, щоб зрозуміти зв'язки між ними. Усі ці пошуки й прочитаний, але не потрібний код лишаються в контексті й з'їдають ліміт ще до першої правки.
Тому автор перестав дозволяти Claude «блукати» усім репозиторієм для кожного завдання. Якщо відомо, що зміна стосується конкретної частини проєкту, він одразу звужує область роботи до неї — прийом особливо помітний на великих кодових базах, де зайве дослідження швидко накопичується. Формулювання на кшталт Working only inside src/payments/, do not open other directories unless the fix requires it одразу відсікає зайвий пошук, а не просто просить «бути стислим».
Effort: Medium як стандарт, а не компроміс
Автор раніше тримав рівень effort високим за замовчуванням, вважаючи, що більше міркувань завжди дає кращий результат. На практиці для щоденних завдань це зайве. Medium добре справляється з дрібними багами, невеликими змінами, рефакторингом простого коду й додаванням базової функції — модель не витрачає токени на прораховування кожного можливого варіанту.
Medium — не постійна заміна вищих рівнів. Коли справа доходить до складного багу чи важкої сесії дебагу, яка справді потребує глибшого міркування, effort варто підняти назад. Правило автора просте: не змушувати Claude думати складніше, ніж вимагає завдання, і піднімати рівень лише тоді, коли рутинний підхід дав збій.
Що виносити в CLAUDE.md, а що лишати в промпті
Ще одне джерело витрат — повторення тих самих правил проєкту в кожному запиті: який стек використовувати, якої структури компонентів дотримуватись, не додавати нові залежності, запускати тести після змін, не чіпати API. Усе це автор переніс у CLAUDE.md, щоб Claude звертався до файлу сам, а не отримував ті самі інструкції щоразу заново.
Разові вимоги в CLAUDE.md не потрапляють. Якщо щось стосується лише поточного завдання — наприклад, don't modify this component або use this approach for this particular fix — це лишається в самому промпті. Перетворювати одноразову вимогу на постійне правило проєкту немає сенсу: це лише подовжує контекст, який Claude мусить читати щоразу.
PDF спершу через дешевшу модель
Насичені зображеннями чи скановані PDF заповнюють контекстне вікно швидше, ніж здається, — через картинки, форматування, повторювані заголовки та інший непотрібний вміст. Замість того щоб одразу віддавати такий документ основній моделі, автор спершу проганяє його через дешевшу, легшу модель із запитом зробити стислу текстову версію.
При цьому модель отримує чітку інструкцію: зберегти фактичні твердження, цифри, дати, імена, інструкції та рекомендації, а також структуру документа, і прибрати наповнювач, повтори, маркетингову мову й артефакти форматування. Орієнтир за обсягом — приблизно 20–30% від початкової довжини. Уже цю стиснуту версію автор передає сильнішій моделі для глибшого аналізу: витрачається менше вхідних токенів, і сама модель отримує менше шуму для обробки.