KomuraSoft LLC
Contáctenos
Menú

Fable ha dejado de estar disponible, pero no toca rendirse ── Aguantar con OpenRouter Fusion＋LLM chinos＋una capa de revisión

· · AI, LLM, OpenRouter, Claude, ChatGPT, DeepSeek, Ingeniería de prompts, Eficiencia de desarrollo, Presentación de herramientas

1. Fable ha muerto. Y ahora, ¿qué?

Seré honesto: esto ni de lejos se acerca a Fable.

En el momento de escribir este artículo, el agente de programación con IA “Fable” que ofrecía Anthropic ha dejado de prestar servicio. Aquella precisión, aquella velocidad, aquella sensación de integración perfecta… por ahora no existe nada equivalente que lo sustituya.

Aun así, no se puede uno quedar de brazos cruzados. Buscando alternativas, el panorama es este:

  • Claude Code / Claude Sonnet: inteligente, pero solo no alcanza la precisión de Fable, y el coste se dispara
  • GPT-5 / GPT-5.5: sorprendentemente flojo. Se queda sin fuelle enseguida al trabajar con bases de código largas. Y encima es caro
  • Cursor / Windsurf: buena experiencia de uso, pero depende del modelo que use por detrás. No permite una configuración libre
  • LLM locales (Ollama, etc.): rápidos, pero la precisión cae en picado en cuanto se les pasa un repositorio real

Después de probar de todo, esto es a lo que he llegado: generar código con la función Fusion de OpenRouter＋LLM chinos, y rematarlo con una revisión de gpt-5.5-pro o una revisión de PR de Codex. No compite en absoluto con Fable, pero resulta bastante más utilizable que el gpt-5.5 a secas. Cumple, dentro de lo razonable.

Eso sí, al tratarse de LLM chinos, entregarles código de trabajo sigue dando bastante respeto. Este planteamiento está pensado exclusivamente para proyectos personales o de afición.

2. ¿Qué es OpenRouter Fusion?

OpenRouter es una puerta de enlace API que permite acceder de forma unificada a varios proveedores de LLM. Claude, GPT, Gemini, DeepSeek: todos se pueden usar con la misma interfaz.

Ese OpenRouter cuenta con una función llamada “Fusion”.

Dicho de forma sencilla, es un mecanismo que envía un mismo prompt a varios modelos, analiza sus respuestas y hace que un único modelo elabore la salida final. Podría describirse como una “deliberación colegiada entre modelos”.

En concreto, el flujo es el siguiente:

  1. El usuario introduce un prompt
  2. Los modelos indicados en analysis_models responden simultáneamente al mismo prompt
  3. El modelo indicado en model compara y analiza esas respuestas, estructurando puntos de acuerdo, contradicciones, carencias y puntos ciegos (= el papel de juez)
  4. A continuación, ese mismo modelo redacta la respuesta final basándose en dicho análisis

Un detalle importante: no es posible asignar roles o prompts distintos a cada modelo de análisis. Todos reciben el mismo prompt, responden de forma independiente, y el juez evalúa las diferencias; un mecanismo así de sencillo.

El agente de programación por línea de comandos opencode admite Fusion de forma nativa como plugin. Basta con escribir la configuración en opencode.json para conseguir un agente en el que varios modelos colaboran para generar y revisar código.

3. La configuración real

A continuación, el núcleo del opencode.json que uso actualmente.

{
  "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
              }
            ]
          }
        }
      }
    }
  }
}

El conjunto se compone de cinco modelos de análisis y un modelo de ejecución.

Modelos de análisis (todos ven el mismo prompt y responden a la vez)

Modelo Desarrollador Características
xiaomi/mimo-v2.5-pro Xiaomi (小米) Fabricado por uno de los mayores fabricantes de smartphones de China. Relación calidad-precio muy alta
z-ai/glm-5.1 Zhipu AI (智譜AI) Surgido de la Universidad Tsinghua. Habitual en los primeros puestos de los benchmarks en chino. Fuerte en razonamiento lógico
deepseek/deepseek-v4-pro DeepSeek (深度求索) El conocido LLM disruptivo procedente de China. Rendimiento de programación sobresaliente
moonshotai/kimi-k2.7-code Moonshot AI (月之暗面) Modelo especializado en generación de código. Bien valorado en el procesamiento de contextos largos
minimax/minimax-m3 MiniMax (稀宇科技) Nuevo actor cuya reputación crece con rapidez en multimodalidad y procesamiento de textos largos

Modelo de ejecución (redacta la respuesta final a partir de los resultados del análisis)

  • deepseek/deepseek-v4-pro: a partir de las respuestas de los modelos de análisis, se encarga de la generación real de código y de la edición de archivos.

¿Por qué LLM chinos?

Sencillamente porque la relación calidad-precio es arrolladora.

En 2026, los LLM chinos ofrecen precios de API de entre 1/5 y 1/20 de los de Anthropic u OpenAI, con un rendimiento equivalente o superior. En particular, la capacidad de programación de DeepSeek V4 Pro a menudo da la sensación, en uso real, de igualar o incluso superar a Claude Sonnet y GPT-5.5.

4. Cómo funciona ── por qué Fusion por sí solo no basta

El flujo con Fusion en solitario es este:

  1. El usuario introduce un prompt
  2. Los cinco modelos de análisis generan cada uno de forma independiente una respuesta
  3. El modelo de ejecución (DeepSeek V4 Pro) compara y analiza esas respuestas, generando un análisis estructurado que extrae puntos de acuerdo, contradicciones y carencias
  4. Basándose en ese análisis, ese mismo modelo de ejecución (DeepSeek V4 Pro) genera el código final

Esto recuerda al trabajo en equipo humano: cinco ingenieros revisan la misma especificación y aportan cada uno sus comentarios de revisión, y una sola persona (DeepSeek V4 Pro) los analiza y organiza antes de implementarlos.

Sobre el límite de la ventana de contexto: la ventana de contexto de Fusion es de 128K tokens. A primera vista puede parecer escasa, y de hecho se llena antes de lo que uno esperaría, porque hay que meter ahí, además del historial de la conversación, las respuestas de los cinco modelos. Pero no hace falta alarmarse. Aunque se superen esos 128K y falle el paso de síntesis de Fusion, cada modelo de análisis ya ha terminado de procesar el prompt de forma individual, con su propia ventana de contexto, mucho más amplia (DeepSeek V4 Pro con un millón de tokens, Kimi K2.7 con unos 260.000, por ejemplo). opencode también conserva el historial completo de la sesión, así que la “memoria” de los modelos no se pierde. En la práctica, según mi experiencia, no supone un obstáculo serio.

Pero solo con esto todavía se queda muy lejos de Fable. Al fin y al cabo, Fable, siendo un único modelo, superaba con facilidad la precisión de una deliberación colegiada entre varios modelos. Ese es el verdadero músculo de Anthropic.

Por eso se añade una capa de revisión más a la salida de Fusion. Hay dos opciones.

Opción A: revisión de código con gpt-5.5-pro

  1. Generar código con la configuración de Fusion
  2. Pasar el código generado a gpt-5.5-pro con la instrucción “revisa esto y propón correcciones”
  3. Hacer que el modelo de ejecución original aplique esas correcciones

gpt-5.5-pro es bastante flojo generando código por sí solo, pero sorprendentemente bueno revisando código ya existente.

Opción B: revisión de PR con GitHub Codex

  1. Generar código con la configuración de Fusion
  2. Presentarlo como PR y pasarlo por la revisión de PR de GitHub Codex
  3. Incorporar los posibles fallos o las dudas de diseño que señale Codex

Codex realiza su revisión teniendo en cuenta el contexto de GitHub (issues, PR anteriores, estructura del proyecto), lo que le aporta una perspectiva distinta a la de una revisión de LLM genérico.

Basta con una de las dos opciones. Fusion (deliberación de cinco modelos) → revisión (gpt-5.5-pro o Codex): un montaje de dos etapas. La idea de fondo es esta: como no se llega ni de lejos al nivel de Fable en una sola pasada, se compensa con el proceso.

Los errores de versión de bibliotecas y el uso de API inexistentes, tan habituales con gpt-5.5 a secas, han disminuido notablemente con este montaje.

5. Velocidad y practicidad

La velocidad en sí apenas difiere de la de un único modelo. Como los cinco modelos se ejecutan en paralelo, el tiempo de respuesta bruto se mantiene dentro de un margen aceptable.

El problema es la precisión. Donde Fable acertaría a la primera, este montaje genera varios retrabajos. Como resultado, el tiempo total de desarrollo es claramente más lento que con Fable. Cada error se paga con lentitud.

Aun así, resulta bastante más utilizable que el gpt-5.5 a secas. El código generado con Fusion＋revisión ya se acerca bastante a la solución correcta desde el primer intento, sin duda más rápido que caer, con gpt-5.5 solo, en el bucle infinito de generar → corregir → corregir → corregir.

La sensación general sería: “la velocidad no está mal. En precisión queda muy lejos de Fable, pero varios peldaños por encima del gpt-5.5 a secas”. Un equilibrio razonable.

6. Extra: la capa de revisión y otros ajustes de opencode

Capa de revisión: gpt-5.5-pro o revisión de PR de Codex

La configuración de Fusion por sí sola no acaba de dar confianza, así que uso una de las dos opciones como capa de revisión.

gpt-5.5-pro: lo designo como subagente mediante la función task de opencode, con la instrucción de “revisar el código generado y proponer correcciones”. Si se le pide escribir código desde cero, el resultado es discreto, pero es extrañamente bueno encontrando defectos en código escrito por otros.

GitHub Codex: al presentar una PR, ejecuto la revisión de PR de Codex. Que tenga en cuenta el contexto completo del proyecto le da un matiz distinto al de una revisión de LLM genérico.

Cuál de los dos uso depende del día. Usar ambos a la vez sería, sin duda, excesivo y demasiado lento.

Otros ajustes

Además de Fusion, en opencode.json he incluido algunos ajustes prácticos adicionales.

{
  "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"]
  }
}

Hay dos puntos clave.

1. Bloqueo de comandos de borrado

Se deniegan explícitamente Remove-Item, del, rm, rmdir, rd, erase y git clean. Confiar el borrado de archivos a un agente de IA sencillamente me da miedo. Cuando de verdad hace falta borrar algo, lo hago yo mismo.

2. primary_tools: ["task"]

Con esto se prioriza la exploración en paralelo mediante subagentes (task). Al leer o buscar simultáneamente en varios archivos dentro de una base de código grande, hacerlo a través de task resulta claramente más rápido.

7. En resumen

El fin de Fable duele. Duele de verdad. Por ahora no existe nada que lo supere.

Pero tampoco se puede uno quedar de brazos cruzados, así que aguanto con un montaje que genera con OpenRouter Fusion＋LLM chinos y remata con una revisión de gpt-5.5-pro o una revisión de PR de Codex.

Los puntos clave de este montaje:

  • Generación de código mediante la “deliberación colegiada” de cinco modelos con OpenRouter Fusion
  • Modelos de análisis: Xiaomi Mimo / GLM / DeepSeek / Kimi / MiniMax
  • Modelo de ejecución: DeepSeek V4 Pro
  • Capa de revisión final: gpt-5.5-pro o revisión de PR de Codex (basta una de las dos)
  • Velocidad similar a la de un único modelo, aunque se ralentiza por los retrabajos derivados de una precisión inferior a la de Fable
  • Bastante más utilizable que el gpt-5.5 a secas. Lejos de Fable, pero suficiente para un uso práctico
  • Al ser LLM chinos, resulta difícil de usar con código de trabajo. Limitado a proyectos personales o de afición

Si sientes el vacío que ha dejado Fable en tus agentes de programación con IA, o si el gpt-5.5 a secas te parece demasiado poco fiable, este montaje merece la pena como solución provisional.

Basta con tener una cuenta de OpenRouter para empezar a usarlo hoy mismo.

Enlaces de referencia

Artículos relacionados

Artículos recientes con las mismas etiquetas para profundizar en temas cercanos.

Temas relacionados

Estas páginas sitúan el tema en un contexto más amplio de servicios y decisiones.

Servicios relacionados con este tema

El artículo está directamente relacionado con los siguientes servicios.

Preguntas frecuentes

Preguntas habituales en las consultas sobre el tema del artículo.

¿Qué es la función Fusion de OpenRouter?
Es un mecanismo que envía un mismo prompt a varios modelos a la vez, deja que uno de ellos (haciendo de juez) compare y analice sus respuestas para estructurar puntos de acuerdo, contradicciones y carencias, y hace que ese mismo modelo redacte la respuesta final a partir de dicho análisis. Podría describirse como un sistema de deliberación colegiada entre modelos. No es posible asignar roles o prompts distintos a cada modelo de análisis: todos reciben exactamente el mismo prompt. El agente de programación por línea de comandos opencode admite Fusion de forma nativa como plugin; basta con escribir la configuración en opencode.json para usarlo.
¿Por qué usar LLM chinos?
Sencillamente por su relación calidad-precio arrolladora. En 2026, los LLM chinos ofrecen precios de API de entre 1/5 y 1/20 de los de Anthropic u OpenAI, con un rendimiento equivalente o superior. En particular, la capacidad de programación de DeepSeek V4 Pro a menudo da la sensación, en uso real, de igualar o incluso superar a Claude Sonnet y GPT-5.5. Ahora bien, entregar código de trabajo a LLM chinos supone un riesgo real, así que este planteamiento está pensado exclusivamente para proyectos personales o de afición.
¿Por qué no basta con Fusion por sí solo?
Porque ni siquiera la deliberación colegiada de cinco modelos alcanza la precisión de Fable. Por eso se añade una capa de revisión adicional a la salida de Fusion. Hay dos opciones: hacer que gpt-5.5-pro revise el código generado y aplicar sus propuestas de corrección, o presentar el código como PR y pasarlo por la revisión de PR de GitHub Codex; basta con una de las dos. gpt-5.5-pro es bastante flojo generando código por sí solo, pero sorprendentemente bueno revisando código ya existente, mientras que Codex ofrece observaciones que tienen en cuenta el contexto completo del proyecto.
¿Qué tan práctico resulta este montaje?
Como los cinco modelos se ejecutan en paralelo, la velocidad apenas difiere de la de un único modelo. La precisión, en cambio, queda muy por detrás de Fable, y los retrabajos que genera alargan claramente el tiempo total de desarrollo. Aun así, es sin duda más rápido que caer, con gpt-5.5 a secas, en un bucle infinito de generar y corregir, y los errores de versión de bibliotecas o el uso de API inexistentes han disminuido de forma notable. Basta con tener una cuenta de OpenRouter para probarlo de inmediato.

Perfil del autor

Página de presentación del autor del artículo.

Go Komura

Representante de KomuraSoft LLC

Especializado en desarrollo de software para Windows, consultoría técnica e investigación de fallos, sobre todo en proyectos con sistemas existentes y errores difíciles de reproducir.

Contactar
Volver al blog