Что переносится при смене поставщика API: ключи, баланс и история чатов
Разделите средства аккаунта, историю клиента и серверные ресурсы. Сохраните читаемый экспорт и восстанавливаемую копию, проверьте файлы и базу знаний, затем выполните приёмку, переключение и отзыв старых ключей.
При смене поставщика API обычно можно перенести доступные вам материалы и настройки. Баланс аккаунта, серверные ресурсы и права доступа автоматически за ними не следуют. Даже похожий формат интерфейсов не означает, что миграция завершена после замены адреса. Сначала выясните, где находятся данные, затем сохраните восстанавливаемую копию и только после этого переключайте запросы.
Руководство предназначено для пользователей настольных клиентов и собственных приложений. Это порядок миграции и приёмки, а не отчёт об испытании конкретного поставщика. Перевод средств, возврат денег и полная совместимость не гарантируются. Документация проверена 18 октября 2026 года; при выполнении действий учитывайте установленную версию клиента.
1. Составьте список: что копировать, а что создавать заново
За словом «аккаунт» могут скрываться вход в клиент, учётная запись поставщика API и ресурсы платформы моделей. Одинаковый адрес электронной почты не делает их одной системой данных.
| Объект | Что сохранить | Что делать при переходе |
|---|---|---|
| API Key | Название ключа, права и список приложений; само значение хранить защищённо | Создать новые учётные данные у нового поставщика; не проверять новый адрес старым ключом |
| Баланс, бонусы, платежи | Отдельно оплаченные и подарочные средства, сроки, заказы и правила возврата | Урегулировать в прежнем аккаунте; обсуждать перенос только при явной поддержке обеих сторон |
| Промпты и настройки помощников | Системные инструкции, параметры, определения инструментов, выбор модели | После копирования проверить каждое поле: новый интерфейс может его не поддерживать |
| История и вложения | Исходную резервную копию, читаемый экспорт и оригиналы файлов | Отдельно проверить формат импорта, ветви диалога и связи с вложениями |
| Серверные файлы и сеансы | Исходные файлы, назначение ресурсов, старые ID и владельца | Не считать ID переносимыми между поставщиками; создать ресурсы заново и сохранить соответствия |
| База знаний | Оригиналы, настройки разбиения, модель эмбеддингов, контрольные результаты поиска | Проверить возможность повторного использования индекса; при смене модели выполнить требуемое продуктом перестроение |
Расчёты по балансу и техническое переключение — независимые процессы. Не передавайте третьим лицам полный ключ, резервную копию клиента или код входа ради «переноса баланса». Если исходная платформа не предоставляет экспорт, отметьте это как пробел, а не рассчитывайте, что новый поставщик восстановит данные.
2. Сохраните и читаемый экспорт, и полную резервную копию
Читаемый экспорт нужен для просмотра, резервная копия в родном формате — для восстановления. Markdown или PDF сохраняют текст, но не обязательно позволяют импортировать полноценный диалог с ролями сообщений, ветвями, результатами инструментов и связями с файлами. Непрозрачный архив, в свою очередь, не заменяет доступную для чтения копию важных материалов.
Например, согласно текущей официальной странице Cherry Studio «Настройки данных», полная копия по умолчанию содержит диалоги, помощников, базы знаний, вложения, пользовательские настройки и конфигурацию Provider, включая API-ключи. Облегчённая копия пропускает изображения, файлы баз знаний и другие файлы данных, сохраняя историю чатов и настройки. Это описание конкретного продукта, а не правило для всех клиентов.
Подготовьте данные в следующем порядке:
- Запишите название и версию клиента, время и тип копии. Приостановите задачи, которые продолжают записывать данные.
- Создайте полную копию средствами клиента, а важные промпты и диалоги отдельно сохраните в читаемом виде. Оставьте оригиналы вложений, а не только миниатюры или временные ссылки.
- Храните исходную копию в защищённом месте и не отправляйте её поддержке нового поставщика. Для обращения подготовьте отдельный материал только с необходимыми обезличенными полями.
- Восстановите копию в отдельной тестовой учётной записи ОС или изолированном каталоге данных. Заранее отключите синхронизацию, автоматические задачи и внешние инструменты, чтобы восстановленные старые ключи сразу не запустили запросы. Если клиент не позволяет безопасную изоляцию, сначала изучите официальный порядок восстановления; не перезаписывайте единственный рабочий экземпляр.
- Выборочно проверьте ранний диалог, диалог с ветвями и вложение: содержание, порядок сообщений, открытие файла и его связь с диалогом. Для неиспользуемых возможностей поставьте отметку «не применимо».
Удаление старого ключа из клиента не удаляет его из ранее созданного архива. Защищайте такой архив как секрет. Отзыв ключа прекращает возможность его использования для авторизации, но не стирает содержащиеся в копии разговоры.
3. Добавьте новую конфигурацию, не перезаписывая старую
Сохраните прежние настройки как временный ориентир для отката и дайте новой конфигурации отдельное имя. Проверяйте тип протокола, Base URL, API Key и ID модели вместе. Нельзя заменить только URL и продолжить отправлять прежние учётные данные.
Так, документация OpenRouter требует создать API-ключ на его платформе и передавать его как Bearer token. Одинаковый способ записи заголовка не означает переносимость ключей. Если у конкретного шлюза существует отдельный механизм переноса учётных данных, его границы нужно подтвердить по доверенной документации, а не вывести из сходства интерфейсов.
Помимо модели текущего чата, проверьте помощника по умолчанию, генерацию заголовков, перевод, изображения, эмбеддинги, переранжирование и фоновые задания. Переключение одного окна не мешает другим функциям продолжать расходовать средства старого аккаунта.
Составьте таблицу соответствий: прежняя конфигурация → новая конфигурация → место использования → проверенные функции → ответственный. Указывайте псевдонимы ключей, а не полные значения. Сначала направьте через новую конфигурацию одну задачу с низким риском. Подтвердите целевой хост запроса, результат и запись о расходе, затем переключайте остальные места использования. Перед передачей сетевого журнала удалите заголовки авторизации и чувствительное содержимое.
4. Видимая история ещё не означает, что новая модель её получила
Если старый диалог отображается после миграции, это подтверждает лишь способность клиента показать сохранённую историю. Сколько сообщений, системных инструкций, вложений и результатов инструментов попадёт в следующий запрос, зависит от сборки контекста клиентом. Новый поставщик не получает историю прежней платформы автоматически из-за одинакового адреса электронной почты.
В изолированной копии создайте нечувствительный тестовый диалог, например: «Код проекта — Голубая ель; результат — список из трёх проверок». Затем через новую конфигурацию попросите назвать код и результат. Если клиент позволяет просмотреть отправленный запрос, проверьте, действительно ли в него вошла нужная история. Один верный ответ не доказывает полноту миграции: дополнительно проверьте роли, порядок и обрезку контекста. Не пересылайте новому поставщику весь личный архив ради поиска ошибки.
Вложения и серверные ресурсы проверяйте отдельно:
- Файл открывается в клиенте, но запрос сообщает об отсутствующем ресурсе: проверьте ссылку на ID прежнего поставщика и срок действия временного URL. Сохранив оригинал, загрузите его по правилам нового интерфейса.
- Текстовый чат работает, а поиск по базе знаний — нет: проверьте исходный текст, разбиение и переключение сервиса эмбеддингов. Проверки только чат-модели недостаточно.
- Поиск ухудшился после замены модели эмбеддингов: векторные пространства разных моделей нельзя считать одинаковыми; совпадение размерности не доказывает совместимость. Документация Cherry Studio предусматривает перестроение базы с уже существующими векторами при смене модели эмбеддингов. Сначала подтвердите доступность новой модели, затем перестройте базу и повторите поиск по фиксированным вопросам.
Даже если меняется только поставщик, который заявляет ту же модель эмбеддингов, подтвердите точную версию, размерность и обработку входных данных. Одинакового отображаемого названия недостаточно, чтобы считать старый индекс пригодным.
5. Решайте о переключении и откате по результатам приёмки
Ниже предложены проверки для выполнения пользователем. Они не означают, что автор уже испытал эти сценарии у какого-либо поставщика. Начинайте с нечувствительных примеров и ограниченного бюджета; платные проверки выполняйте в своей разрешённой среде.
| Проверка | Условие прохождения | Первый шаг при неудаче |
|---|---|---|
| Восстановление копии | Выборочные диалоги, ветви и вложения восстановлены либо ограничения зафиксированы | Сохранить исходную копию и собрать недостающие данные |
| Новая авторизация | Запрос идёт на новый хост с новыми учётными данными | Проверить привязку конфигурации, не отправлять старый ключ новому сайту |
| Продолжение диалога | Необходимая история входит в запрос с правильными ролями и порядком | Проверить обрезку контекста и формат импорта |
| Файлы и база знаний | Файлы доступны, контрольные вопросы находят правильные исходные фрагменты | Проверить соответствия ID, разбор документов и индекс |
| Рабочий процесс | Нужный формат, потоковая выдача или инструменты проходят проверку задачи | Не переносить непроверенные задачи; уточнить поддержку конкретной функции |
| Расходы и старый трафик | Новые запросы сопоставимы с учётом расходов; нет неожиданных старых вызовов | Проверить модели по умолчанию, очереди, фоновые задания и повторы |
Назначьте явный момент переключения и зафиксируйте задачи в работе, завершённые задачи и задачи с неизвестным результатом. Сначала прекратите приём новых заданий старым маршрутом, затем дождитесь завершения запросов в работе или выясните их результат. Это снижает риск повторного выполнения одного внешнего действия через новую платформу.
Откат тоже не сводится к возврату URL. Сохраните новые диалоги, загруженные файлы и результаты, появившиеся после переключения; старая резервная копия не должна их затереть. Уже выполненную отправку письма, запись или оплату смена модели не отменяет. При неизвестном статусе сначала вручную проверьте журнал выполнения, затем решайте о повторе. Организацию проверки самих задач см. в статье Как проверять AI-модель на своих задачах.
6. После миграции закройте прежние точки доступа
Отзывайте ненужные старые ключи после проверки важных задач и периода наблюдения, соответствующего циклу ваших автоматических заданий. При подозрении на утечку отзывайте ключ немедленно, не оставляя опасные учётные данные ради отката. Основы хранения описаны в руководстве по безопасности API Key.
Напоследок проверьте настройки клиента по умолчанию, переменные окружения серверов, автоматизацию и конфигурации участников команды. Если старая платформа предоставляет такую возможность, отключите ненужное автопополнение или продление и сохраните расчётные документы. Право на возврат, сроки зачисления и объём удаления данных определяются отдельно условиями прежней платформы и фактическим результатом обращения. Удаление локальной конфигурации не закрывает удалённый аккаунт и не удаляет его журналы.
Миграция завершена, когда важные материалы имеют восстанавливаемую копию, новый рабочий процесс прошёл приёмку, старые запросы остановлены, а по оставшемуся балансу и хранимым данным есть план дальнейших действий. Ответ в одном окне чата подтверждает только один из этих шагов.
Источники, проверенные 18 октября 2026 года: Cherry Studio: настройки данных, Cherry Studio: модели и настройки поиска, OpenRouter: авторизация. При подготовке статьи платные API-запросы и реальная миграция пользовательских данных не выполнялись.