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

1. Fable умер. И что теперь

Скажу честно: до Fable этому решению далеко.

На момент написания статьи ИИ-агент для написания кода «Fable» от Anthropic прекратил своё существование. Та точность, та скорость, то ощущение слаженной интеграции — равноценной замены пока не существует.

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

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

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

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

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

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

У этого OpenRouter есть функция под названием «Fusion».

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

Конкретно процесс выглядит так:

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

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

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

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

Ниже — ключевая часть моего текущего 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, а то и выше.

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

Процесс с одним только Fusion выглядит так:

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

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

Об ограничении окна контекста: окно контекста Fusion составляет 128K токенов. На первый взгляд кажется немного, и действительно заполняется быстрее, чем можно было бы ожидать, — ведь помимо истории диалога туда нужно уместить ответы всех пяти моделей. Но паниковать не стоит. Даже если 128K превышены и этап синтеза Fusion завершается неудачей, каждая модель анализа уже успела самостоятельно обработать промпт в рамках собственного, гораздо большего окна контекста (у DeepSeek V4 Pro — миллион токенов, у 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 довольно слаб в самостоятельной генерации кода, зато на удивление хорош в ревью уже существующего кода.

Вариант 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

Одной конфигурации Fusion доверять не вполне спокойно, поэтому в качестве слоя ревью использую один из двух вариантов.

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

GitHub Codex: в момент оформления PR запускаю PR-ревью Codex. То, что оно учитывает контекст всего проекта, придаёт ему иной оттенок по сравнению с универсальным LLM-ревью.

Какой из вариантов использовать — зависит от настроения в конкретный день. Использовать оба сразу было бы явным перебором и слишком медленно.

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

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

{
  "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 плохо подходит для рабочего кода. Годится только для хобби и личной разработки

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

Достаточно иметь аккаунт OpenRouter, чтобы начать пользоваться уже сегодня.

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

• OpenRouter: Fusion plugin
• OpenRouter: Fusion Router
• OpenRouter: OpenCode integration
• opencode: Config
• GitHub Codex: PR review
• Anthropic: Claude Fable 5 and Claude Mythos 5

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

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

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

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

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

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

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

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

Что такое функция Fusion в OpenRouter?

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

Почему используются именно китайские LLM?

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

Почему одного 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, техническом консалтинге и расследовании сбоев, особенно в проектах с унаследованными системами и трудно воспроизводимыми ошибками.