В начале сентября знакомые разработчики стали жаловаться на одно и то же: Cursor перестал работать, показывает not available in your region, у части пользователей отменились платные подписки. Первый совет, который разошёлся по чатам, звучал разумно: «в настройках есть поле для своего ключа OpenAI и переопределение базового адреса — подставьте туда любой доступный эндпоинт, и всё заработает».

Не работает. И причина этого интереснее самой новости, потому что она объясняет, какие инструменты вообще устойчивы к таким событиям, а какие нет.

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

Что мы обычно называем «AI‑редактором»

Со стороны пользователя AI‑редактор выглядит как один продукт: пишешь код, рядом чат, сверху автодополнение. На деле это как минимум пять независимых подсистем, и живут они в разных местах.

Поле «свой API‑ключ» влияет ровно на последнюю строку таблицы. Всё остальное идёт через инфраструктуру вендора — и именно она отключается, когда речь про региональные ограничения.

Отсюда первый практический вывод: вопрос «можно ли подставить свой ключ» и вопрос «переживёт ли инструмент отключение вендора» — разные вопросы. Первый про экономику, второй про архитектуру.

Почему индекс проекта — отдельная проблема

Индексация заслуживает отдельного абзаца, потому что о ней вспоминают в последнюю очередь.

Чтобы агент отвечал «где у нас валидируется токен», ему нужен семантический поиск по репозиторию. Это значит, что файлы разбиваются на фрагменты, для каждого считаются эмбеддинги, и всё это где‑то хранится. У облачных редакторов «где‑то» — это их серверы.

Отсюда два следствия. Первое: даже с вашим ключом код всё равно уходит на сторону вендора — просто не в модель, а в индекс. Второе: индекс — ещё одна точка отказа, полностью независимая от того, чей ключ вы вставили.

Классификация инструментов по «облачной привязке»

Если разложить популярные инструменты по тому, сколько у них собственного облака, картина получается такая.

Полный вертикальный стек. Редактор, авторизация, агент, индекс и автодополнение — всё своё, ключ можно подставить только в чат. Максимум удобства и минимум контроля: любое решение вендора вы получаете целиком.

Агент‑расширение поверх чужого редактора — Cline, Roo‑подобные форки, Continue. Расширение живёт в вашем VS Code, состояние — на диске, запросы идут прямо на тот адрес, который вы указали. Промежуточного сервиса нет: некому проверять, из какой вы страны.

Терминальные агенты — Claude Code, Codex CLI, aider. Здесь всё принадлежит вам, кроме самой модели. Плата за это — отсутствие интеграции с редактором и другая эргономика: агент не «дополняет строку», а выполняет задачу целиком.

Редакторы с подключаемым провайдером — например, Zed: свой редактор, но модель добавляется как обычный OpenAI‑совместимый провайдер.

Разница не в качестве, а в том, кто владеет цепочкой. Чем длиннее чужая часть цепочки, тем больше событий вне вашего контроля способны её оборвать — и региональные ограничения тут только один из сценариев. В том же ряду стоят изменение тарифов, закрытие бесплатного плана, смена модели «по умолчанию» и остановка проекта вендором.

Практика: три параметра, которые нужны всегда

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

Cline (расширение VS Code) — в настройках выбирается провайдер OpenAI Compatible, затем заполняются Base URL, API Key, Model ID. Конфигурационного файла у него нет, настройки лежат внутри VS Code.

Continue.dev — ~/.continue/config.yaml:

models:
  - name: Основная модель
    provider: openai
    model: <идентификатор-модели>
    apiBase: https://<адрес-провайдера>/v1
    apiKey: <ключ>
    roles: [chat, edit]

Codex CLI — ~/.codex/config.toml, провайдер описывается блоком, а ключ берётся из переменной окружения, а не из файла:

model_provider = "custom"
model = "<идентификатор-модели>"

[model_providers.custom]
name = "Custom"
base_url = "https://<адрес-провайдера>/v1"
env_key = "CUSTOM_API_KEY"
wire_api = "chat"

Claude Code — две переменные окружения:

export ANTHROPIC_BASE_URL=https://<адрес-провайдера>
export ANTHROPIC_AUTH_TOKEN=<ключ>

Zed — провайдер добавляется в настройках агента либо прямо в settings.json:

{
  "language_models": {
    "openai_compatible": {
      "custom": {
        "api_url": "https://<адрес-провайдера>/v1",
        "available_models": [
          { "name": "<идентификатор>", "display_name": "Модель", "max_tokens": 200000 }
        ]
      }
    }
  }
}

Общее правило, на котором спотыкаются чаще всего: базовый адрес — это именно база, обычно оканчивающаяся на /v1. Дописывать туда /chat/completions не нужно, библиотека добавит путь сама, иначе получится /v1/chat/completions/chat/completions и загадочный 404.

Чего лишаешься при переезде

Честно про минусы, иначе разбор неполный.

Автодополнение уровня Tab. Это отдельная быстрая модель, обученная вендором под свой продукт, и открытого эквивалента такого же качества нет. Автодополнение Continue работает, но ощущается иначе.

Единый UX. В вертикальном стеке чат, агент и индекс знают друг о друге. Собрав то же самое из расширения и терминального агента, вы получите набор инструментов, а не продукт.

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

Здесь же практический совет, экономящий больше всего: включайте кэширование контекста, если провайдер его поддерживает. В агентских сценариях один и тот же проект уезжает в модель десятки раз подряд, и чтение из кэша обычно дешевле обычного ввода на порядок. На реальном профиле нагрузки — агент, 27 тысяч токенов контекста, 76 запросов подряд — доля кэша дошла до 86% входных токенов, а счёт оказался вчетверо ниже, чем был бы без него.

Что из этого следует

Я не считаю, что вертикальные AI‑редакторы — плохая идея. У них лучший UX на рынке, и купили их не зря.

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

И, пожалуй, главный вывод, который я вынесла из этой истории: проверять надо не «есть ли поле для своего ключа», а «что перестанет работать, если вендор завтра скажет нет». Ответ на второй вопрос обычно длиннее, чем ожидаешь.