Як контролювати витрати AI-агента на VPS

Як не дозволити постійно запущеному AI-агенту перевищити бюджет

Контроль витрат AI-агента на VPS (virtual private server) ґрунтується на обмеженнях, які ви встановлюєте до запуску агента, оскільки під час його роботи ніхто не стежить за лічильником. Обмежуйте кожну відповідь за допомогою max_tokens, обмежуйте кількість ітерацій циклу у власному коді, кешуйте незмінну частину промпту та записуйте в журнал показники використання для кожної відповіді, щоб визначити, яке завдання витрачає кошти. Оренда сервера має фіксовану місячну ціну. API моделі тарифікується за кількістю токенів, а цикл без нагляду легко витрачає токени непомітно.

Тут мається на увазі агент, який уже існує та викликає Messages API із сервера, яким ви керуєте. У матеріалі Як створити AI-агента з Claude на VPS описано саму інфраструктуру.

Чому unattended agent має іншу структуру витрат

В інтерактивній сесії бере участь людина. Якщо модель рухається неправильним шляхом або читає журнал на 40,000 рядків, користувач зупиняє її. У unattended agent такого обмеження немає: він працює, доки цикл не завершиться, а потім таймер запускає його знову.

Частота — це множник, який часто не враховують. Завдання за розкладом кожні п’ять хвилин запускається 288 разів на день і приблизно 8,640 разів на місяць. Незалежно від вартості одного запуску, саме на цю кількість її потрібно помножити. Багатьом "always-on" агентам не потрібно працювати постійно. Їм потрібно відповідати протягом певної кількості хвилин. Це означає, що достатньо розкладу.

Agent також оплачує те, за що вікно чату не стягує плату.

• Визначення інструментів передаються з кожним запитом. System prompt для використання інструментів коштує 290 токенів у Claude Opus 4.8 з tool_choice із auto або none, і 410 — із any або tool. Інструмент bash додає ще 325 токенів. Кожен MCP server, який ви підключаєте, додає до цього обсягу власні схеми; MCP — це протокол контексту моделі.
• Результати роботи інструментів є вхідними токенами. Команда, яка виводить 8,000 рядків, додає 8,000 рядків до наступного запиту та до кожного наступного запиту в межах цього ходу.
• Отримані сторінки є вхідними токенами. Середня вебсторінка розміром 10 kB — це приблизно 2,500 токенів, а дослідницький PDF розміром 500 kB — приблизно 125,000 токенів. max_content_tokens обрізає лише текстові дані, оскільки цей параметр "застосовується до текстового вмісту, а не до двійкового вмісту, такого як PDF". Для PDF натомість використовуйте max_uses і allowed_domains, щоб обмежити його обсяг.
• Пошук у вебі оплачується за кожен пошуковий запит — $10 за 1,000 пошукових запитів, незалежно від кількості отриманих результатів. Пошуковий запит із помилкою не тарифікується.

Жодна з цих статей витрат не є значною для одного запуску. Але всі вони стають значними 8,640 разів.

Жорсткі та м’які обмеження вирішують різні проблеми

max_tokens застосовується примусово. Це жорстке обмеження загального обсягу одного запиту, яке охоплює і міркування, і текст відповіді. Claude ніколи не перевищує його, а модель не бачить цього числа. Досягнення ліміту повертає stop_reason: "max_tokens" і обрізану відповідь. Для агентів важливо, що кожен запит у циклі використання інструментів має власний max_tokens. Тому він обмежує одну відповідь, а не все завдання. Десять викликів інструментів по 4,000 токенів дають обмеження 40,000 токенів для одного ходу.

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

resp = client.beta.messages.create(
    model="claude-opus-4-8",
    max_tokens=4096,
    betas=["task-budgets-2026-03-13"],
    output_config={"task_budget": {"type": "tokens", "total": 64000}},
    messages=messages,
)

"Бюджети завдань — це м’яка рекомендація, а не жорстке обмеження." Claude може перевищити його під час однієї дії, а примусове обмеження вихідних даних усе одно визначає max_tokens. "Зворотний відлік бачить лише модель", а відповіді не містять поля із залишком бюджету. Мінімальне прийнятне значення task_budget.total — 20,000 токенів; менше значення повертає помилку 400. Якщо бюджету недостатньо для роботи, модель може поводитися як під час відмови: звузити завдання або завершити його раніше.

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

Бюджети завдань доступні в beta для Claude Fable 5.1, Claude Fable 5, Claude Opus 5.5, Claude Opus 5, Claude Opus 4.8, Claude Opus 4.7, Claude Sonnet 5.5 і Claude Haiku 5.5. Claude Sonnet 5 і Claude Haiku 4.5 позначені як Not supported, а бюджети завдань не застосовуються до Claude Code. Тому сесія Claude Code, від’єднана в tmux залежить від правильного керування сесією.

Третє обмеження налаштовується в Claude Console: створіть для агента окремий workspace, а потім установіть для нього місячний ліміт витрат і обмеження кількості запитів за хвилину. "Для Default Workspace не можна встановити обмеження", а "загальноорганізаційні обмеження діють завжди, навіть якщо сума обмежень workspace перевищує їх". Додайте сповіщення про витрати, щоб отримати повідомлення після досягнення порога, але до вичерпання ліміту.

Вибір моделі для кожного завдання та фактичний вплив effort

Вибір моделі залежить від конкретного завдання. Станом на жовтень 2026 року ціна за мільйон токенів — спочатку вхідні, потім вихідні: Claude Fable 5.1 і Fable 5 — $10 і $50, Claude Opus 5.5 — $4 і $20, Claude Opus 5, Opus 4.8 та Opus 4.7 — $5 і $25, Claude Sonnet 5.5 і Sonnet 5 — $2 і $10, Claude Haiku 5.5 — $0.10 і $0.50 для запитів обсягом до 100,000 токенів ($0.50 і $2.50 для більшого обсягу; кешовані токени також враховуються), а Claude Haiku 4.5 — $1 і $5. Спочатку Anthropic продавала Sonnet 5 за цією ціною як тариф для запуску, потім зробила її стандартною та скасувала заплановане підвищення до $3 і $15. Крок, який лише класифікує рядки журналу, не потребує Opus.

Не покладайтеся також на безкоштовний доступ для покриття великого навантаження. Окрім невеликого кредиту, який Claude API надає під час реєстрації, єдина регулярна квота — щомісячний кредит API, включений до планів Claude Max і Team: $100 для Max 5x, $200 для Max 20x і до $500 спільного кредиту для Team. Кредит поновлюється в кожному платіжному циклі. Отримати його можна через 7 днів після підключення відповідного плану; спосіб оплати не потрібен. Він покриває Claude API, Managed Agents, Agent SDK і playground, але не Claude Code. Наприкінці кожного циклу кредит анулюється без перенесення залишку. Використання кредиту враховується в ліміті витрат. Коли кредит закінчиться, запити припиняться, якщо організація додатково не має придбаних кредитів.

Effort — це другий важіль керування витратами. output_config.effort приймає low, medium, high, xhigh і max, хоча не кожна модель підтримує всі рівні. Для більшості моделей значенням за замовчуванням є high, а для Claude Opus 5.5 і Claude Haiku 5.5 — medium. Явне встановлення стандартного значення для моделі має той самий результат, що й пропуск цього параметра. Нижчий effort скорочує не лише тривалість міркування. У документації зазначено, що Claude робить менше викликів інструментів і об’єднує кілька операцій у меншу кількість викликів. Для агента це дає більшу економію, оскільки пропущений виклик інструмента означає, що цілий запит не виконується.

Проблема в тому, що effort впливає на кеш. Зміна значення верхнього рівня між запитами інвалідовує кешування prompt. У задокументованому прикладі для Claude Opus 5.5 запит 2 повернув cache_read_input_tokens: 3546. У запиті 3 effort змінили з medium, стандартного значення цієї моделі, на low, і запит повернув cache_creation_input_tokens з 3546 та cache_read_input_tokens з 0. Тому змінюйте effort верхнього рівня між різними типами навантаження, але не в межах одного кешованого діалогу. Є два способи змінити глибину без порушення кешу. У Claude Fable 5.1, Opus 5.5, Opus 5, Sonnet 5.5 і Haiku 5.5 зміна effort для окремого повідомлення (beta, заголовок mid-conversation-output-config-2026-07-01) встановлює новий рівень і залишає кешований префікс без змін. У будь-якій моделі можна натомість керувати цим через prompt: рядок на кшталт "Answer directly without deliberating." у найновішому повідомленні користувача не змінює попередні точки розриву. Однак у Claude Haiku 5.5 ця фраза не гарантує зменшення обсягу міркування.

Токени міркування оплачуються за тарифами для вихідних токенів і враховуються в max_tokens. Тому обірвана відповідь часто означає, що бюджет витрачено на міркування. Перегляньте usage.output_tokens_details.thinking_tokens, щоб дізнатися кількість токенів. У статті Що насправді формує рахунок Claude за токени описано склад цього показника.

Кешуйте стабільний префікс і не ламайте його випадково

Запис у кеш коштує 1.25 базової ціни вхідних даних для кешу на п’ять хвилин і 2 рази базової ціни для кешу на одну годину. У більшості моделей читання з кешу коштує 0.1 базової ціни, тому «кешування стає вигідним після одного читання з кешу для тривалості 5 хвилин (запис коштує 1.25x) або після двох читань з кешу для тривалості 1 година (запис коштує 2x)». У новіших моделях читання коштує ще менше: 0.05 базової ціни для Claude Opus 5.5 і Claude Sonnet 5.5 та 0.025 для Claude Fable 5.1.

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

Є три способи непомітно втратити кеш.

Префікс змінюється. «Префікси кешу створюються в такому порядку: tools, system, потім messages». Будь-яка зміна байта на початку цього порядку робить недійсним увесь вміст після нього, а редагування визначень інструментів робить недійсним увесь кеш. Класична помилка — додати timestamp або run id у system prompt. Тоді кожен запит містить інший префікс, записує новий запис із вартістю 1.25x і нічого не читає з кешу. Ознакою є значення usage.cache_read_input_tokens, що дорівнює 0 для зовні однакових викликів. Перемістіть текст, який часто змінюється, у найновіше user message.

Префікс надто короткий. Для кожної моделі встановлено мінімальну довжину вмісту, який можна кешувати. Якщо запит коротший, його обробляють без кешування, і «жодної помилки не повертають». Зокрема, це 512 токенів для Claude Fable 5.1, Fable 5, Opus 5.5, Opus 5, Sonnet 5.5 і Haiku 5.5, 1,024 — для Claude Opus 4.8 і Claude Sonnet 5 та 4,096 — для Claude Haiku 4.5. Тому перенесення завдання із Sonnet 5 на Haiku 4.5 може непомітно вимкнути кешування.

Розмова виходить за межі lookback. «Розмір вікна lookback становить 20 блоків». Для кожної точки переривання система перевіряє не більше 20 позицій, а потім зупиняється. У задокументованому прикладі turn містить 35 блоків, а точка переривання розташована на блоці 35. Система перевіряє блоки від 35 до 16, але запис попереднього turn на блоці 15 уже не входить у це вікно, тому збігу немає. Агент, який додає кілька блоків tool-use і tool-result у кожному turn, перевищує 20 блоків за два або три turn. На кожен запит доступні чотири точки переривання, тому одну з них варто використати для найновіших повідомлень.

Передавайте все, що може зачекати, до Batches API

«Усі запити оплачуються за 50% стандартних цін API» — і для вхідних, і для вихідних даних. Обробка batch-запитів асинхронна: «більшість batch-запитів завершується менш ніж за 1 годину». Результати доступні після завершення всіх запитів або через 24 години — залежно від того, що настане раніше. Це типовий показник, а не гарантія.

Опитуйте processing_status, доки його значення не стане ended. Запити зі статусом errored, canceled або expired не оплачуються. Якщо ви використовуєте ліміт витрат, врахуйте один нюанс: «batch-запити можуть незначно перевищити налаштований ліміт витрат вашого Workspace».

Знижки сумуються. Оскільки виконання batch-запиту може тривати понад 5 хвилин, документація рекомендує одногодинне кешування для batch-запитів зі спільним контекстом. Розділіть обробку: усе, чого очікує користувач або webhook, залишайте в оперативному контурі, а нічний дайджест чи класифікацію журналів за вчора передавайте до batch за половину ціни.

Записуйте всі поля використання кожної відповіді у власне сховище

Неможливо віднести до витрат те, що ви не записали. Кожна відповідь містить дані про свою вартість.

u = resp.usage
row = {
    "job": job_name,
    "model": resp.model,
    "uncached_input": u.input_tokens,
    "cache_write": u.cache_creation_input_tokens,
    "cache_read": u.cache_read_input_tokens,
    "output": u.output_tokens,
    "stop_reason": resp.stop_reason,
}

Додавайте один рядок для кожного API-виклику до файлу у форматі JSON Lines і позначайте його назвою завдання. Через тиждень ви зможете визначити, яке завдання витрачає кошти, а яке лише створює видимість активності. Стежте за cache_read: стовпець із нульовими значеннями — найпоширеніша помилка обліку витрат у self-hosted агенті.

Одне поле легко неправильно інтерпретувати. input_tokens враховує лише токени після останньої точки кешування, тому фактичний розмір промпту дорівнює total_input_tokens = cache_read_input_tokens + cache_creation_input_tokens + input_tokens. Агент, який звітує про input_tokens: 400 для великого промпту, не є дешевим: решта токенів надійшла з кешу.

Підраховуйте токени до надсилання запиту. Підрахунок токенів безкоштовний, а його ліміти окремі від лімітів створення повідомлень, тому використовуйте count_tokens, щоб відхилити надмірно великий вкладений файл, а не платити за виявлення проблеми. Результат є оцінкою, тому повторно вимірюйте його для кожної моделі й ніколи не використовуйте підрахунок токенів з tokenizer іншого постачальника. Моделі Claude 4.7 і новіші, зокрема Claude Fable 5 і Claude Sonnet 5, використовують новий tokenizer, який «генерує приблизно на 30% більше токенів для того самого тексту». Claude Sonnet 4.6 і старіші моделі, зокрема Claude Haiku 4.5, використовують попередній tokenizer.

Для отримання офіційних даних Admin API повертає статистику використання через https://api.anthropic.com/v1/organizations/usage_report/messages, а дані про витрати — через https://api.anthropic.com/v1/organizations/cost_report. Для обох запитів потрібен admin key (sk-ant-admin01-...), переданий як x-api-key: $ANTHROPIC_ADMIN_KEY разом із anthropic-version: 2023-06-01. Звіт про використання приймає bucket_width=1d, group_by[]=model і api_key_ids[]=. Звіт про витрати доступний лише в розрізі днів і групує дані за workspace_id або description. Є одне обмеження: «Admin API недоступний для індивідуальних облікових записів».

Параметр api_key_ids[] — простий спосіб розподіляти витрати: створіть окремий API key для кожного завдання, відфільтруйте звіт про використання за допомогою api_key_ids[] і розділіть дані за ключами через group_by[]=api_key_id. Фільтр використовує множину, а вимір групування — однину. Зберігайте ключі в environment, а не в коді, як це робить перший застосунок Claude API на VPS.

Обмежте цикл, бо інакше цього ніхто не зробить

Обмежена кількість ітерацій тут обов’язкова. Це ваш цикл, отже лічильник також має бути вашим:

for step in range(MAX_STEPS):          # MAX_STEPS = 12, never "while True"
    resp = client.messages.create(...)
    if resp.stop_reason != "tool_use":
        break
else:
    log.warning("job %s hit MAX_STEPS=%d, giving up", job_name, MAX_STEPS)

Жоден із наведених вище обмежувачів не вирішує це завдання: max_tokens обмежує одну відповідь, а модель лише отримує інформацію про бюджет завдання. Hosted product зупинив би процес на цьому етапі, як обмеження Claude на виклики інструментів у межах одного ходу завершує сеанс після надмірної кількості таких викликів. Але цикл, який ви написали самі, не має такого запобіжника, доки ви його не додасте.

Додайте другий запобіжник за межами процесу. Запускайте завдання через systemd timer, а не як постійний процес, і задайте для його service unit обмеження реального часу виконання. Завдання timer зазвичай Type=oneshot, а RuntimeMaxSec= «не має жодного ефекту для сервісів Type=oneshot», тому задайте TimeoutStartSec=600 саме там. Використовуйте RuntimeMaxSec=600 лише для unit типу Type=simple. У будь-якому разі завислий запуск буде завершено через десять хвилин, а не продовжуватиметься, доки ви його не помітите. У матеріалі Запуск програми як systemd service і timer описано самі unit-файли. Перегляньте результат запуску за допомогою journalctl -u triage-agent.service --since "1 hour ago".

Також обмежте кількість повторних спроб, оскільки handler, який повторює спроби без кінця, оплачує кожну з них. Для помилки 429 або 500 доречно виконати кілька спроб із backoff. Для помилки 400 повторні спроби не потрібні, оскільки той самий запит завершиться так само.

Контроль витрат AI-агента починається з аналізу власних показників

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

Це передбачає використання API key, оскільки агент є вашою власною програмою, яка викликає Messages API. Для власної інтерактивної роботи в матеріалі який план Claude відповідає вашому способу роботи описано варіанти підписки. Усі ціни та ліміти тут перевірено за документацією Anthropic у жовтні 2026 року, тому перед складанням бюджету ще раз перегляньте сторінку з цінами.

FAQ

Скільки коштує запуск постійно активного AI-агента на VPS?

Є два типи витрат, і лише один із них можна передбачити. Сервер має фіксовану щомісячну ціну. Вартість Model API розраховується за кількістю токенів, тому загальна сума залежить від кількості токенів за один запуск і частоти запусків. Anthropic не публікує даних про вартість self-hosted постійно активного агента, тому будь-яку названу суму слід вважати приблизною. Запишіть usage під час одного реального запуску та помножте це значення на кількість запусків за вашим розкладом.

У чому різниця між max_tokens і бюджетом завдання?

max_tokens застосовується примусово й не відображається для моделі. Він обмежує вихідні дані одного запиту, зокрема міркування, а досягнення цього ліміту повертає stop_reason: "max_tokens". Бюджет завдання працює навпаки: модель отримує це число й відповідно регулює цикл роботи агента, але "Task budgets are a soft hint, not a hard cap", а фактичним обмеженням залишається max_tokens.

Чому cache_read_input_tokens завжди дорівнює нулю для мого агента?

Тому що префікс змінюється між викликами або він надто короткий для кешування. Найчастіша причина — timestamp або run id, вставлений у system prompt: кеш використовує префікс як ключ, тому будь-яка зміна байта робить усе наступне недійсним для кешу. Зміна визначень інструментів або значення effort верхнього рівня має такий самий ефект. В іншому разі причина полягає в розмірі: коротші промпти не кешуються, і помилка при цьому не повертається.

Як зупинити AI-агента, якщо він працює в нескінченному циклі?

Підраховуйте кількість ітерацій у коді циклу та зупиняйте його після досягнення фіксованого максимуму, оскільки max_tokens обмежує одну відповідь, а агент виконує багато таких відповідей. Додайте обмеження за часом роботи за межами процесу: запускайте завдання через systemd timer і встановіть TimeoutStartSec= для oneshot unit або RuntimeMaxSec= для simple unit, щоб завислий запуск було примусово завершено за розкладом. Також обмежте кількість повторних спроб, оскільки кожна спроба в циклі повторного виконання збільшує витрати.

Чи можна встановити ліміт витрат для одного ключа Claude API?

Задокументований ліміт витрат застосовується до workspace, а не до окремого ключа, тому створіть для агента окремий workspace і встановіть у ньому місячний ліміт витрат. "You cannot set limits on the Default Workspace". Додайте сповіщення про витрати, щоб спочатку отримати повідомлення про досягнення порогу. Для атрибуції видайте кожному завданню окремий ключ, а потім згрупуйте звіт про використання за допомогою group_by[]=api_key_id.