Вызов модели через startCompletion действительно позволяет изменить её идентификатор в одном поле. Но совместимость приложения определяется не только этой строкой. Новая модель может иначе работать с изображениями, структурой ответа, инструментами и длиной контекста.
В Чатиуме можно сделать управляемый выбор из проверенных маршрутов. Пользователь увидит понятное название, а приложение сохранит точную версию и результат каждого запуска.
Создай AI-редактор с выбором нескольких проверенных моделей. Для каждой показывай подходящие задачи и ограничения. Сохраняй модель, версию инструкции и исходник каждого запуска. Перед сменой основной модели дай сравнить результаты на контрольных примерах.
Идентификатор — часть контракта
Семейство Qwen или Claude включает разные модели. Для API нужен конкретный доступный ID, а не только красивое название в интерфейсе. Суффикс бесплатного маршрута или номер версии также может менять доступность и условия.
На сервере полезно хранить разрешённый список. Это позволяет контролировать совместимость и расходы, а не принимать произвольную строку из браузера. Подпись пользователю и технический идентификатор могут быть разными полями одной настройки.
Четыре проверки перед заменой
| Проверка | Пример возможного различия |
|---|---|
| Вход | Текстовый маршрут не принимает изображение |
| Выход | Нужен текст, изображение или строгая структура |
| Параметры | Не все модели поддерживают одинаковые настройки |
| Поведение | Та же инструкция даёт другую полноту или стиль |
Размер контекста тоже важен, но не означает одинаковую точность на длинных исходниках. Если приложение работает с файлами, проверьте весь путь обработки, включая извлечение данных, а не только таблицу возможностей модели.
Пример безопасного переключателя
Допустим, редактор сокращает описания событий. Оба разрешённых маршрута принимают текст. Сервер выбирает модель только после проверки значения, полученного из формы; в коде ниже эта проверка уже выполнена и сохранена в model.
import { startCompletion } from '@start/sdk'
const { completionId } = await startCompletion(ctx, {
model,
system: 'Сократи описание, сохранив даты, место и условия участия.',
messages: [{ role: 'user', content: [{ type: 'text', text: sourceText }] }],
onCompletionCompleted: done,
onCompletionFailed: failed,
})
ctx даёт Чатиум, sourceText содержит проверенный исходник. done и failed — зарегистрированные обработчики app.function, проверяющие caller.type === 'plugin' && caller.appSlug === 'start'. Метод возвращает ID; ответ приходит позже. Пример показывает место выбора модели, а не весь код проверки списка и хранения.
Как сравнить новую модель с прежней
Сохраните небольшую коллекцию типичных и сложных примеров. Для описания события это могут быть обычный текст, несколько дат, исключение по доступу и неполный исходник. Критерии приёмки должны оставаться одинаковыми.
Не меняйте одновременно модель, инструкцию и подготовку данных, если хотите понять причину разницы. Сначала сравните маршруты на одном задании. Затем отдельно улучшайте промпт под выбранный вариант, сохраняя версии.
Как не сломать историю
Каждый ответ должен хранить фактически использованный ID, даже если настройка основной модели позже изменилась. Иначе старые результаты будут выглядеть так, будто их создала новая модель.
Если маршрут недоступен, не переключайте его незаметно на другой с иными возможностями или расходами. Приложение может иметь согласованное правило замены, но пользовательский результат и журнал должны отражать фактический выбор.
Частые вопросы
Можно ли всегда менять модель без изменения кода?
Для совместимых текстовых задач часто достаточно настройки. Если меняются форматы, инструменты или структура ответа, потребуется проверить и иногда изменить окружающую логику.
Нужно ли показывать пользователю все модели OpenRouter?
Необязательно. Небольшой список проверенных маршрутов проще объяснить и поддерживать. Каталог целиком полезен на этапе исследования.
Как понять, что новая модель лучше?
По принятым результатам на одинаковой выборке, с учётом времени и расходов. Методика есть в оценке моделей, а поведение при недоступности — в запасном маршруте.