# Балансы оплаченных сервисов: как не узнать от клиента, что кончились деньги на API

Деньги на API кончаются молча. Где остаток виден по API, где нужна ручная цифра с датой, какие пороги ставить и почему следилке нужен пульс снаружи.

URL: https://posts.danashkin.ru/guides/balansy-oplachennyh-servisov
Обновлено: 2026-09-28

---

## Коротко

**Главное**

- У самосборного продукта десятки мелких платных аккаунтов, и деньги на каждом кончаются в свой момент. Узнают об этом обычно по упавшей функции, а не по предупреждению.
- Мониторинг баланса API работает не везде. У меня остаток читается программно у 13 аккаунтов из 27, для остальных нужна ручная цифра с датой снятия.
- Предупреждать надо по порогам в валюте аккаунта, одной тревогой на один факт. Отдельная тревога нужна на дату «оплачено до» у хостинга и домена.
- Следилка, которая живёт на том же хостинге, что и продукт, погаснет вместе с ним. Я это правило смягчил, но только с внешней проверкой пульса.

## Почему деньги на API кончаются внезапно?

**Главное**

Потому что аккаунтов много, у каждого свой темп расхода и свой кабинет. Сервис не шлёт письмо «денег осталось на три дня», он просто начинает отвечать ошибкой. Первым её замечает пользователь продукта, то есть клиент.

Когда собираешь продукты через [вайбкодинг](/concepts/vibecoding), платные аккаунты копятся незаметно. Доступ к нейросети через посредника, второй посредник про запас, сервис поиска, озвучка, хостинг, домен. Я пересчитал свои и насчитал 27 кандидатов на слежку по всем проектам.

Хуже всего с общими аккаунтами. У меня один посредник к нейросетям оплачивает запросы сразу шести проектов, другой - четырёх. Ни один проект не видит, сколько осталось всего, потому что каждый знает только свою долю расхода.

Раз в неделю я тратил от пятнадцати до тридцати минут на обход кабинетов. И всё равно пропустил.

В моём сервисе замеров канал к одной нейросети двое суток отвечал ошибкой 429 «слишком много запросов», похожей на перегрузку. На деле у ключа не была подключена оплата, и причину искали глазами.

Что это значит на практике: деньги кончаются тихо. Если следить за ними некому, первым об этом узнает клиент.

## Где остаток виден по API, а где только руками?

**Главное**

Остаток по API отдают посредники к нейросетям, часть облаков и хостингов. Крупные поставщики моделей показывают только отчёт о расходе, подписки знают лишь дату продления. У меня программно читается 13 аккаунтов из 27, у двух из них частично.

Перед сборкой следилки я попросил агента пройтись по документации всех 27 сервисов, без единого вызова с реальными ключами. Картина получилась такая:

| Тип аккаунта | Остаток по API | Что делать |
|---|---|---|
| Посредники к нейросетям | обычно есть отдельный запрос остатка | читать по расписанию |
| Крупные поставщики моделей | нет, только отчёт о расходе по админ-ключу | ручная цифра и их собственные письма о лимитах |
| Облака и хостинги | часто есть, иногда сразу «дней до блокировки» | осторожно с ключом, см. ниже |
| Сервисы озвучки и данных | есть в своих единицах: символы, кредиты, токены | показывать как есть, без пересчёта в рубли |
| Подписки | нет, есть дата продления | следить за датой |

Итог по моему списку: у четырнадцати аккаунтов остатка по API нет вовсе. Это не дыра в следилке, это её нормальная половина. Для таких аккаунтов сторож хранит ручную цифру и дату, а первой линией остаются уведомления самого сервиса.

Отдельно про единицы. Сервис озвучки отдаёт остаток в символах, один из поставщиков моделей - в токенах. Перевод в рубли - уже оценка, поэтому показывай единицы самого сервиса.

## Ключ для чтения остатка часто умеет тратить

**Главное**

У большинства сервисов остаток читается тем же ключом, которым тратятся деньги, а у хостингов ещё и управляются серверы. Честный ключ «только на чтение» у меня нашёлся всего у двух сервисов из 27. Поэтому в следилку кладутся только ключи, потеря которых стоит не больше остатка.

Из тринадцати читаемых аккаунтов у восьми остаток отдаётся только ключом, который умеет тратить деньги или управлять серверами. Ещё у двух это под вопросом. Даже у крупного посредника к нейросетям документация требует для остатка ключ управления, а не обычный рабочий.

Собрать такие ключи в одном сервисе со страницей входа в интернете - риск крупнее самой проблемы. Пустой баланс у меня пока обходился временем на поиск причины, а утёкший ключ от хостинга стоит денег сразу.

Правило я сформулировал так: ключ попадает в следилку, только если худшее, что с ним сделают, - потратят остаток на этом же аккаунте. Предоплата, без автопополнения с карты, без управления серверами. Ключи хостинга и регистратора домена в следилку не кладутся, для них ручная цифра и родные уведомления.

Где и как хранить сами ключи, чтобы они не утекли через код, подробно разобрано в статье о том, [где хранить ключи своего продукта](/guides/gde-hranit-klyuchi-svoego-produkta).

## Как вести ручную цифру, чтобы она не врала?

**Главное**

Каждая ручная цифра хранится с датой снятия и сроком годности, у меня это семь дней. Протухшая цифра - повод для напоминания. Пересчитывать её «минус расход» нельзя, а непрочитанный остаток нельзя показывать нулём или вчерашним числом.

Ручная цифра - это снимок: зашёл в кабинет, увидел 1 200 рублей, записал с датой. Через неделю снимок ничего не говорит о сегодняшнем дне, и таблица обязана это показывать.

Три правила, которые держат ручную цифру честной:

- **Время снятия у каждой цифры.** Без него свежий остаток и цифра месячной давности выглядят одинаково.
- **Срок годности.** Цифре больше семи дней - строка желтеет, и следилка просит обновить.
- **Никакого «минус расход».** Соблазн понятен: знаешь вчерашний остаток и примерный расход, вычел и получил сегодняшний. Это уже прогноз, а выглядит он как факт.

С автоматическими цифрами та же логика. Сервис не ответил - в строке статус «не прочиталось», а не ноль и не прошлое значение. Ноль пугает зря, прошлое значение успокаивает зря, и второе опаснее.

**Ложное спокойствие хуже отсутствия следилки**

Представь: следилка показывает 30 долларов, а в кабинете 3. Она прочитала лимит вместо остатка или выдала старую цифру за свежую. После одного такого случая ей перестают верить и возвращаются к ручному обходу.

## Какие пороги ставить и как не утонуть в предупреждениях?

**Главное**

Два порога у каждого аккаунта в его валюте: жёлтый и красный. Ноль и минус - сразу красный. Прогноз «на сколько дней хватит» считать только по разнице ежедневных снимков остатка. Одна тревога на один факт, повтор только при ухудшении.

Порог в днях звучит красиво: «денег хватит на пять дней». Я пробовал считать дни по логам своего продукта, и расчёт ошибся бы в двадцать раз. В логе цена одного замера складывалась из двух разных аккаунтов, и разделить её задним числом было нельзя. У главного аккаунта ошибка шла в опасную сторону: «хватит надолго».

Поэтому схема такая:

- **Пороги в валюте аккаунта.** Жёлтый условно значит «пополнить на этой неделе», красный - «сегодня».
- **Прогноз по снимкам.** Раз в сутки остаток записывается, темп считается по разнице снимков, пополнения в расход не засчитываются. Первый прогноз появляется на второй день, до этого честный прочерк.
- **Дата вместо суммы.** У хостинга и домена важна дата «оплачено до». Тревога за четырнадцать и за пять дней: хостинг убивает дата, а не остаток.

Теперь про шум. Одно и то же предупреждение каждые три часа через неделю перестают читать. Поэтому одна тревога на один факт, и ключ повтора включает уровень: переход из жёлтого в красный - новое сообщение.

Обратная ошибка тоже бывает. В одном разобранном случае следилка за пульсом замолчала на 43 дня: ключ повтора был привязан к сервису, а не к конкретному сбою, старые тревоги никто не закрывал, и каждый новый сбой система считала дублем первого.

## Почему сторож не должен жить на том хостинге, за которым следит?

**Главное**

Потому что при блокировке хостинга за неуплату следилка погаснет вместе с продуктом ровно тогда, когда должна кричать. Я осознанно смягчил это правило ради скорости сборки и закрываю риск тремя компенсациями: внешний пульс, даты «оплачено до» и проверенные уведомления хостинга.

Самый опасный отказ следилки - молчание. Остановилось расписание, отвалился бот, закончились деньги на сервере, а снаружи это выглядит как хороший день без тревог.

Отсюда правило: сторож не живёт на хостинге, за балансом которого следит. Я его нарушил. Следилку для своих аккаунтов я собираю вкладкой в своей рабочей платформе, а платформа стоит у того же хостинга.

Так я переиспользую готовый вход, базу, расписание и выкладку. Вынести следилку отдельно - значит строить всё это заново, а потом ещё раз переезжать.

Нарушение я закрываю тремя компенсациями:

1. **Внешний пульс.** Сторож после каждого обхода отмечается в бесплатном сервисе проверки пульса. Обход идёт раз в три часа. Нет отметки дольше четырёх часов - приходит сообщение от внешнего сервиса, а не от самого сторожа.
2. **Даты «оплачено до»** у хостинга, регистратора и домена с тревогой за две недели и за пять дней.
3. **Родные уведомления хостинга,** проверенные руками до запуска.

Ещё один пульс - утренняя сводка. Она приходит всегда, даже когда всё в порядке. Нет сводки утром - это уже сигнал.

Про то, почему у автоматизации тишина - самая частая поломка, я писал в материале про [автозадачи, которые работают без тебя](/guides/avtozadachi-agent-rabotaet-bez-tebya).

## Один обход кабинетов вместо еженедельных

**Главное**

Следилка начинается с одного полного обхода: список аккаунтов, ключи, пороги, родные уведомления. Неподключённый аккаунт не прячется, а висит в утренней сводке каждый день. Иначе следилка выглядит готовой, а смотрит на пятую часть денег.

Мой первый сторож для хостинга был написан, но месяц молчал: ему так и не выдали токен. Снаружи это ничем не отличалось от спокойного месяца. Поэтому порядок такой:

1. **Составить список**

   Все платные аккаунты по всем проектам одной таблицей: сервис, какие проекты на нём живут, предоплата или подписка.

2. **Разметить по API и ключам**

   У каждого аккаунта: читается ли остаток, каким ключом, что этот ключ умеет кроме чтения.

3. **Включить родные уведомления**

   Письма о лимитах, боты хостингов, напоминания регистратора. Это первая линия там, где API нет.

4. **Задать пороги и даты**

   Жёлтый и красный порог в валюте аккаунта, даты «оплачено до» у хостинга и домена.

5. **Проверить подставной тревогой**

   Временно поднять порог выше текущего остатка и убедиться, что сообщение пришло.

Аккаунт без ключа или без цифры остаётся строкой «не подключён» и каждое утро попадает в сводку, пока не подключишь или не уберёшь его.

## Частые вопросы

**Главное**

Чаще всего спрашивают про автопополнение, про то, нужна ли тут нейросеть, куда девать подписки и как часто проверять остатки.

### Частые вопросы

**Почему не включить автопополнение везде?**

Оно есть не у всех сервисов и прячет проблему списанием с карты. А ключ от аккаунта с автопополнением я в следилку не кладу: его утечка стоит больше остатка.

**Нужна ли для такой следилки нейросеть?**

Нет. Следилка читает числа и сравнивает их с порогами. Нейросеть пригодится при сборке, а работать продукт будет без неё, это разобрано в статье о том, [нужен ли Claude готовому приложению](/guides/nuzhen-li-claude-gotovomu-prilozheniyu).

**Что делать с подписками?**

У подписки нет остатка, есть дата продления. В первую версию я их не беру, для них хватает писем о продлении.

**Как часто проверять остатки?**

Я заложил обход раз в три часа плюс утреннюю сводку. Чаще имеет смысл, только если деньги сгорают за часы.

## Главный вывод

**Главное**

Деньги на API кончаются молча, поэтому следилка должна говорить и о нехватке, и о собственной поломке. Остаток по API, ручная цифра с датой, пороги в валюте аккаунта, одна тревога на факт и пульс снаружи.

Хорошая следилка за балансами скучная. Она пишет редко, всегда по делу и честно говорит «не знаю», когда цифры нет.

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

А ты знаешь, сколько сейчас денег на каждом аккаунте, от которого зависит твой продукт?

### Источники

- [Get remaining credits - остаток на счёте по API и требование ключа управления, OpenRouter](https://openrouter.ai/docs/api/api-reference/credits/get-remaining-credits)
- [Usage and Cost API - отчёт о расходе по админ-ключу вместо остатка, Claude Platform Docs](https://platform.claude.com/docs/en/manage-claude/usage-cost-api)
- [Get user subscription - израсходованные символы и лимит подписки, ElevenLabs](https://elevenlabs.io/docs/api-reference/user/subscription/get)
- [429 Too Many Requests - код ответа «слишком много запросов», MDN](https://developer.mozilla.org/en-US/docs/Web/HTTP/Reference/Status/429)
- [Healthchecks.io Documentation - проверка пульса: сервис молчит, пока отметки приходят вовремя, Healthchecks.io](https://healthchecks.io/docs/)
- [A Dead-Man's Switch That Pages Once and Goes Quiet Is Worse Than None - разбор 43 дней тишины из-за ключа повтора тревоги, DEV Community](https://dev.to/merlonix/a-dead-mans-switch-that-pages-once-and-goes-quiet-is-worse-than-none-ours-went-silent-for-43-days-1f0n)
- [Dead man's switch - выключатель, который срабатывает, когда оператор перестаёт подавать сигнал, Википедия](https://en.wikipedia.org/wiki/Dead_man%27s_switch)