16 июля GigaChat объявил единый адрес API, а с 17 июля новые подключения должны использовать api.giga.chat. Для тех, кто ищет «гига чат официальный сайт» и уже встраивает сервис в продукт, важнее другое: прежний gigachat.devices.sberbank.ru/ пока продолжает работать для ранее подключённых клиентов, но для новых интеграций он больше не предназначен.
Это не авария и не повод сегодня менять URL во всех приложениях. Но это момент, когда привычная строка в исходном коде становится техническим долгом с неизвестным сроком погашения. Дата окончательного отключения старого адреса не объявлена. Именно поэтому миграцию разумно начать до неё, а не в день, когда legacy-адрес перестанет отвечать.
Подключите модели для разработки с оплатой в рублях на provod.ai
Что действительно изменилось
Новый target URL один и для физических, и для юридических лиц: api.giga.chat. Объявление датировано 16 июля, а формулировка о подключении с нового адреса действует с 17 июля.
Старый адрес не объявлен отключённым. Документация прямо оставляет его для уже подключённых клиентов, одновременно помечая как неподходящий для новых подключений и будущий объект вывода из эксплуатации.
Практическое следствие простое:
- новая интеграция должна начинаться с
api.giga.chat; - работающая старая интеграция не обязана переключаться немедленно;
- каждая жёстко зашитая ссылка на прежний адрес увеличивает будущую стоимость изменения.
Почему «он же ещё работает» не является стратегией
Сильное возражение звучит разумно: если endpoint доступен, а дата sunset не названа, переключение создаёт риск без немедленной пользы. Для критичного сервиса действительно не стоит устраивать массовую замену только ради соответствия новой рекомендации.
Но это не аргумент за бездействие. Это аргумент за контролируемую подготовку.
Когда base URL живёт в коде, его приходится искать по репозиториям, образам, переменным CI/CD и настройкам отдельных окружений. Когда URL вынесен в конфигурацию, команда может проверить новый маршрут на ограниченном трафике, сохранить быстрый rollback и не превращать будущую миграцию в ночную операцию.
У старого endpoint сейчас есть важное свойство: он даёт время. Не гарантию, а окно для спокойной проверки.
Canary вместо большой замены
Начните не с переключателя в production, а с инвентаризации. Найдите все места, где задаётся базовый адрес: конфиги приложений, секреты, Helm values, переменные окружения, шаблоны деплоя и тестовые стенды. Цель не в том, чтобы срочно всё поменять, а в том, чтобы добиться одного управляемого параметра.
Затем поднимите canary с api.giga.chat и проверьте конкретно вашу интеграцию:
- Получается ли токен так же, как ожидает клиент.
- Подходит ли scope для нужного сценария.
- Проходит ли TLS-проверка цепочки сертификатов в вашем окружении.
- Совпадают ли настроенные таймауты и обработка ошибок с фактическим поведением.
- Сопоставимы ли ответы для ваших запросов и парсеров.
- Можно ли быстро вернуть прежний base URL без новой сборки приложения.
Это инженерный маршрут, а не обещание, что авторизация, scope или сетевое поведение окажутся идентичными для любой системы. Именно canary превращает неизвестность в проверяемый список.
Диагностика: мигрировать сейчас или поставить в очередь
Мигрировать в ближайший технический цикл, если старый адрес зашит в исходниках, одна конфигурация обслуживает несколько приложений или у команды нет понятного способа отката. Здесь основная польза не в смене домена, а в устранении зависимости, которой трудно управлять.
Провести только canary, если сервис критичен, а текущая интеграция стабильна. Это позволяет получить собственные результаты по токенам, TLS, таймаутам и ответам, не рискуя всем трафиком.
Не добавлять новый legacy-адрес нигде, если интеграция ещё не началась. Для неё решение уже принято документацией: используйте api.giga.chat.
Отсутствие заметной свежей дискуссии на Reddit, Hacker News и GitHub не делает изменение менее важным. Оно лишь означает, что ориентироваться стоит на официальное правило подключения и на поведение собственной системы, а не на шум сообщества.
Для таких переходов полезен подход, при котором provider endpoints живут в конфигурации, проходят health-check и переключаются через canary, не требуя переписывать клиентское приложение. Этот принцип можно применить и при проектировании интеграционных потоков в provod.ai.
Что для вашей команды дороже: оставить стабильный legacy-адрес до объявления sunset или заранее потратить цикл на canary и конфигурационный rollback?
provod.ai — подключение AI без переписывания продукта
Сохраняйте привычный стек: приложение, AI-клиент, агент, IDE, SDK или библиотека продолжают работать в знакомом формате. Если инструмент поддерживает OpenAI-совместимый API, обычно меняются только URL и ключ.
В одном каталоге — актуальные модели для текста и медиа: GPT от OpenAI, Claude от Anthropic, Gemini от Google, Grok от xAI, DeepSeek, Qwen, GLM, Kimi и MiniMax; для изображений — Nano Banana 2 Pro и GPT Image; для видео — последние версии Seedance, Kling, Veo и Google Omni. Также доступны модели для reasoning, поиска, документов, эмбеддингов, музыки и аудио.
Стоимость моделей совпадает с официальными тарифами поставщиков 1:1: агрегатор не добавляет свою наценку, а российская команда платит в рублях через единый баланс.
Подключите существующий AI-стек к provod.ai: инструкция по миграции · форма регистрации · цены на модели · защита данных по 152-ФЗ