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

Коротко

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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