Fable orchestrator: скилл, который думает, но не пишет ни строчки кода

Есть соблазн думать, что чем больше моделей участвует в разработке, тем сложнее должна быть архитектура вокруг них. Fable orchestrator — небольшой репозиторий на Shell, который спорит с этим интуитивно. Вместо прокси, дашборда, каталога моделей или хранилища ключей авторы предлагают ровно то, что заявлено в названии: скилл-роутер для Codex, который аккуратно разводит роли между тем, кто решает, и тем, кто делает.

Идея простая до прямолинейности. Claude Fable 5.1 планирует и выносит окончательное суждение — но не пишет код и не владеет рабочим пространством. Codex остаётся рантаймом и делегирует ограниченные по объёму задачи имплементации агентам OpenCode Go. GPT-5.6 Luna берёт на себя обычную реализацию, DeepSeek V4 Flash — циклы, повторяющиеся итерации и задачи с высокой пропускной способностью. При этом сам Fable 5.1 демонстративно вынесен за пределы графа имплементации: он планирует и адъюдицирует, но физически не может оказаться в позиции исполнителя. Это не техническое ограничение ради красоты архитектурной диаграммы, а способ держать роли разделёнными на уровне логики системы, а не договорённости между людьми.

Показательна деталь из README: если ни один из двух разрешённых маршрутов OpenCode Go недоступен, workflow сообщает о блокере, а не изобретает модель на замену. Это редкая для автоматизированных пайплайнов честность — большинство подобных систем в похожей ситуации тихо подставят что-то похожее и продолжат работу, скрыв факт деградации. Здесь предпочли явный отказ явной подмене.

Что физически лежит в репозитории

Устанавливаемый скилл занимает три файла: SKILL.md, agents/openai.yaml и исполняемый scripts/ask_fable.sh. Последний вызывает локальный алиас fable из Claude Code без сохранения сессии — то есть каждый вызов начинается с чистого листа, никакого накопленного контекста между обращениями. Пакет данных, который передаётся в этот скрипт, должен содержать только решения и факты о рабочем пространстве; в README отдельно подчёркнуто, что credentials туда попадать не должны в принципе — не потому что это плохая практика, а потому что установщик и сам скилл спроектированы так, будто credentials для них не существуют.

Установка через install.sh работает в два режима: --dry-run печатает, что именно будет скопировано и куда, ничего не создавая, а --copy реально ставит скилл в ~/.codex/skills/fable, создавая только необходимые директории и оставаясь безопасным для повторного запуска. Флаг --target позволяет выбрать другую директорию скиллов. Установщик читает только сам репозиторий и путь назначения — он не трогает, не создаёт и не читает никакие ключи доступа. Это тот случай, когда ограниченность инструмента — осознанный выбор дизайна, а не недоработка.

Как это работает в жизни

Запрос к скиллу выглядит как обычная команда: $fable build the feature. В ответ Fable возвращает ограниченный граф задач. Codex его валидирует, параллельно запускает готовые к работе узлы, когда это уместно, собирает свидетельства выполнения, проверяет результат и, если задача требует ещё одного решения, снова обращается к Fable за адъюдикацией. Каждый узел имплементации в этом графе обязан использовать либо GPT-5.6 Luna, либо DeepSeek V4 Flash — других вариантов система не предусматривает.

Сам скилл не является самодостаточным продуктом — он потребляет вызываемые агенты opencode-go/ и opencode-go-responses/, которые поставляет Codex Router. Настройка OpenCode Go происходит один раз, в роутере, а после любого изменения провайдера или определений агентов требуется перезапуск Codex — деталь, которая напоминает: это не облачный сервис с горячей перезагрузкой конфигурации, а локальная связка компонентов, которая ожидает явного рестарта при изменении контракта.

Проверка работоспособности тоже устроена без затей — tests/test_skill.sh запускает набор проверок, названных в README «dependency-light»: минимум внешних зависимостей, максимум прозрачности в том, что именно тестируется.

В этой скромности и заключается основной аргумент проекта. За полтора года разговоров об агентных системах индустрия выработала привычку добавлять слои — оркестраторы оркестраторов, дашборды состояния, каталоги моделей с автообновлением. Fable orchestrator идёт в обратную сторону: он фиксирует ровно три роли (планирование, реализация, адъюдикация), жёстко разносит их по разным моделям и демонстративно отказывается делать что-либо ещё. Не хранит ключи, не рисует графики, не выбирает модель за пользователя, если выбор не разрешён конфигурацией. Проект стал заметным — 547 звёзд и сто форков за короткое время — не потому что решает какую-то новую задачу, а потому что честно ограничивает себя одной, и делает это последовательно на каждом уровне: от README до кода установщика.