Cómo cambiar entre modelos de IA sin perder tu contexto (2026)

ori se instala con curl -fsSL https://openrouter.ai/labs/ori/install.sh | bash. Inicias sesión con tus credenciales de OpenRouter y ejecutas tu entorno a través de él. OpenRouter es sincero sobre el problema que resuelve: "Al usar una pasarela como OpenRouter, para obtener la misma experiencia lista para usar con Claude Code que obtienes usando el entorno nativo de Anthropic, hay muchas variables de entorno que debes configurar". La CLI también se adapta a lo que estás ejecutando: "En ori claude, detectamos tu indicador --model y cambiamos la configuración para que sea la más óptima para el modelo que estás usando".

Junto a esto, la guía de recetas de Claude Code de OpenRouter documenta cómo redirigir la CLI a un endpoint compatible con Anthropic mediante tres variables de entorno. Una vez configurado, puedes seguir usando modelos de Claude facturados a través de créditos, o reemplazar los "slots" de Opus, Sonnet y Haiku con modelos abiertos más económicos: GLM-5.2, DeepSeek V4, Qwen3-Coder, Kimi.

El enfoque de pasarela de Google apunta al mismo comportamiento desde el lado de la infraestructura: configuras nombres de modelos virtuales en una especificación OpenAPI 3.x, los apuntas a backends que incluyen Gemini, Claude y los modelos OSS-GPT de OpenAI, y enrutas el tráfico sin codificar endpoints de forma fija ni ejecutar tu propio proxy.

Los precios empujan en la misma dirección. El propio equipo de OpenAI ha dicho públicamente que el recorte de precio del 80% en GPT-5.6 Luna es permanente en lugar de promocional, y los análisis del sector en la misma semana señalaron que llegó días después de que Fable 5 de Anthropic se lanzara a $50 por millón de tokens de salida. Toma estas cifras específicas como datos de principios de agosto de 2026 y consulta los precios actuales antes de planificar en función de ellos, pero la dirección es clara: la elección del modelo se está convirtiendo en una decisión por tarea, y las herramientas ahora asumen que la tomarás a menudo.

Los modelos no mantienen el estado entre llamadas

Cada solicitud es autónoma. Todo lo que el modelo parece "saber" sobre tu proyecto llegó en la ventana de contexto de esa solicitud y se va con ella. La propia documentación de Cursor lo expresa claramente: "Los modelos de lenguaje grandes no retienen memoria entre completados". Nada en el enrutamiento cambia esto: una pasarela reenvía solicitudes, no acumula conocimiento.

Las funciones de memoria de cada proveedor son exclusivas de ellos

Las herramientas que utilizas tienen funciones de memoria reales ahora, y son genuinamente útiles. Sin embargo, cada una está bloqueada a su propio producto: las entradas de memoria de Claude, la memoria sintetizada entre chats de ChatGPT, los archivos de memoria local de Codex, el directorio de reglas de un IDE. Si enrutas una solicitud a un backend diferente, nada de eso la acompaña, porque para empezar nunca formó parte de la solicitud.

La configuración de tu entorno no es tu contexto

Este es el error que ori facilita cometer. Cuando las variables de entorno, los slots de modelos y los ajustes de razonamiento se gestionan de forma automática, el cambio parece completo: la herramienta se inicia, el modelo responde, todo parece configurado. Lo que realmente se movió fue la tubería. El conocimiento acumulado de tu base de código, las decisiones, los callejones sin salida, la razón por la que ese módulo parece incorrecto pero debe permanecer así, no se movieron a ningún lado.

Los modelos baratos hacen que el problema sea más visible, no menos

El argumento económico para el enrutamiento es real: enviar el trabajo rutinario a un modelo barato y reservar el costoso para problemas difíciles. Pero un modelo barato sin contexto produce un trabajo que tienes que corregir, y corregirlo cuesta el tiempo humano que intentabas ahorrar. Los ahorros solo se materializan cuando el modelo más barato comienza con el mismo nivel de comprensión que tenía el costoso.

Volver a pegar el briefing. Un bloque de contexto del proyecto al inicio de cada sesión. Funciona y es universal, razón por la cual casi todo el mundo lo hace. También cuesta tokens en cada llamada, y es un resumen: los detalles específicos se erosionan cada vez que alguien lo reescribe para acortarlo.

Archivos de instrucciones. AGENTS.md, .cursor/rules, CLAUDE.md, .trae/rules. Estas son las herramientas adecuadas para las reglas que siempre deben aplicarse, y la mayoría de los entornos las leen independientemente del modelo que esté detrás, lo que las convierte en la opción más portable disponible. No son un almacén de conocimiento: nadie quiere mantener a mano un preámbulo de 900 líneas que crece cada semana, y las reglas cargadas en cada solicitud son reglas por las que pagas en cada solicitud.

Mantener un solo modelo para todo. La solución más simple: evitar cambiar. También significa pagar tarifas premium por trabajo trivial y no usar el modelo que realmente es mejor para una tarea determinada.

Funciones de memoria por herramienta. Activar la memoria en todas partes y cruzar los dedos. Terminas con varias imágenes parciales que se distancian entre sí, y descubres que han divergido en el peor momento. Este es el mismo fallo que aparece siempre que múltiples agentes trabajan sin memoria compartida.

Búsqueda (retrieval) sobre el repositorio. Útil, y mejor que nada. La búsqueda encuentra texto que se asemeja a la consulta; no guarda la decisión que tomaste en junio o el enfoque que ya rechazaste, razón por la cual la búsqueda por sí sola no es memoria.

Si el modelo ahora es un componente intercambiable, el contexto debe dejar de vivir dentro de él. Coloca el conocimiento en su propia capa y permite que cualquier modelo al que enrutes lea de ella, de la misma manera que ori permite que cualquier modelo que elijas use el mismo entorno.

MemoryLake está diseñado exactamente para esa posición en la pila tecnológica: la memoria como su propia capa, accesible a través de MCP o una API, de forma independiente de qué modelo respondió la última vez.

Paso 1: Crear una clave de API

Genera una clave y realiza tu primera solicitud en unos 30 segundos.

Paso 2: Subir tus primeras memorias

Carga el material que todo modelo necesita independientemente de cuál esté de turno: notas de arquitectura, contratos de API, el registro de decisiones, manuales de procedimientos (runbooks) y las convenciones que no son obvias a partir del código. Los documentos, imágenes y otros archivos van todos al mismo lugar.

Paso 3: Conectar tu IA y agentes

Dale acceso a Claude, Codex, OpenClaw y otros agentes a través de MCP. Para cualquier cosa a la que accedas a través de una pasarela en lugar de un cliente MCP nativo, recupera las memorias relevantes a través de la API e inclúyelas en la solicitud que reenvía tu enrutador. La ruta cambia; lo que el modelo sabe sobre tu proyecto, no.

El primer efecto es que las decisiones de enrutamiento se vuelven puramente económicas. En este momento, elegir un modelo más barato tiene un costo oculto (el impuesto de restablecimiento del contexto), razón por la cual los equipos se quedan discretamente en el modelo costoso incluso para trabajos que no lo necesitan. Elimina ese impuesto y la pregunta de "qué modelo usar para esta tarea" se podrá responder únicamente en función del precio y la capacidad, que es la premisa sobre la que se construye todo el ecosistema de enrutamiento.

El segundo es que los lanzamientos de modelos dejan de ser disruptivos. Ha habido seis o siete lanzamientos de frontera a los que ha valido la pena cambiar en los últimos meses. Si evaluar uno nuevo significa reconstruir su comprensión de tu base de código, lo evaluarás con problemas de juguete y no aprenderás nada útil. Si el contexto se comparte, lo apuntas a la misma memoria y obtienes una comparación real en una tarde.

El tercero es la consistencia en una flota mixta. Si un modelo barato se encarga de tu andamiaje de pruebas y un modelo de frontera se encarga de la arquitectura, deberían trabajar a partir de la misma comprensión del sistema. De lo contrario, la salida del modelo barato contradice el diseño del modelo costoso, y alguien tendrá que darse cuenta.

Mantén las reglas y el conocimiento en lugares diferentes

Los archivos de instrucciones se trasladan bien entre entornos y modelos: úsalos para las reglas que siempre deben aplicarse. En su lugar, coloca el cuerpo creciente de conocimiento del proyecto en una capa de memoria, de modo que no pagues por un preámbulo gigante en cada solicitud y no edites a mano un archivo que cambia semanalmente.

Escribe por qué enrutaste, no solo hacia dónde

"La generación de pruebas va al modelo barato" es una decisión que revierte silenciosamente cualquiera que esté de guardia a las 2 a. m. "La generación de pruebas va al modelo barato porque la ventaja del modelo de frontera allí se midió por debajo del 3% en nuestra suite" sobrevive, y le dice a la siguiente persona qué debe volver a medir.

Vuelve a verificar los datos cuando vuelvas a enrutar

Las capacidades de los modelos, los límites de contexto y los precios cambian mensualmente, y los detalles de este artículo corresponden a principios de agosto de 2026. Antes de comprometerte con una política de enrutamiento, verifica los números actuales en la fuente. La lección general de cada cambio de modelo hasta ahora, ya sea Opus 5, DeepSeek V4 o GPT-5.6, es que la métrica de referencia que te importa es tu propia base de código.

Las herramientas se pusieron al día esta semana. ori hace que ejecutar Claude Code, Codex, OpenCode o Hermes contra cualquier modelo sea una instalación de una sola línea, y el enrutamiento a nivel de pasarela hace lo mismo en la capa de infraestructura. La elección del modelo es ahora una decisión por tarea, y la fricción que hacía que cambiar fuera algo raro casi ha desaparecido.

Lo que no se resolvió es lo que más importa en el día a día. Los modelos no retienen el estado entre llamadas, las funciones de memoria de cada proveedor no se transfieren entre ellos y un entorno perfectamente configurado sigue entregando tu repositorio a un extraño. Hasta que el conocimiento del proyecto viva en una capa externa a los modelos entre los que enrutas, cada cambio te costará el contexto que tenías, y el modelo barato al que cambiaste gastará sus ahorros en equivocarse.