Технический контекст
Я покопался в этом кейсе не как зритель, а как человек, который постоянно собирает AI integration в рабочих инструментах. Суть простая: в Cursor можно прописать custom URL для OpenAI-совместимого провайдера в Settings → Models, ввести ключ и включить override base URL. На бумаге выглядит почти идеально.
Но дальше начинается реальная жизнь. Если вы хотите протащить GPT-подписку или прокси-транслейтор запросов в Cursor, упираетесь в то, каким API реально стреляет клиент. По отзывам и разбору документации, кастомный путь у Cursor часто ходит через /chat/completions, а новые GPT-сценарии местами уже ждут Responses API.
И вот здесь я бы не обещал магии. Для обычных OpenAI-compatible endpoint это часто заводится быстро. Для свежих GPT-моделей или подписочных схем нужен либо аккуратный прокси, который переводит формат запросов, либо надо мириться с тем, что часть функций будет вести себя криво.
Отдельно понимаю, почему люди вообще это делают. Не ради бенчмарков, а ради UX: Composer 2.5, exploration, работа с UI, быстрые правки по коду в одной оболочке. В таком режиме build AI automation внутри IDE реально приятнее, чем прыгать между CLI и вебом.
По расходу Composer у меня зацепился важный практический сигнал: на новой кодовой базе он ест заметно больше в первые дни, потом подключается что-то вроде умного кеширования. В обсуждении был ориентир: за две недели среднего использования ушло около 60%, причем первые 30% сгорели очень быстро. Не научный тест, но как полевой ориентир цифра полезная.
Что это меняет для бизнеса и автоматизации
Если коротко, выигрывают команды, которым важнее скорость мышления, чем стерильная архитектура. Cursor с хорошей моделью внутри реально ускоряет исследование кода, UI-итерации и мелкую инженерную рутину.
Проигрывают те, кто надеется, что custom endpoint автоматически даст дешевую и бесшовную замену официальной интеграции. Не даст, если протоколы не совпали. Один неверный слой совместимости, и агент уже ведет себя странно, а затраты растут без пользы.
Я бы закладывал тут два решения: либо сразу проектировать прокси под конкретный формат запросов, либо не трогать хрупкую схему там, где команде нужен предсказуемый production UX. Мы в Nahornyi AI Lab как раз такие узкие места и разбираем: где нужна AI implementation ради скорости команды, а где лучше собрать нормальную обвязку, чтобы automation with AI не превратилась в дорогой эксперимент. Если у вас Cursor, внутренние инструменты или кодовый агент уже начинают съедать время и бюджет, давайте посмотрим на ваш сценарий и соберем решение без лишней магии.