Управление подписками claude / codex / kimi — варианты

По принципу cswap: слоты аккаунтов, свап кред-файлов под локами, живой usage-дашборд, авто-переключение до упора в лимит. Ниже — что уже стоит на машине, четыре варианта архитектуры и опции. Выбери вариант (клик по карточке), отметь опции и пришли ссылку из планки внизу.

Что уже стоит (инвентаризация, WSL Ubuntu)

cswapclaude

claude-swap 0.24.1 (uv tool, Python) — эталон принципа
Слоты, алиасы, TUI-дашборд, 5h/7d + per-model usage
Авто-свитч: threshold/hysteresis/cooldown, карантин мёртвых токенов
Session-mode (cswap run) — параллельные аккаунты
Скриптовый контракт: list/status --json, auto --json event-stream
Свапает ~/.claude/.credentials.json под локами Claude Code

Работает, менять нечего — источник паттерна.

codex-authcodex

@loongphy/codex-auth 0.2.10 (npm) — уже в бою
3 аккаунта (pro / team / pro), registry.json с usage и кредитами
Демон в systemd: авто-свитч при 5h<10%, weekly<5%
CLI: list / status / login / import / switch / remove / config
Свапает ~/.codex/auth.json, бэкапит per-account
⚠ его usage-API помечен «может привести к ограничениям OpenAI»

Работает. Вопрос — оставлять движком или заменять.

— нет —kimi

kimi-cli (uv tool), один аккаунт, никакого свитчера
Креды: ~/.kimi/credentials/kimi-code.json (OAuth: access + refresh, expires_at) + .lock рядом
Usage API есть: GET {base}/usages c Bearer — weekly limit + окна limits[]
Токен-рефреш kimi-cli делает сам по expires_at

Дыра: свитчер kimi придётся писать с нуля в любом варианте.

Статистика по всем аккаунтам — и без тормозов (требование, входит в каждый вариант)

Показ usage по всем аккаунтам codex/claude/kimi разом — и чтобы ни просмотр, ни свитч, ни набор в панели никогда не ждали сеть. Принцип тот же, что внутри cswap, но вынесен на уровень всех трёх провайдеров:

UI никогда не ходит в сеть. Любой показ (subs list, TUI, статус-строка, панель tm2027) читает только локальный кэш usage-cache.json — ответ мгновенный, у цифр маркер возраста «· 4m ago», как в cswap.
Один фоновый пуллер опрашивает провайдеров параллельно (три независимых потока — тормоз одного API не задерживает остальных) и пишет кэш атомарно.
Адаптивная частота: активный аккаунт — чаще (~1–2 мин), простаивающие — реже, исчерпанные — ~раз в 10 мин, после 429 — backoff. Трафик к API плоский при любом числе аккаунтов и открытых дашбордов.
Отказоустойчиво: API недоступен → показываются последние известные цифры с возрастом, никакой пустоты и никаких блокировок.
Для claude и codex пуллер не дублирует опросы — забирает готовые цифры из кэшей cswap и registry.json codex-auth (они уже поллят сами); свой опрос только для kimi.

Варианты архитектуры

AТри свитчера: дописать только kswap

cswap и codex-auth не трогаем. Пишем kswap — маленький клон cswap для kimi (add / list / switch / auto), свапающий kimi-code.json и поллящий /usages.

cswapcodex-authkswap ← новый

↓↓↓

.claude/.credentials.json.codex/auth.json.kimi/credentials/*.json

три независимых инструмента, три демона, три UX

Минимум кода и риска — рабочее не трогается

cswap и codex-auth дальше обновляются upstream'ом

Быстрее всех: день работы

Три разных CLI и три дашборда — нет общей картины

Логика авто-свитча размножена трижды

«Сколько у меня всего осталось» — нигде не видно

объём: ~1 деньриск: низкийнового кода: только kswap

BЕдиный пульт поверх движков (рекомендую)

Один CLI/TUI subs с адаптерами: claude → JSON-API cswap, codex → registry + CLI codex-auth, kimi → свой нативный адаптер (его всё равно писать). Одна таблица всех аккаунтов трёх провайдеров, subs switch codex 2, один вотчер, который делегирует свитчи движкам.

subs — один пульт: list / switch / auto / tui

↓ json↓ cli/registry↓ нативно

cswapcodex-authkimi-адаптер

движки живут своей жизнью, пульт агрегирует и командует

Одна панель: все подписки, usage, кто активен — разом

Рабочие движки переиспользуются, а не переписываются

kimi-адаптер — единственный по-настоящему новый кусок

Готовый бэкенд для панели в tm2027 потом

Зависимость от JSON-контрактов cswap / codex-auth (могут дрейфовать)

Под капотом остаются их собственные демоны — координация

объём: 2–3 дняриск: средний-низкийнового кода: агрегатор + kimi-адаптер

CОдин движок: своя реализация на всех

Полная замена: один инструмент со слотами для всех трёх провайдеров, свои usage-пуллеры (Anthropic, ChatGPT backend, Kimi), один демон, один конфиг. cswap и codex-auth сносятся.

uniswap: слоты · usage-пуллеры · авто-демон · TUI

↓↓↓

.claude/….codex/….kimi/…

cswapcodex-auth

всё своё, upstream-инструменты выбрасываются

Идеальная унификация: одна модель слотов/алиасов/экспорта

Никаких чужих контрактов и чужих демонов

Много работы: локи Claude Code, OAuth-нюансы трёх провайдеров, карантины

Теряются upstream-фиксы cswap (он живой и умный)

Риск сломать сегодня работающие свитчи claude и codex

Ответственность за «OpenAI может забанить за usage-API» — на нас

объём: 1–2 неделириск: высокийнового кода: всё

DB + панель в tm2027

Вариант B как бэкенд, плюс сразу панель Subscriptions в деке tm2027: карточки аккаунтов с usage-барами, свитч кликом, событList авто-свитча в статусбар. Дека уже умеет WSL-мост — данные берутся вызовом subs --json.

tm2027 — панель Subscriptions (GPUI)

↓ wsl.exe · subs --json

subs (вариант B)

cswapcodex-authkimi-адаптер

усидж и свитчи — там же, где терминалы

Всё в одном окне: панели агентов и их лимиты рядом

Авто-свитч виден как notice в статусбаре деки

B остаётся самостоятельным CLI — деке он не обязателен

Самый долгий путь до результата

GPUI-вёрстка + протокол к WSL — отдельный пласт работы

объём: B + 3–4 дня декириск: среднийэтапность: можно B сейчас, деку потом

Сравнение

	A · три свитчера	B · единый пульт	C · один движок	D · B + tm2027
Общий дашборд трёх подписок	нет	да	да	да, в деке
Рабочие cswap/codex-auth	не трогаем	переиспользуем	выбрасываем	переиспользуем
kimi мультиаккаунт + авто-свитч	да (kswap)	да (адаптер)	да	да
Объём работ	~1 день	2–3 дня	1–2 недели	~неделя
Риск сломать работающее	низкий	низкий	высокий	средний
Upstream-обновления движков	сохраняются	сохраняются	теряются	сохраняются
Путь к панели в tm2027	нет базы	готовый бэкенд	свой API	сразу в комплекте

Опции (мультивыбор — к любому варианту)

Единый systemd-вотчер

Один user-unit subs-watch вместо трёх демонов: сам дергает cswap auto --once / codex-auth / kimi-чек по расписанию.

Уведомления о свитчах в Windows

Авто-свитч любого провайдера → toast на хосте (через tm2027-нотификации или wsl-notify).

kimi: полный паритет с cswap

Не только switch, но и слоты/алиасы/экспорт-импорт/карантин мёртвых refresh-токенов.

Строка для статусбаров

subs status --line → «C:2 12% · X:1 4% · K:1 37%» — для tmux/herdr/статусбара деки.

Единый экспорт/бэкап

Один subs export — все аккаунты всех провайдеров в один файл (для переноса на новую машину).

Стратегия consume-first везде

Жечь сначала аккаунт с ближайшим weekly-резетом (как в cswap) — и для codex, и для kimi.

Открытые вопросы

Сколько kimi-аккаунтов планируется? Сейчас один — если второго не будет, kimi-часть сводится к usage-мониторингу без свитча.
Session-mode для codex/kimi (параллельные аккаунты в разных панелях, как cswap run) — нужен или достаточно глобального свитча?
Пульт ставим как uv tool (Python, как cswap) — ок? Альтернатива: Rust-бинарь, но для оркестрации это лишнее.