Несколько проектов на одном аккаунте: как не запутаться

Фрилансер с тремя клиентами, агентство с параллельными проектами, разработчик, который держит рабочий и личный код на одном логине — во всех случаях баланс на аккаунте один, а источников расхода несколько. Проблема начинается не с самого расхода, а с того, что в конце месяца непонятно, кто из проектов сколько съел.

Баланс общий, ключи — нет

GET /v1/balance возвращает баланс аккаунта целиком — это одна цифра на всех, независимо от того, сколько ключей выпущено и сколько проектов их использует. А вот дневной и месячный лимит расхода в долларах и список разрешённых моделей настраиваются на странице конкретного ключа в /app/api-keys — это уже per-key, а не per-account. Отсюда практическая схема: один аккаунт, общий баланс для пополнений, но отдельный ключ под каждый проект со своим лимитом.

curl https://api.zukko.pro/v1/balance \
  -H "Authorization: Bearer fetch_любой_ключ_этого_аккаунта"

Неважно, каким из ключей аккаунта дёрнуть /v1/balance — цифра будет одна и та же, потому что баланс общий.

Как разложить расход по проектам, если баланс один

Раз баланс общий, а лимиты — per-key, отслеживать "чей это был расход" нужно через два источника, а не один:

• Заголовки X-Zukko-Cost-Micros и X-Fetch-Balance-Cents в каждом обычном (не потоковом) ответе — стоимость конкретного запроса и остаток на аккаунте после него (оба в микродолларах, несмотря на «Cents» в названии второго). Записанные в лог вместе с ключом, они и дают разбивку по проектам.
• GET /v1/usage — история списаний по всему аккаунту (все ключи вместе, фильтра по ключу нет), с курсорной пагинацией — для сверки общей суммы и для потоковых запросов, у которых заголовков стоимости нет.

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

Если для каждого клиента или проекта завести свой ключ и логировать X-Zukko-Cost-Micros по каждому ключу отдельно, к концу месяца сумма по ключу клиента A даёт его счёт — не нужно делить общий расход по аккаунту пропорционально на глазок. Если клиент работает через потоковые запросы (stream: true), заголовков у них нет — для строгого разделения такому клиенту лучше завести отдельный аккаунт.

Лимит на ключ как защита от одного зарвавшегося проекта

Если один из проектов — например, скрипт с автогенерацией контента для клиента B — вдруг зациклится и начнёт слать запросы пачками, при общем ключе на все проекты это ударит по балансу, который питает и клиента A, и клиента C. При отдельном ключе на проект с выставленным дневным лимитом такой скрипт упрётся в свой собственный потолок и остановится с 429 key_daily_limit_reached, а баланс аккаунта для остальных ключей останется нетронутым.

Список разрешённых моделей — способ держать проекты в своих рамках

Если для клиента A по контракту зафиксирован бюджет на модели уровня glm-5.3-flash, а клиент B оплачивает работу с claude-opus-5-5, ограничение списка моделей на уровне ключа гарантирует это технически: ключ клиента A физически не сможет вызвать дорогую модель, даже если это произойдёт по ошибке в коде. Попытка вернёт 403 model_not_allowed_for_key вместо неожиданного счёта не по тому тарифу.

Пополнение — общее, трата — раздельная

Оплата баланса — через СБП, банковскую карту (PayPear), крипту или, с 16 сентября 2026 года, иностранную карту Mastercard EU через Fride (комиссия около 13%, суммы $2–$594) — идёт на аккаунт целиком, а не на конкретный ключ. Это удобно: не нужно пополнять пять раз для пяти проектов. Но именно поэтому важно не полагаться на память о том, "чей был последний платёж" — вся отчётность по проектам должна идти через ваши логи заголовков стоимости по ключам (а /v1/usage — для сверки общей суммы), а не через историю пополнений баланса; сами пополнения в /v1/usage не попадают.

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

10% с пополнений приглашённых пользователей начисляются на баланс того, кто пригласил. Если ведёшь несколько клиентских проектов и советуешь им завести свой аккаунт вместо использования твоего ключа — это не только чище с точки зрения биллинга (у каждого клиента свой лимит и своя история), но и даёт процент с их пополнений через реферальную программу.

Практическая раскладка

Для агентства с несколькими клиентами: один аккаунт, один способ оплаты, но:

export FETCH_KEY_CLIENT_A=fetch_...   # лимит $50/мес, только glm-5.3-flash и gpt-5.6-luna
export FETCH_KEY_CLIENT_B=fetch_...   # лимит $200/мес, claude-opus-5-5 разрешён
export FETCH_KEY_INTERNAL=fetch_...   # лимит $10/день, для тестов и демо

Каждый ключ живёт в переменных окружения своего проекта, каждый лимит выставлен под конкретный контракт, а сумма X-Zukko-Cost-Micros по каждому ключу из ваших логов в конце месяца — это уже готовый счёт клиенту, а не повод пересчитывать общий расход аккаунта вручную.

Проверка статуса сервиса не должна зависеть ни от одного из ключей

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

curl https://api.zukko.pro/api/status

Общий мониторинг-скрипт, который следит за доступностью для всех проектов сразу, может дёргать /api/status без привязки к какому-либо из клиентских ключей — если он упадёт из-за исчерпанного лимита одного клиента, статус остальных проектов будет неверно интерпретирован как авария. Отдельно от него GET /v1/models тоже отдаёт список без ключа — полезно для проверки, что нужная модель ещё в каталоге, прежде чем разбираться, почему конкретный ключ клиента вернул 404 model_not_found или 503 model_disabled.