Fable больше не в подписке, но сдаваться рано ── OpenRouter Fusion＋китайские LLM＋слой ревью

1. Fable умер. Что теперь

Скажу прямо: до Fable этому далеко.

На момент написания статьи флагманская модель Anthropic «Fable» в рамках подписки с фиксированной платой больше недоступна так, как раньше. Та точность, та скорость, то ощущение единой среды. Равноценной замены пока нет.

Что такое Fable — исходные факты

Для тех, кто Fable не знает, кратко зафиксирую исходные факты.

Fable — это флагманская модель Anthropic Claude Fable 5, анонсированная 9 июня 2026 года. По официальному объявлению она стоит так:

Формы поставки описаны в том же анонсе. Через Claude API и в Enterprise-плане с оплатой по факту модель доступна с момента объявления. В подписочных планах она включена без доплаты до 22 июня 2026 года, после этой даты до появления свободной ёмкости нужны usage credits.

То есть модель не исчезла. Реальность в том, что в рамках подписки с фиксированной платой ею больше нельзя пользоваться как раньше. Альтернативную схему в этой статье мы ищем именно при этом условии — «в рамках фиксированной платы». Если бюджет позволяет платить за API по факту использования, быстрее просто взять Fable.

Потеряли не столько саму модель, сколько опыт «отправил в одну модель — и прошло». Схему ниже стоит рассматривать как попытку приблизиться к этому за счёт коллегии нескольких моделей и слоя ревью.

Но и сидеть сложа руки нельзя. Если искать замену, картина такая:

• Claude Code / Claude Sonnet: умный. Но в одиночку до точности Fable не дотягивает, да и счёт растёт
• GPT-5 / GPT-5.5: на удивление слаб. На длинной кодовой базе быстро выдыхается. К тому же дорогой
• Cursor / Windsurf: пользоваться приятно, но всё упирается в модель за кулисами. Произвольно собрать схему нельзя
• Локальные LLM (Ollama и т. п.): скорость есть, но стоит отдать реальный репозиторий — точность резко проседает

Основы работы с ИИ-кодингом — здесь: Полное введение в Claude Code: от установки до практических задач, разбор новых правил ИИ-кодинга

После всех попыток я остановился на схеме: генерировать код через Fusion в OpenRouter＋китайские LLM, а на финише прогонять ревью gpt-5.5-pro или PR-ревью Codex. Fable это ни в каком виде не заменяет, но заметно лучше голого gpt-5.5. Пользоваться можно.

Оговорка: китайские LLM, поэтому скармливать им рабочий код всё-таки страшно. Схема рассчитана на хобби-проекты и личную разработку. Из чего складывается этот риск, разбираю в главе 3, в разделе «Что передавать китайским LLM».

Как читать оценки в этой статье

Сразу оговорюсь. Оценки вроде «слаб», «на уровне или выше», «заметно лучше» в этой статье — личные ощущения автора от своей работы. Это не баллы стандартных бенчмарков и не сравнительный эксперимент с выровненными условиями. Если оценка не оговорена отдельно, считайте её ощущением.

Объективно проверить можно разве что цены, да и те меняются. Актуальные ставки моделей смотрите в каталоге моделей OpenRouter. Если думаете внедрять, цены обязательно сверьте сами.

Иначе говоря, если достаточно личных ощущений, схему можно пробовать уже сегодня. Дальше читайте статью именно так.

На схеме сплошная линия обозначает отношение, которое выполняется всегда, а пунктирная — условное отношение (условия указаны в пояснении к каждому отношению на странице сведений). Полный список отношений (всего 18, с доказательствами и степенью уверенности) и определения основных понятий собраны на странице сведений карты знаний (на японском). Данные: JSON-LD / Turtle

2. Что такое OpenRouter Fusion

OpenRouter — API-шлюз, через который к нескольким провайдерам LLM ходят единообразно. Claude, GPT, Gemini, DeepSeek — всё через один интерфейс.

У этого OpenRouter есть функция «Fusion».

Проще говоря, это механизм, в котором один промпт уходит нескольким моделям, ответы разбираются, и итоговый вывод собирает одна модель. По сути — коллегия моделей.

Конкретно поток такой:

1. Пользователь вводит промпт
2. Модели из analysis_models одновременно отвечают на один и тот же промпт
3. Модель из model сравнивает и разбирает эти ответы, структурирует согласия, противоречия, пробелы и слепые зоны (роль judge)
4. Затем та же модель по этому разбору пишет итоговый ответ

Важно: задать каждой модели анализа отдельную роль или свой промпт нельзя. Все получают один промпт, отвечают независимо, а judge оценивает различия — вот и весь несложный механизм.

CLI-агент для написания кода opencode поддерживает Fusion нативно, как плагин. Достаточно прописать настройки в opencode.json, и получается агент, в котором несколько моделей вместе генерируют и ревьюят код.

3. Реальная конфигурация

Установка: ставим opencode и подключаем OpenRouter

Прежде чем разбирать содержимое конфига, кратко путь до него.

1. Ставим opencode

curl -fsSL https://opencode.ai/install | bash

Можно и через пакетный менеджер. На Windows в официальной документации рекомендуют WSL.

npm install -g opencode-ai            # Node.js
brew install anomalyco/tap/opencode   # macOS / Linux
scoop install opencode                # Windows

2. Регистрируем API-ключ OpenRouter

В панели OpenRouter через Create API Key создаём ключ. Затем в нужном каталоге запускаем opencode, выполняем /connect, в списке провайдеров выбираем OpenRouter и вставляем ключ.

cd /path/to/project
opencode

/connect

Ключ сохраняется в ~/.local/share/opencode/auth.json. В конфиг его писать не нужно — и не пишите.

3. Кладём opencode.json

Конфиг обычно лежит в одном из двух мест.

Если есть оба, они сливаются; при конфликте ключей побеждает проектный файл. Конфиг Fusion ниже работает в любом из двух мест. Я пользуюсь им постоянно, поэтому держу глобальный. В начало файла стоит добавить "$schema": "https://opencode.ai/config.json" — тогда в редакторе работают автодополнение и проверка.

4. Инициализируем проект

/init

opencode разбирает проект и создаёт AGENTS.md. Этот файл рекомендуется коммитить в Git. Тогда вывод учитывает структуру проекта и его стиль кода.

Конфигурация Fusion

Ниже — ключевая часть моего текущего opencode.json.

{
  "model": "openrouter/openrouter/fusion",
  "provider": {
    "openrouter": {
      "models": {
        "openrouter/fusion": {
          "name": "OpenRouter Fusion (Custom DeepSeek V4 Pro)",
          "options": {
            "plugins": [
              {
                "id": "fusion",
                "analysis_models": [
                  "xiaomi/mimo-v2.5-pro",
                  "z-ai/glm-5.1",
                  "deepseek/deepseek-v4-pro",
                  "moonshotai/kimi-k2.7-code",
                  "minimax/minimax-m3"
                ],
                "model": "deepseek/deepseek-v4-pro",
                "max_tool_calls": 8
              }
            ]
          }
        }
      }
    }
  }
}

Схема из пяти моделей анализа и одной исполняющей модели.

Модели анализа (все видят один промпт и отвечают одновременно)

Исполняющая модель (пишет итоговый ответ по результатам анализа)

• deepseek/deepseek-v4-pro: по ответам моделей анализа отвечает за фактическую генерацию кода и правку файлов.

Почему китайские LLM

Просто потому, что соотношение цена/качество на голову выше.

По состоянию на 2026 год API китайских LLM стоит 1/5–1/20 от Anthropic или OpenAI при сопоставимом или более высоком качестве. Особенно качество кода у DeepSeek V4 Pro на практике нередко ощущается на уровне Claude Sonnet и GPT-5.5, а то и выше.

И «1/5–1/20», и «на уровне или выше» — как я оговорил в главе 1, ощущения на том, чем я пользовался. Цены зависят от модели и провайдера и постоянно меняются, поэтому сначала сверьте фактические ставки в каталоге моделей OpenRouter. Качество тоже не подтверждено опубликованными бенчмарками.

Что передавать китайским LLM — критерии для рабочей задачи

В главе 1 я написал, что «скармливать рабочий код страшно». Бояться в общем — ещё не решение, поэтому разложу, что именно может произойти.

Оговорка: принудительный ZDR действует только на маршрутизацию запросов инференса. Плагины и инструменты вроде веб-поиска крутят сторонние сервисы и живут по своим политикам хранения. Политики включаемых инструментов проверяйте отдельно.

Дальше «можно ли это в работе» удобнее думать в таком порядке.

1. Разделить, что передаёте. Код, спецификации и данные заказчика, которые закрыты NDA или договором подряда, не отправлять. Отправлять только то, на что у вас есть права, или то, что уже опубликовано. Если эту границу провести нельзя, дальше смотреть незачем.
2. Проверить договор. В заказной разработке часто есть пункты о субподряде и о выносе информации вовне. Попадает ли отправка во внешний LLM-сервис под эти пункты — вопрос не для самостоятельной интерпретации, его нужно согласовать с заказчиком. Если в данных есть персональная информация, это может квалифицироваться как «передача третьему лицу за границей» по японскому Закону о защите персональных данных, поэтому нужна проверка по руководству Комиссии по защите персональных данных (передача третьему лицу за границей).
3. Закрыть настройками. Когда шаги 1 и 2 пройдены, настройками закрывают обучение, хранение логов и трансграничную передачу из таблицы выше.
4. Оставить запись. Зафиксировать, какие модели и что именно вы им отдаёте. Потом, когда попросят объяснить, это сработает.

Схема этой статьи на шаге 1 сознательно ограничена хобби-проектами и личной разработкой. Если хотите в работу — сначала пройдите как минимум шаги 2 и 3.

4. Как это работает — почему одного Fusion мало

Поток одного только Fusion такой:

1. Пользователь вводит промпт
2. Пять моделей анализа генерируют ответы каждая независимо
3. Исполняющая модель (DeepSeek V4 Pro) сравнивает и разбирает эти ответы и собирает структурированный анализ: согласия, противоречия, пробелы
4. По этому анализу та же исполняющая модель (DeepSeek V4 Pro) пишет итоговый код

Это ближе к работе живой команды. Пятеро инженеров смотрят одну спецификацию и каждый даёт комментарии в ревью, затем один человек (DeepSeek V4 Pro) разбирает и упорядочивает их и реализует — примерно такая картина.

Про ограничение окна контекста. Окно контекста Fusion — 128K токенов. На первый взгляд мало, и оно заполняется быстрее, чем кажется: помимо истории диалога туда нужно уместить ответы всех пяти моделей. Паниковать не стоит. Даже если 128K превышены и этап синтеза Fusion падает, каждая модель анализа уже обработала промпт сама в своём, гораздо большем окне (у DeepSeek V4 Pro — 1 млн токенов, у Kimi K2.7 — около 260 тысяч и т. д.). Сам opencode тоже хранит историю всей сессии, так что «память» моделей не пропадает. На практике, по ощущениям, серьёзной помехи это не создаёт.

Но одного этого до Fable всё равно далеко. Fable — одна модель, и при этом по точности с запасом обходила коллегию нескольких моделей. Так проявляется запас Anthropic.

Поэтому к выходу Fusion добавляем ещё один слой ревью. Вариантов два.

Вариант A: ревью кода gpt-5.5-pro

1. Сгенерировать код в конфигурации Fusion
2. Отдать сгенерированный код gpt-5.5-pro с указанием «проревьюй и предложи правки»
3. Эти правки применить через исходную исполняющую модель

На практике gpt-5.5-pro назначают субагентом через функцию task в opencode и дают указание «проревьюй и предложи правки».

gpt-5.5-pro сам по себе код пишет слабо, зато ревью уже существующего кода — поиск слабых мест в чужой работе — у него неожиданно получается.

Вариант B: PR-ревью GitHub Codex

1. Сгенерировать код в конфигурации Fusion
2. Оформить PR и прогнать через PR-ревью GitHub Codex
3. Codex указывает на возможные баги и сомнения в дизайне — эти замечания вносят в код

Codex ревьюит с учётом контекста GitHub (issue, прошлые PR, структура проекта), поэтому копает с другой стороны, чем универсальное LLM-ревью.

Достаточно одного из двух. Выбирать можно по настроению, а гонять оба — явный перебор и слишком медленно. Fusion (коллегия из пяти моделей) → ревью (gpt-5.5-pro или Codex) — двухступенчатая схема. Идея такая: раз до Fable за один проход далеко, разницу закрываем процессом.

Ошибки версий библиотек и вызовы несуществующих API, на которых спотыкается голый gpt-5.5, с этой схемой заметно сократились.

5. Скорость и практичность

Сама скорость почти как у одной модели. Пять моделей работают параллельно, поэтому чистое время отклика остаётся приемлемым.

Проблема — точность. Там, где Fable проходил с первого раза, эта схема даёт несколько возвратов на доработку. В итоге общее время разработки заметно больше, чем с Fable. Ошибки как раз и замедляют.

Тем не менее это заметно лучше голого gpt-5.5. Код по схеме Fusion＋ревью уже с первой попытки довольно близок к правильному — точно быстрее, чем застрять с одним gpt-5.5 в бесконечном цикле генерация → правка → правка → правка.

По ощущениям так: «скорость нормальная. До точности Fable далеко, но на несколько ступеней лучше голого gpt-5.5».

6. Бонус: прочие настройки opencode

Про слой ревью (gpt-5.5-pro или PR-ревью Codex) я уже написал в главе 4. Здесь — всё остальное.

Прочие настройки

В opencode.json помимо Fusion у меня стоят ещё несколько практических настроек.

{
  "permission": {
    "read": "allow",
    "glob": "allow",
    "grep": "allow",
    "task": "allow",
    "webfetch": "allow",
    "websearch": "allow",
    "lsp": "allow",
    "edit": "allow",
    "bash": {
      "*": "allow",
      "Remove-Item *": "deny",
      "del *": "deny",
      "rm *": "deny",
      "rmdir *": "deny",
      "rd *": "deny",
      "erase *": "deny",
      "git clean *": "deny"
    }
  },
  "experimental": {
    "primary_tools": ["task"]
  }
}

Два важных момента.

1. Блокировка команд удаления

Remove-Item, del, rm, rmdir, rd, erase и git clean явно запрещены. Доверять ИИ-агенту удаление файлов страшно. Если удалить всё же нужно, делаю это сам.

2. primary_tools: ["task"]

Приоритет у параллельного обхода через субагентов (task). Когда в большой кодовой базе нужно одновременно читать или искать по нескольким файлам, путь через task заметно быстрее.

7. Итог

То, что Fable пропал из фиксированной подписки, бьёт сильно. По-настоящему сильно. Лучше него пока ничего нет.

Но сидеть сложа руки нельзя, поэтому я держусь на схеме: генерация через OpenRouter Fusion＋китайские LLM, финиш — ревью gpt-5.5-pro или PR-ревью Codex.

Суть схемы:

• Генерация кода коллегией из пяти моделей через OpenRouter Fusion
• Модели анализа: Xiaomi Mimo / GLM / DeepSeek / Kimi / MiniMax
• Исполняющая модель: DeepSeek V4 Pro
• Финишный слой ревью: gpt-5.5-pro или PR-ревью Codex (достаточно одного)
• Скорость как у одной модели. Но из-за более низкой, чем у Fable, точности переделки замедляют работу
• Заметно лучше голого gpt-5.5. До Fable далеко, но для практики хватает
• Китайские LLM, поэтому для рабочего кода схема неудобна. Хобби и личная разработка (порядок решения — таблица в главе 3)
• Все оценки выше — личные ощущения автора. Цены смотрите в каталоге моделей OpenRouter

Если среди ИИ-агентов для написания кода вам тяжело без Fable или голый gpt-5.5 кажется слишком слабым, как временное решение схему стоит попробовать.

Заведите аккаунт OpenRouter, поставьте opencode по шагам из главы 3 — и можно пробовать уже сегодня.

Справочные ссылки

• OpenRouter: Fusion plugin
• OpenRouter: Fusion Router
• OpenRouter: OpenCode integration
• OpenRouter: Provider Logging ── политики обучения и хранения данных по провайдерам и настройки фильтрации
• OpenRouter: Zero Data Retention ── маршрутизация только на эндпоинты ZDR и границы её действия
• OpenRouter: Models ── актуальные ставки моделей
• opencode: Intro ── установка и шаги до /init
• opencode: Providers ── подключение OpenRouter и где хранятся учётные данные
• opencode: Config ── где лежит конфиг и в каком порядке он сливается
• GitHub Codex: PR review
• Anthropic: Claude Fable 5 and Claude Mythos 5 ── первичная информация о позиционировании, тарифах и формах поставки Fable
• Комиссия по защите персональных данных Японии: руководство (передача третьему лицу за границей) ── как трактовать трансграничную передачу, если в данных есть персональная информация
• NoCode Solutions: Полное введение в Claude Code: от установки до практических задач, разбор новых правил ИИ-кодинга ── основы работы с ИИ-кодингом

Похожие статьи

Недавние статьи с теми же тегами помогут подробнее изучить близкие темы.

Связанные темы

Эти страницы показывают тему статьи в более широком контексте услуг и решений.

Услуги по этой теме

Статья напрямую связана со следующими услугами.

Частые вопросы

Вопросы, которые часто возникают при консультациях по теме статьи.

Что такое Fusion в OpenRouter?

Это механизм, в котором один и тот же промпт одновременно уходит нескольким моделям, одна модель в роли judge сравнивает и разбирает ответы — фиксирует согласия, противоречия и пробелы — и затем та же модель по этому разбору пишет итоговый ответ. По сути это коллегия моделей. Задать каждой модели анализа отдельную роль или свой промпт нельзя: все получают один и тот же промпт. CLI-агент для написания кода opencode поддерживает Fusion нативно, как плагин: достаточно прописать настройки в opencode.json.

Почему именно китайские LLM?

Из-за соотношения цена/качество. По состоянию на 2026 год API китайских LLM стоит примерно 1/5–1/20 от Anthropic или OpenAI при сопоставимом или более высоком качестве. Особенно качество кода у DeepSeek V4 Pro на практике нередко ощущается на уровне Claude Sonnet и GPT-5.5, а то и выше. Передавать этим моделям рабочий код рискованно, поэтому схема рассчитана на хобби-проекты и личную разработку.

Почему одного Fusion недостаточно?

Даже коллегия из пяти моделей не дотягивает до точности Fable. Поэтому к выходу Fusion добавляют ещё один слой ревью. Два варианта: отдать сгенерированный код на ревью gpt-5.5-pro и применить правки либо оформить PR и прогнать его через PR-ревью GitHub Codex — достаточно одного из двух. gpt-5.5-pro слабо генерирует код сам, зато хорошо ревьюит уже написанное; Codex указывает на проблемы с учётом контекста всего проекта.

Насколько эта схема пригодна на практике?

Пять моделей работают параллельно, поэтому скорость почти как у одной модели. Точность же до Fable не дотягивает, из-за переделок общее время разработки заметно растёт. Всё равно это быстрее, чем застрять с голым gpt-5.5 в бесконечном цикле генерации и правок; ошибки версий библиотек и вызовы несуществующих API тоже заметно сократились. Достаточно аккаунта OpenRouter, чтобы попробовать сразу.

Об авторе

Страница с профилем автора статьи.

Го Комура

Представитель KomuraSoft LLC

Специализируется на разработке программного обеспечения для Windows, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.