Использование подписки на нескольких компьютерах и приложениях

Одна подписка провайдера (Kimi, Moonshot, Together, DeepSeek), Meridian на домашнем сервере и Virtual Key на каждое устройство и приложение. Полный контроль над тем, кто и сколько съел.

Проблема

Многие провайдеры — Kimi, Moonshot, Together, Mistral La Plateforme, DeepSeek — продают подписку с фиксированной квотой, а не pay-as-you-go API. У вас один аккаунт и один upstream-ключ, но в реальной жизни вы хотите использовать эту подписку:

с нескольких устройств — рабочего ноутбука, домашнего ПК, личного MacBook, мобильного клиента;
из нескольких приложений — IDE (Cursor, Zed), AI-ассистенты (Claude Code, Codex), CLI-инструменты, самописные скрипты, чат-клиент;
с разными лимитами на разные сценарии — фоновые задачи должны быть ограничены строгим rate limit, а интерактивная работа — нет.

Прописать один и тот же upstream-ключ во все эти места — потеря контроля:

невозможно понять, какое приложение/устройство съело квоту;
при утечке ключа из одного приложения нужно ротировать его везде сразу;
невозможно отдельно ограничить фоновые скрипты, не трогая интерактив.

Кого это касается: индивидуальные разработчики и опытные пользователи, маленькие команды (2–3 человека), использующие один аккаунт провайдера на несколько устройств/приложений.

Что предлагает Meridian

Meridian разворачивается локально (Docker, бинарь) или на домашнем сервере / NAS / VPS. Upstream-ключ подписки лежит в одном месте — внутри Meridian. На каждое устройство и каждое приложение выпускается собственный Virtual Key с независимыми rate limit и (опционально) бюджетом.

Приложения настраиваются на OpenAI-совместимый эндпоинт Meridian (base_url) и получают свой VK вместо upstream-ключа. Дашборд показывает, какой VK сколько съел; отозвать доступ можно на уровне отдельного приложения, не трогая подписку в целом.

Сценарий

Разработчик имеет подписку Kimi и использует её с пяти разных мест.

Подготовка. Разработчик поднимает Meridian на домашнем сервере (или VPS, или в Docker локально на ноутбуке). Если устройства находятся в разных сетях — открывает доступ через VPN, обратный прокси с TLS или Cloudflare Tunnel.
Добавление провайдера. Так как Kimi отсутствует в списке встроенных провайдеров, он добавляется как custom-провайдер поверх базового openai-адаптера: указывается base_url Kimi (большинство китайских провайдеров OpenAI-совместимы) и единственный upstream-ключ подписки.
Создание VK на каждое назначение. Разработчик через UI создаёт пять VK: vk-cursor-work, vk-cursor-home, vk-claude-code, vk-cli-scripts, vk-background-jobs. Для фоновых заданий задаётся жёсткий лимит 10 req/min; для интерактивных клиентов — без лимита или мягкий.
Настройка приложений. В каждом приложении (Cursor, Claude Code, CLI-скрипты) меняется base_url на адрес Meridian и api_key на соответствующий VK.
Наблюдение. Через Logs и Prometheus-метрики разработчик видит, какой VK сколько съел; при подозрении на утечку конкретного VK (например, скрипт ушёл в продакшен) — отзывает его одним действием (is_active: false), остальные продолжают работать.

Конфигурация

Шаг 1. Добавление Kimi как custom-провайдера.

Откройте Providers → Add New Provider.
Базовый тип: openai. Имя: kimi. base_url: https://api.kimi.com/coding (или соответствующий эндпоинт вашего провайдера).
Добавить заголовки HTTP запросов: User-Agent:claude-code/0.1.0 и X-Client-Name:claude-code
Добавьте upstream-ключ подписки, полученный на сайте Kimi.

Шаг 2. Создание VK на каждое назначение.

Virtual Keys → Add Virtual Key.
Имя: vk-cursor-work (повторите для каждого приложения/устройства).
Provider Configs: добавьте kimi с разрешёнными моделями.
Для фоновых VK задайте Request Limit: 10, Reset Duration: 1m.

Шаг 3. Настройка приложений.

В каждом клиенте (Cursor, Claude Code и т. п.) укажите:

Base URL: https://<ваш-meridian>:8080/v1
API Key: sk-bf-<имя-vk> (значение из созданного VK)

Большинство нишевых провайдеров (Kimi/Moonshot, DeepSeek, Together, Fireworks и т. д.) предоставляют OpenAI-совместимый API. Для них достаточно base_provider: "openai" с правильным base_url. Если провайдер использует нестандартную схему путей — добавьте request_path_overrides, см. Custom-провайдеры.

Что вы получаете

Единая точка управления подпиской для всех ваших устройств и приложений. Upstream-ключ хранится только в Meridian.
Видимость «какое приложение сколько съело» в дашборде и логах с разбивкой по VK.
Отзыв доступа на уровне приложения, а не подписки в целом. Утечка одного VK не вынуждает ротировать ключ во всех приложениях.
Разные лимиты на разные сценарии. Фоновые скрипты ограничены rate limit, интерактивные клиенты — нет.
Прозрачная замена для приложения. Любой OpenAI-совместимый клиент (Cursor, IDE-плагины, openai SDK) работает без изменений в коде — только смена base_url и api_key.

Ограничения и подводные камни

Meridian должен быть доступен с каждого устройства. Варианты: домашний сервер с проброшенным портом, VPS, локальный Docker на каждом устройстве (с общим config_store, если нужна синхронизация конфигурации).
TOS провайдера. Подписка может прямо запрещать многоустройственное использование одного аккаунта или работу через прокси. Это юридический вопрос, не технический; ответственность за соответствие — на вас.
Семантика «приоритетов» (интерактив важнее фона) — через разные rate limits, не через очереди. Приоритетных очередей в этом форке нет; гарантировать «фон не съест квоту, нужную интерактивному запросу» можно только заранее заданными лимитами.
Один upstream-ключ — единая точка отказа. При отзыве/блокировке ключа провайдером пострадают все VK одновременно. Если у вас есть запасные подписки — добавьте их как второй ключ с весовой балансировкой (см. Управление ключами провайдеров).
Безопасность. При публичном доступе Meridian обязательно настройте HTTPS и enforce_auth_on_inference: true. См. Управление и учёт.

Связанные материалы

Виртуальные ключи — на каждый VK можно задать собственный бюджет и rate limit.
Бюджеты и лимиты — детально о rate limits по запросам и токенам.
Custom-провайдеры — добавление произвольного OpenAI-совместимого провайдера.
Управление ключами провайдеров — взвешенная балансировка между несколькими подписками одного провайдера.
Защита от опустошения бюджета и отказа в обслуживании — pre-LLM estimation как защита, если квота подписки конвертируется в денежный лимит.