Технічний контекст
Я детально розібрав цей кейс не як сторонній спостерігач, а як людина, яка постійно налаштовує AI integration у робочих інструментах. Суть проста: у Cursor можна прописати custom URL для OpenAI-сумісного провайдера в Settings → Models, ввести ключ і увімкнути override base URL. На папері це виглядає майже ідеально.
Але далі починається реальне життя. Якщо ви хочете підключити GPT-підписку або проксі-транслятор запитів у Cursor, ви впираєтеся в те, яким API насправді користується клієнт. За відгуками та аналізом документації, кастомний шлях у Cursor часто йде через /chat/completions, тоді як нові GPT-сценарії подекуди вже очікують на Responses API.
І тут я не обіцяв би магії. Для звичайних OpenAI-compatible endpoints це часто запускається швидко. Для найновіших моделей 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, внутрішні інструменти або кодовий агент уже починають з'їдати час і бюджет, давайте розберемо ваш сценарій і створимо рішення без зайвої магії.