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

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

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

Цей матеріал розрахований на вже готового агента, який викликає Messages API з вашого сервера. Building an AI agent with Claude on a VPS описує архітектуру системи.

Чому витрати на автономного агента мають іншу структуру

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

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

Агент також створює витрати на речі, які не характерні для вікна чату.

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

Кожна окрема операція не є дорогою. Дорогою є сумарна вартість 8,640 повторень.

Hard ceilings and soft ceilings вирішують різні завдання

Застосовується max_tokens. Це жорстке обмеження на загальний обсяг одного запиту, що включає текст роздумів та відповідь. Claude ніколи не генерує текст більше цього ліміту, при цьому модель не бачить цього числа. Досягнення ліміту призводить до stop_reason: "max_tokens" та обрізаної відповіді. Проблема для агентів: кожен запит у циклі використання інструментів (tool-use loop) має власний 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,
)

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

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

Task budgets знаходяться в стадії beta у Claude Fable 5, Claude Opus 4.8 та Claude Opus 4.7. Claude Sonnet 5 та Claude Haiku 4.5 позначені як Not supported, а task budgets не застосовуються до Claude Code, тому Claude Code session detached in tmux залежить від коректності роботи сесії.

Третій рівень обмежень знаходиться в Claude Console: виділіть агенту окремий workspace, потім встановіть для нього місячний ліміт витрат та ліміти запитів на хвилину. "Ви не можете встановити ліміти для Default Workspace", а "Загальнокорпоративні ліміти (Organization-wide limits) завжди діють, навіть якщо сума лімітів workspace більша". Додайте сповіщення про витрати, щоб отримати попередження до того, як буде досягнуто ліміту.

Вибір моделі для кожного завдання та реальний вплив рівня зусиль

Вибір моделі приймається для кожного окремого завдання. Станом на липень 2026 року, ціна за мільйон токенів (вхідні, потім вихідні): Claude Fable 5 — $10 та $50, Claude Opus 4.8 та Opus 4.7 — $5 та $25, Claude Sonnet 5 — $3 та $15, Claude Haiku 4.5 — $1 та $5. Наразі ціна Sonnet 5 нижча за заявлену, оскільки діє «Вступна ціна $2/$10 за мільйон вхідних/вихідних токенів до 31 серпня 2026 року». Для кроку, який лише класифікує рядки логів, модель Opus не потрібна.

Рівень зусиль (effort) — це другий чинник впливу. output_config.effort приймає low, medium, high, xhigh та max; значення за замовчуванням — high, тому явне встановлення high не дає змін. Зменшення рівня зусиль впливає не лише на довжину роздумів: документація стверджує, що це змушує Claude робити менше викликів інструментів (tool calls) та об'єднувати операції в одну. Для агентів це дає більшу економію, оскільки уникнення виклику інструменту означає відміну цілого запиту.

Пастка полягає в тому, що рівень зусиль суперечить кешуванню. Зміна значення між запитами анулює кеш промпту (prompt caching). У наведеному прикладі запит 2 показав cache_read_input_tokens: 3546; запит 3, де рівень зусиль було змінено з high на medium, показав cache_creation_input_tokens 3546 та cache_read_input_tokens 0. Тому змінюйте рівень зусиль між різними робочими навантаженнями, а не всередині однієї кешованої розмови. Щоб керувати глибиною обробки без порушення кешу, робіть це в промпті: фраза на кшталт «Answer directly without deliberating.» у останньому повідомленні користувача дозволить зберегти попередні точки розриву (breakpoints) незмінними.

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

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

Запис у кеш коштує у 1.25 рази дорожче за базову ціну вводу для 5-хвилинного кешу та у 2 рази дорожче для 1-годинного кешу. Читання з кешу коштує 0.1 від базової ціни. Отже, «кешування стає вигідним вже після одного читання для 5-хвилинного кешу (запис 1.25x) або після двох читань для 1-годинного кешу (запис 2x)».

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

Три способи неявного розриву кешу.

Зміна префікса. «Префікси кешу створюються у такому порядку: tools, system, потім messages». Будь-яка зміна байта на попередніх етапах анулює всі наступні дані. Редагування визначень інструментів (tool definitions) також анулює весь кеш. Поширеною помилкою є використання часової мітки або run id у системному промпті: кожен запит отримує новий префікс, створює новий запис за ціною 1.25x і не отримує жодного збігу в кеші. Ознакою є usage.cache_read_input_tokens у значенні 0 при ідентичних на вигляд викликах. Перенесіть мінливий текст у останнє повідомлення користувача.

Занадто короткий префікс. Кожна модель має мінімальну довжину для кешування. Якщо довжина менша за цей ліміт, запит обробляється без кешування, при цьому «помилка не повертається». Ліміти становлять 1,024 токени для Claude Opus 4.8 та Claude Sonnet 5, та 4,096 токени для Claude Haiku 4.5. Отже, перехід з Sonnet на Haiku може непомітно вимкнути кешування.

Розмір діалогу перевищує вікно перегляду. «Вікно перегляду становить 20 блоків». Система перевіряє максимум 20 позицій на кожній точці розриву (breakpoint) і зупиняється. У наведеному прикладі: поворот, що містить 35 блоків з точкою розриву на 35-му блоці, перевіряє блоки від 35 до 16. Запис попереднього повороту на 15-му блоці виходить за межі вікна, тому збіг відсутній. Агент, який додає кілька блоків використання інструментів (tool-use) та результатів інструментів (tool-result) за кожен поворот, перевищує ліміт у 20 блоків за два або три повороти. На кожен запит припадає чотири точки розриву, тому виділяйте одну з них на останні повідомлення.

Надсилайте завдання, які можуть почекати, через Batches API

"Вартість використання становить 50% від стандартних цін API" як для вхідних, так і для вихідних даних. Пакетна обробка є асинхронною. "Більшість пакетів завершується менш ніж за 1 годину". Результати доступні після завершення всіх запитів або через 24 години, залежно від того, що настане раніше. Це типовий показник, а не гарантований.

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

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

Логуйте поля використання кожного запиту у власне сховище

Ви не зможете врахувати витрати, які не були зафіксовані. Кожна відповідь містить дані про її вартість.

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

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

Для отримання точних даних 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[]=. Обмеження: «Admin API недоступний для індивідуальних акаунтів».

Цей останній параметр — простий спосіб атрибуції: надайте кожному завданню власний 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 обмежує одну відповідь, а моделі лише повідомляється бюджет завдання.

Встановіть друге обмеження поза процесом. Запускайте завдання за допомогою systemd timer замість постійного процесу та встановіть RuntimeMaxSec= у юніті сервісу. З використанням RuntimeMaxSec=600 зависле виконання буде завершено через десять хвилин, а не триватиме до вашої уваги. Running a program as a systemd service and timer описує роботу з файлами юнітів. Щоб дізнатися результат виконання, використовуйте journalctl -u triage-agent.service --since "1 hour ago".

Також обмежте кількість повторних спроб, оскільки кожен повторний запуск обробника створює витрати. Помилки 429 або 500 потребують кількох спроб із затримкою (backoff). Помилка 400 не потребує повторів, оскільки той самий запит призведе до того самого результату.

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

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

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

FAQ

Скільки коштує запуск AI-агента в режимі 24/7 на VPS?

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

Яка різниця між max_tokens та task budget?

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

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

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

Як зупинити AI-агента від нескінченного циклу?

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

Чи можу я встановити ліміт витрат для одного Claude API key?

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