Зачем стартапу шлюз вместо прямого биллинга у провайдера

Ранний стартап, который тестирует несколько моделей одновременно, обычно приходит к одному и тому же: под каждого провайдера — отдельная регистрация, отдельный способ оплаты, отдельный формат запроса. Claude ждёт /v1/messages с заголовком anthropic-version, OpenAI — /v1/chat/completions, у остальных свои нюансы. Шлюз с одним ключом fetch_... убирает это дублирование не потому, что как-то магически объединяет провайдеров, а потому, что отдаёт оба самых распространённых формата — Anthropic-совместимый и OpenAI-совместимый — из одной точки на одном балансе.

Один ключ, два протокола, вся линейка моделей

Ключ работает и с POST /v1/messages (для клиентов вроде Claude Code или Anthropic SDK), и с POST /v1/chat/completions или POST /v1/responses (для Cursor, Codex, OpenAI SDK). Это значит, что A/B-тест claude-opus-5-5 против gpt-5.6-sol на реальной задаче не требует переписывать клиентский код под второй формат запроса — меняется только адрес и тело запроса, а не инфраструктура вокруг ключей и биллинга.

Оплата без открытия счёта в другой юрисдикции

Прямой биллинг у Anthropic или OpenAI обычно завязан на карту, выпущенную в поддерживаемой стране, и это отдельная административная задача для команды без иностранного юрлица. Здесь доступны СБП, банковская карта через PayPear, оплата криптовалютой и — с 2026-09-16 — иностранная карта Mastercard EU через Fride (комиссия около 13%, суммы от $2 до $594). Минимальное пополнение — $1. Для команды из одного-двух человек на старте это разница между «настроили за десять минут» и «ищем, у кого занять иностранную карту».

Лимиты на ключ как бюджетный контроль, а не как ограничение

У каждого ключа можно задать дневной и месячный лимит расхода в долларах и список разрешённых моделей — настраивается на странице ключа в кабинете. На практике это удобно раздавать по ролям: ключ для junior-разработчика с доступом только к glm-5.3-flash и лимитом $5 в день, ключ для core-команды с доступом к claude-opus-5-5 без урезанного списка моделей. Один неудачный промпт в цикле или забытый крон-джоб при таком разделении сжигает бюджет одного ключа, а не весь баланс компании.

Баланс проверяется до похода к модели

Ошибка 402 — {"error":{"message":"Недостаточно средств на балансе","code":"insufficient_balance"}} — возвращается до того, как запрос уходит к провайдеру. Это значит, что сломанный деплой, который спамит запросами при нулевом балансе, не тратит ни цента, пока баланс не пополнят. Для стартапа на раннем этапе, где деплои случаются часто и не всегда аккуратно, это конкретная защита от неожиданного счёта, а не абстрактное удобство.

Учёт расходов без пяти личных кабинетов

GET /v1/usage отдаёт историю списаний с курсорной пагинацией (next_cursor; поля created_at, model, input_tokens, output_tokens, total_tokens, cost_cents в дробных центах) — можно затянуть в свою же таблицу учёта или дашборд, не заходя по очереди в консоли пяти разных провайдеров. История общая на весь аккаунт, все ключи вместе — фильтра по ключу нет. На уровне отдельного запроса в обычном (нестриминговом) ответе есть заголовки X-Zukko-Cost-Micros (стоимость этого конкретного запроса в микродолларах, где 1,000,000 = $1) и X-Fetch-Balance-Cents (остаток после списания — несмотря на название, тоже в микродолларах; точный баланс в центах отдаёт GET /v1/balance) — этого достаточно, чтобы на лету привязать стоимость запроса к конкретному клиенту, фиче или эксперименту, без отдельного похода в биллинг. У потоковых ответов (stream: true) этих заголовков нет — для них расход смотрят в кабинете, /v1/usage или /v1/balance.

Что происходит, когда провайдер меняет каталог

Модели выключают и заменяют, и это нормальная часть жизненного цикла API. Разница в том, как об этом узнаёт клиент: выключенная модель отвечает 503 с кодом model_disabled, а актуальный список всегда доступен через GET https://api.zukko.pro/v1/models (или на странице «Модели» в кабинете). Не нужно отслеживать changelog провайдера отдельно — стоит такой ошибке вылезти в логах прод-сервиса, и сразу видно, что менять в конфиге.

Идемпотентность как часть биллинговой гигиены

Заголовок Idempotency-Key возвращает тот же ответ на повтор запроса с тем же ключом и тем же телом в течение 24 часов, не списывая повторно. Ключ задаётся на каждый логический запрос — уникальный для запроса и одинаковый при его повторах; заново при ретрае его не генерируют. Работает это для POST /v1/chat/completions, /v1/messages и /v1/responses. Для стартапа, где ретраи на сетевых обрывах обычно пишутся на скорую руку, это разница между «пользователь два раза заплатил за один и тот же ответ» и «повтор ничего не стоил».

Реферальная программа как побочный источник компенсации

10% с пополнений приглашённых участников — если стартап и так рассказывает другим основателям о том, чем пользуется сам, реферальная ссылка компенсирует часть собственных расходов на API без дополнительных усилий.

Статус сервиса в собственном мониторинге

GET https://api.zukko.pro/api/status отдаёт публичный JSON со статусом моделей без ключа — его можно воткнуть в тот же статус-пейдж или health-check, который у команды уже настроен для собственных сервисов, вместо того чтобы вручную проверять, жив ли провайдер, когда падает продовый запрос. Для стартапа с одним дежурным на всё это означает на один источник неопределённости меньше в три часа ночи: если /api/status отвечает нормально, а запросы всё равно падают, проблема локальная, а не на стороне шлюза.

Поддержка без отдельного тикет-трекера

На раннем этапе заводить отдельный процесс эскалации к каждому провайдеру ради одного вопроса о биллинге — накладно. Здесь поддержка ведётся через Telegram @zukkopro↗, без формы, без ожидания ответа по почте несколько дней — для стартапа, где счёт идёт на часы простоя, это тоже часть операционной экономии, а не второстепенная деталь.

curl https://api.zukko.pro/v1/balance \
  -H "Authorization: Bearer fetch_ваш_ключ"

curl "https://api.zukko.pro/v1/usage?limit=50" \
  -H "Authorization: Bearer fetch_ваш_ключ"

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