BYOK без прикрас: 5 вещей, которые ломаются в Open Design сегодня

Мы говорим людям, что Open Design построен на BYOK с самого основания. Это по-прежнему так. Стартовый пост о рабочем процессе BYOK проходит по работающему пути — направьте daemon на любую совместимую с OpenAI конечную точку, вставьте свой ключ, и готово. Для большинства конфигураций это вся история, и она остаётся всей историей.

Но «BYOK» — это не одна функция. Это контракт, который дотягивается до составителя чата, конечной точки финализации, выбора модели, пути запуска CLI и слоя аналитики. Каждое из этих мест — точка, где контракт может сломаться, и прямо сейчас несколько из них являются открытыми issue в нашем публичном трекере, заведёнными пользователями за последние 48 часов.

Мы могли бы написать стартовый пост и на этом остановиться. Вместо этого вот честный разбор: треды, пришедшие на этой неделе, что ломается, почему ломается, что делать сегодня и какой PR (или слот в roadmap) это исправляет. Ничего из этого не скрыто. Всё заведено, размечено и приведено по ссылкам ниже — и мы предпочитаем, чтобы вы узнали об этом от нас, а не наткнулись на это посреди демонстрации в пятницу.

Обещание против списка багов

Постановка вопроса важна, потому что лёгкое неверное прочтение — «BYOK сырой». Это не так. Ни один из пяти ниже не является багом «BYOK не работает». Каждый из них живёт на границе между адаптером, который принадлежит нам — слоем совместимости с OpenAI, выбором модели, путём финализации — и тем, что нам не принадлежит: CLI вышестоящего провайдера, его решения по упаковке или модель процессов хост-платформы.

Эта граница — там, где в любом open-source CLI-оркестраторе живёт реальность. Мы не запускаем инференс, мы не поставляем форкнутый CLI под каждого провайдера и мы не оборачиваем всё в прокси, который сглаживает края (и тихо облагает налогом ваши токены). Цена такой позиции в том, что когда CLI провайдера меняет форму или Windows навязывает ограничение, которого нет у macOS, шов становится виден. На этой неделе пять таких швов проявились разом.

Вот все пять, в порядке поступления.

Gemini теряется по пути к «Finish Design»

Issue #1619 — bug, open

Симптом

BYOK настроен для Gemini. Тест подключения в настройках проходит успешно. Выбор модели возвращает модели Gemini. Обычный чат работает — вы можете провести полноценный разговор на собственном ключе Gemini без проблем. Но в тот момент, когда пользователь нажимает Finish Design, daemon выдаёт ошибку в форме Anthropic, словно он вдруг забыл, с каким провайдером он разговаривал.

Почему это происходит

Ответ мейнтейнера в треде это подтверждает: обычный чат в режиме API уважает выбранного BYOK-провайдера Gemini из конца в конец, но Finish Design ещё не обобщён за пределы пути финализации, совместимого с Anthropic. Всё остальное маршрутизируется через прокси с учётом провайдера, который умеет говорить на диалекте каждого upstream. Finish Design всё ещё идёт через жёстко прописанную конечную точку финализации Anthropic, оставшуюся от более раннего релиза — поэтому ответ Gemini, приходящий в форме, отличной от Anthropic, спотыкает парсер.

Обходное решение

Направьте Gemini через OpenRouter в слоте провайдера, совместимого с Anthropic. Тогда путь Finish Design видит ответ в форме Anthropic, возвращающийся из шима OpenRouter, и финализирует корректно. Это лишний переход, и вы платите за маршрутизацию OpenRouter, а не обращаетесь к Gemini напрямую, но это стабильно работает сегодня и покрывает тот единственный путь, который сломан, не задевая путь чата, который уже работает.

Кто это исправляет

Обобщение Finish Design теперь находится в roadmap BYOK как P1. PR пока нет — это следующее, за что возьмётся команда daemon, и это единственный из пяти, который является дефектом в коде, полностью принадлежащем нам, а не несоответствием на границе.

Gemini 3 Flash умирает на Windows ещё до того, как доходит промпт

Issue #1611 — bug, open

Симптом

Gemini 3 Flash Preview падает внутри Open Design на Windows с stdin: write EOF примерно через 1,5 секунды — ещё до того, как промпт вообще доходит до модели. Gemini 3 Pro прекрасно работает в той же самой установке. А прямой Gemini CLI (gemini --model gemini-3-flash-preview ...) срабатывает, когда установлено GEMINI_CLI_TRUST_WORKSPACE=true. Значит, дело не в ключе, не в аккаунте и не в CLI самом по себе.

Почему это происходит

Диагностика заняла два захода, и это стоит показать, потому что это хороший пример того, как такие вещи распутываются. Первое прочтение скриншота репортёра выглядело как ошибка квоты 429 RESOURCE_EXHAUSTED на стороне upstream. После чистого воспроизведения в PowerShell, которое записало OD_GEMINI_3_FLASH_OK в stdout, картина изменилась: модель доступна, CLI исправен, сбой происходит конкретно на пути запуска Open Design → Gemini CLI, и он специфичен для варианта Flash на Windows. Pro проходит тот же путь запуска и выживает; Flash — нет.

Обходное решение

Выберите Gemini 3 Pro Preview в выборе модели. Он проходит через тот же путь запуска и работает. Отдельно — и эта деталь отняла больше времени, чем сам баг — проверьте ~/.gemini/hooks/. Медленный хук gsd-check-update.js (Hook execution error: Hook timed out after 60000ms) добавлял примерно 104 с накладных расходов на каждый запуск в случае этого пользователя, совершенно независимо от сбоя Flash. Почистите свои хуки Gemini в любом случае; зависший хук проверки обновлений заставит любой агент казаться сломанным.

Кто это исправляет

Помечено как специфичное для Flash и относящееся к стороне OD. Расследование пути записи в stdin со стороны daemon в процессе — write EOF говорит, что stdin дочернего процесса закрылся до того, как daemon закончил писать промпт, так что исправление лежит в том, как именно порождается этот конкретный вариант.

У DeepSeek TUI на Windows потолок промпта в 30 КБ

Issue #1610 — bug, open

Симптом

На обёртке DeepSeek v0.8.33 в упакованной сборке для Windows длинный составленный промпт не проходит нашу предполётную проверку с 81397 > 30000 bytes. Пользователь не сделал ничего неправильного — он просто составил промпт, достаточно насыщенный (системный контекст, дизайн-система, референсы), чтобы перешагнуть за 30 КБ.

Почему это происходит

Эта проверка намеренная, и она защищает вас от ошибки похуже. Адаптер DeepSeek TUI сейчас отправляет промпт как позиционный аргумент командной строки — привязанный к argv — а Windows ограничивает общую длину командной строки заметно ниже, чем macOS и Linux. Без предполётной проверки тот же промпт упал бы позже, глубже в порождении процесса, с куда менее полезной ошибкой ENAMETOOLONG и без намёка на то, что причина была в размере промпта. Поэтому мы падаем рано и называем число. Несоответствие, которое вскрывает этот issue, — в документации: высокоуровневые рекомендации подразумевают, что запасные варианты для длинных промптов на Windows применяются широко, но у пути DeepSeek TUI его пока нет — его транспорт по-прежнему argv, а не stdin или файл с промптом.

Обходное решение

Если вы на Windows с адаптером DeepSeek TUI, держите составленный промпт меньше 30 КБ или переключитесь на адаптер на основе stdin — Claude Code, Codex и OpenCode все принимают промпт через stdin и не имеют сопоставимого потолка. На macOS и Linux эта проблема вообще не кусается; лимит argv там достаточно высок, чтобы реальные промпты до него не дотягивались.

Кто это исправляет

Правильное исправление — транспорт через stdin или файл с промптом для адаптера DeepSeek TUI, что полностью убирает потолок argv и приводит его в соответствие с адаптерами на stdin. Это отслеживается в очереди команды адаптеров.

Тест локального CLI OpenCode истекает по таймауту до того, как модель прогреется

Issue #1603 — bug, priority:p0, open

Симптом

В Settings → BYOK → OpenCode тест подключения стабильно истекает по таймауту на 45 секундах. Странность в том, что если пользователь сначала открывает терминал OpenCode Desktop и подключает там локальную LLM, то тот же тест Open Design затем срабатывает со следующей попытки.

Почему это происходит

Эта деталь «сначала открой терминал Desktop» — вся разгадка. Open Design не подключается к запущенной сессии OpenCode Desktop. Для smoke-теста в настройках daemon порождает собственный свежий подпроцесс OpenCode CLI и ждёт ответа ok. С холодной локальной моделью — той, что ещё не загружена в память — этот первый ответ может занять дольше, чем бюджет в 45 секунд, потому что модель считывается с диска и прогревается, прежде чем она вообще сможет что-то ответить. Открытие терминала Desktop и ответ на один промпт прогревает модель в кеше ОС так, что свежий подпроцесс daemon затем может сразу же этим воспользоваться. Так что это на самом деле не баг OpenCode; это неверное предположение о времени холодного старта для локальных моделей.

Обходное решение

Перед тестированием OpenCode в Open Design откройте OpenCode Desktop, подключите свою локальную LLM и дайте ей ответить на один промпт. Затем запустите тест подключения OD — модель прогрета, и ответ укладывается в бюджет. Начиная с v0.7.0 бюджет теста подключения также настраивается, так что если ваша локальная модель действительно медленно загружается, вы можете увеличить окно вместо того, чтобы прогревать её вручную.

Кто это исправляет

Исправление на стороне daemon — это более длинное или настраиваемое окно прогрева специально для адаптеров локальных моделей, чтобы холодную локальную модель не судили по тем же часам, что и хостируемый API. Это отслеживается с приоритетом p0 — наивысшим из пяти, потому что пользователи локальных моделей — это именно та аудитория, которой призван служить BYOK.

Упакованное веб-приложение отказывается загружаться по обычному HTTP

Issue #1620 — bug, open

Симптом

Немного другой баг, то же семейство. Репортёр запускает упакованное веб-приложение на LAN-IP по обычному HTTP, и страница падает при загрузке — она так и не доходит до рабочего состояния.

Почему это происходит

После PR #1428 провайдер аналитики и nonce экспорта PDF начали вызывать crypto.randomUUID() напрямую, минуя многоуровневый помощник, введённый в PR #900, который аккуратно откатывается, когда безопасный crypto API недоступен. Chromium не выставляет crypto.randomUUID в небезопасных контекстах — а голый LAN-IP по обычному HTTP, по определению Chromium, не является безопасным контекстом. Поэтому прямой вызов падает на этапе загрузки, и страница уходит вместе с ним. Строго говоря, это не баг BYOK, но он кусает ровно ту же аудиторию: людей, которые запускают собственную инфраструктуру, часто изолированную от сети, часто по обычному HTTP, потому что поднимать сертификат для внутреннего инструмента не стоит возни.

Обходное решение

Раздавайте веб-приложение по HTTPS или через localhost. Оба варианта удовлетворяют требованию безопасного контекста Chromium — localhost считается безопасным даже без сертификата — и страница загружается нормально. Для быстрой внутренней настройки localhost — путь с нулевыми затратами; для доступа по LAN самоподписанный сертификат поверх HTTPS — путь надёжный.

Кто это исправляет

PR #1621 направляет оставшиеся места вызова обратно через многоуровневый помощник UUID из PR #900, так что запасной вариант для безопасного контекста снова применяется везде, а не только там, где он уже был подключён. Он открыт и находится на ревью.

Что это на самом деле говорит о BYOK в Open Design

Читайте этот список как карту контракта, а не как вердикт о качестве. Четыре из этих пяти issue сидят на границах адаптеров — путь запуска CLI у Gemini, транспорт CLI с привязкой к argv у DeepSeek, модель холодного старта у OpenCode, правила безопасного контекста хост-платформы. Пятый, тот что с Finish Design, — на нашей собственной конечной точке финализации, где мы релиз назад жёстко прописали ответ в форме Anthropic и пока не обобщили его. Этот на нас; остальные четыре — налог, который вы платите за уважение к инструментам, которые создали не вы.

И в этом структурный смысл. Любая система BYOK, которая не является переименованным прокси, в итоге приходит сюда. Вы либо владеете инференсом — и теряете BYOK, потому что теперь это вы покупаете токены и накручиваете на них наценку — либо вы уважаете вышестоящие инструменты и наследуете их края: их CLI, их причуды упаковки, лимиты платформ, которые каждый обрабатывает по-своему. Мы намеренно выбрали вторую позицию и выбрали бы её снова. Цена — недели вроде этой, когда команды daemon и адаптеров завели работу по пяти поверхностям за два дня.

Размен всё ещё правильный. Рабочая конфигурация на Claude Code, Codex, Cursor, Gemini Pro на macOS и DeepSeek на Linux — матрица, которая покрывает примерно 90% наших реальных пользователей — сегодня работает чисто, без налога прокси и без наценки на ваши токены. Пять тредов выше — это то, как выглядят остальные 10% матрицы в середине мая 2026 года: названные, заведённые, и у каждого исправление в работе. Честные швы лучше гладкой поверхности, которая прячет, куда уходит счёт.

Чем пользоваться сегодня (матрица)

Это практическая версия раздела выше — те же пять швов, наложенные на то, к чему безопасно обращаться прямо сейчас. Значок ✓ означает, что путь работает как есть; ✗ ссылается на issue, который его блокирует, с обходным решением в соответствующем разделе.

Провайдер	macOS	Linux	Windows	Путь Finish Design
Claude Code (Sonnet / Opus)	✓	✓	✓	нативный
Codex	✓	✓	✓	нативный
Cursor (BYOK)	✓	✓	✓	нативный
Gemini 3 Pro Preview	✓	✓	✓	шим OpenRouter (#1619)
Gemini 3 Flash Preview	✓	✓	✗ (#1611)	шим OpenRouter (#1619)
DeepSeek (API)	✓	✓	✓	шим OpenRouter
DeepSeek TUI (длинные промпты)	✓	✓	✗ (#1610)	шим OpenRouter
OpenCode (локальная модель)	✓	✓	✓ (сначала прогрев, #1603)	n/a

Два прочтения этой таблицы. Если ваш стек в блоке со сплошными ✓ — Claude Code, Codex, Cursor или Gemini Pro — вы на чистом пути, и ничего из вышесказанного не меняет ваш день. Если вы на одной из строк с ✗, в соответствующем разделе есть обходное решение, которое поможет вам работать сегодня, пока выходит связанное исправление. В любом случае подпишитесь на метку BYOK в трекере, если хотите уведомление, когда строка переключится с ✗ на ✓.

Что делать дальше

Библиотека skills Open Design — это рабочий слой под всем этим: контракты на основе файлов, в которые подаёт данные адаптер BYOK, как только подключение исправно. Швы выше — про то, как доставить байты от вашего ключа к модели и обратно; skills — это то, что модель на самом деле с ними делает. Если вы хотите увидеть, что skill потребляет от модели, а что ему безразлично — это также и причина, по которой эти края адаптеров не меняют выход, а лишь то, дойдёте ли вы до него — эта директория и есть правильное место, чтобы начать.

Просмотреть библиотеку skills.

Похожее по теме

• Рабочий процесс дизайна на BYOK: запускайте Claude, Codex или Qwen на собственном ключе — исходное объяснение BYOK и рабочий путь, на краю которого сидят пять швов выше
• Почему мы построили Open Design как слой skill, а не как продукт — почему мы уважаем вышестоящие инструменты, а не оборачиваем их в прокси, что и есть главная причина существования этих границ
• 31 skill, 72 системы — как работает библиотека — во что на самом деле подаёт данные BYOK, как только подключение исправно