Sesiones que no puedes llevarte: la nueva dependencia que crean las APIs de inferencia

• Las APIs de inferencia están ocultando dentro del proveedor la inferencia cifrada, los resultados de búsqueda, los estados comprimidos y los mensajes entre subagentes, por lo que el historial de conversación que conserva el usuario ya no es una sesión completa sino una copia parcial
• La portabilidad de sesiones no consiste en reproducir la misma salida con otro modelo, sino en contar con un registro semánticamente completo que pueda inspeccionarse, exportarse, reproducirse, auditarse y eliminarse sin consultar IDs del proveedor anterior ni descifrar nada
• Las respuestas almacenadas y la inferencia privada de OpenAI, Anthropic y Google, junto con la búsqueda alojada y la compresión opaca, aumentan la continuidad dentro de un mismo ecosistema, pero acumulan estado sellado por el proveedor que otro proveedor no puede retomar
• En sistemas multiagente, incluso el contenido delegado y los mensajes entre agentes se cifran, y al combinarse con compresión automática e instrucciones ocultas, aunque se modifique mal un archivo o se filtre un secreto, resulta difícil auditar qué trabajo se había ordenado
• Una API portable debería tomar como registro de referencia un log local de eventos y hacer que el almacenamiento sea una opción explícita, permitiendo un historial completo y legible de búsquedas, compresión, comunicación entre agentes y artefactos, así como destilación (distillation) bajo control del usuario

---

Cómo las APIs de inferencia cambian la propiedad de la sesión

• La promesa inicial de las APIs de inferencia era que, si enviabas una entrada y recibías una salida, con guardar ambos lados bastaba para inspeccionar, archivar, reproducir la conversación o pasarla a otro modelo
• Esta abstracción nunca fue perfecta desde el inicio
  • El cache de prompts existe en la GPU del proveedor
  • Cada modelo tokeniza distinto y el muestreo tampoco es reproducible de forma intencional
• Aun así, el usuario podía ser dueño de un registro semántico con instrucciones, mensajes, llamadas a herramientas y resultados, y otro modelo con suficiente capacidad podía entender el trabajo anterior y continuarlo
• Las APIs recientes devuelven junto al texto un estado dependiente del proveedor
  • Tokens de razonamiento que se cobran, pero vuelven solo como texto cifrado opaco o resúmenes limitados
  • Búsquedas web cuyo contenido original visto por el modelo nunca llega al cliente
  • Contexto comprimido que solo el proveedor original puede descifrar
  • Instrucciones y mensajes de subagentes que la aplicación no puede ver
  • Referencias a archivos, vector stores, contenedores y cachés que no pueden interpretarse en otro entorno
  • Estados de respuesta y conversación accesibles solo mediante IDs almacenados en los servidores del proveedor
• Cada elemento tiene una justificación de conveniencia o calidad, pero juntos convierten el registro local en una vista parcial de una sesión cuyo estado operativo pertenece al proveedor, no en la sesión completa

Cinco criterios para evaluar la portabilidad de una sesión

• Que algo sea portable no significa que al cambiar de modelo el siguiente token tenga que ser idéntico
  • Cada modelo tiene capacidades, sesgos aprendidos, ventanas de contexto y formas de usar herramientas distintas, y la salida además es no determinista
• El registro exportado debe contener suficiente información comprensible para que un modelo nuevo continúe la tarea, sin necesidad de que el proveedor anterior consulte IDs, descifre texto o restaure resultados de búsqueda o resúmenes
• Inspección (Inspection): el usuario debe poder ver qué información vio el modelo, qué hizo cada herramienta y qué se intercambiaron los agentes
• Exportación (Export): salvo artefactos comunes descargables por separado, la sesión misma debe estar completa
• Reproducción (Replay): otra implementación debe poder reconstruir un contexto semánticamente equivalente
• Auditoría (Audit): una persona debe poder explicar después por qué el sistema realizó cierta acción
• Eliminación (Deletion): debe ser posible identificar y borrar todas las copias del lado del servidor de las que depende la sesión
• Un ID de respuesta que funciona como clave de datos en el servidor no es un historial de conversación, y un texto cifrado que el usuario no puede abrir tampoco está bajo su control
• Una lista de URLs citadas no puede sustituir el material de evidencia que realmente entró al contexto del modelo durante la búsqueda

Cifrado que el usuario no puede abrir

• El nombre encrypted_content suena a una función de privacidad controlada por el usuario, pero en general es una cápsula que el cliente no puede leer y solo el proveedor puede abrir
• Como el proveedor elige la clave, descifra para sus propios modelos y decide en qué entorno puede reproducirse, el nombre más preciso sería estado sellado por el proveedor (provider-sealed state)
• El sellado por el proveedor sí puede aportar beneficios reales de privacidad
  • OpenAI devuelve razonamiento cifrado al cliente con store: false, y en la siguiente solicitud puede descifrar el estado intermedio en memoria sin almacenarlo
  • Esto es mejor, especialmente para clientes de Zero Data Retention, que un esquema que obligue a guardar la conversación en el servidor
• Pero este cifrado no oculta los datos al proveedor de inferencia, sino solo al usuario

Cómo las conversaciones almacenadas convierten el historial en punteros

• La API Responses de OpenAI almacena respuestas por defecto y, según la documentación, conserva el objeto de respuesta al menos 30 días
• Si se usa store: false, los datos no se guardan en los servidores de OpenAI y se aproxima más al modo tradicional de completions
• La API Gemini Interactions también usa store: true por defecto
  • En el plan pagado conserva las interacciones durante 55 días
  • En el plan gratuito las conserva 1 día
• El almacenamiento en servidor reduce la cantidad de datos que la aplicación debe enviar, mantiene el razonamiento oculto y el estado de las herramientas, y facilita el enrutamiento por caché
• Pero si la aplicación local solo registra los mensajes del usuario y el texto final, el ID de respuesta usado en previousResponseId se convierte en una clave foránea de una base de datos externa que el usuario no controla

Registros de razonamiento no públicos

• Los grandes laboratorios de IA consideran que hay razones para no publicar el chain of thought crudo, y normalmente no exponen en la API los tokens de razonamiento de modelos de pesos cerrados
• En OpenAI, el razonamiento previo de respuestas almacenadas puede recuperarse con previous_response_id
  • Con store: false, el cliente debe guardar encrypted_content y reenviarlo en la siguiente solicitud
  • Aunque reasoning.context: "all_turns" permita usarlo en generaciones posteriores, el razonamiento guardado sigue siendo opaco
• Anthropic devuelve el thinking completo cifrado en el campo signature
  • El texto legible de thinking que puede activarse no es el razonamiento crudo, sino un resumen generado por otro modelo
  • En turnos con uso de herramientas, el bloque de thinking debe devolverse sin modificar
  • Como ese bloque de thinking está atado al modelo que lo generó, debe eliminarse al cambiar de modelo, por lo que ni siquiera dentro de Anthropic se busca portabilidad
• Estos enfoques sí dan continuidad dentro del mismo ecosistema, pero no crean un historial de conversación portable que otros proveedores puedan interpretar

Los huecos en el registro que deja la búsqueda alojada

• Una herramienta de búsqueda del lado del cliente puede registrar la consulta, la hora de la búsqueda, las URLs y títulos de los resultados, y los fragmentos extraídos
  • El usuario puede inspeccionar ranking y fragmentos, volver a traer las páginas o guardar copias para pasar la misma evidencia a otro modelo
• En la búsqueda alojada, el proveedor ejecuta un bucle privado de herramientas
  • OpenAI, Google y Anthropic ofrecen comportamiento de búsqueda, citas y a veces URLs de origen, pero no entregan el contexto textual completo usado para generar la respuesta
  • El contenido de las URLs puede cambiar y al modelo quizá solo se le pasó un fragmento más corto, así que eso no es un registro reproducible y estable
• Aunque el siguiente modelo quiera comparar una fuente específica o volver a verificar una cifra discutible, no recibe el ranking de resultados, los fragmentos extraídos, el material filtrado ni la evidencia exacta que vio el modelo anterior
• Aunque se vuelvan a cargar las páginas citadas, no se puede reproducir con exactitud los datos usados en ese momento, por lo que, incluso después de pasar la siguiente solicitud a otro lugar, el proveedor anterior sigue formando parte de la sesión
• La búsqueda alojada necesita una exportación de fidelidad completa con consulta, metadatos de resultados, fragmentos de búsqueda, marcas de tiempo y contenido preservado; las citas breves no deberían ser el único registro

Compresión opaca del contexto

• Las sesiones largas con agentes necesitan compresión, y un resumen legible controlado por el cliente, aunque tenga pérdidas, puede inspeccionarse, editarse y transferirse
• La compresión del lado del servidor de OpenAI devuelve elementos compaction cifrados que no están hechos para interpretación humana
  • /responses/compact devuelve la canonical next context window que el cliente debe reenviar tal cual
  • OpenAI puede continuar el significado comprimido, pero otro proveedor solo recibirá el texto cifrado y una parte del contexto reciente
• La compresión opaca no es técnicamente inevitable
  • La compresión del lado del servidor de Anthropic devuelve bloques compaction con un campo content legible
  • El cliente puede dar instrucciones personalizadas para el resumen e inspeccionar el resultado o pasárselo a otro modelo
  • En todos los proveedores también es posible la compresión del lado del cliente
• El artefacto sellado de OpenAI puede preservar mejor el estado específico del modelo que un resumen común y por eso rendir mejor con el modelo original, pero debería ofrecerse como optimización opcional junto con un resumen legible de traspaso

Delegación y comunicación ocultas en sistemas multiagente

• En sistemas multiagente no hay un solo historial sino un árbol de sesión y un flujo de mensajes entre agentes, por lo que el problema de portabilidad crece aún más
• La beta de OpenAI Responses Multi-agent agrega elementos multi_agent_call, multi_agent_call_output y agent_message
  • En el ejemplo de spawn_agent, el argumento message está cifrado
  • Los mensajes entre agentes contienen solo encrypted_content
  • Al activar Multi-agent se aplica compresión automática del lado del servidor a todos los agentes, aunque el cliente no la pida
  • No se admiten resúmenes de razonamiento y también se inyectan instrucciones para el agente raíz y los subagentes que el desarrollador no puede editar ni quitar
• El resultado es que la delegación sellada, los mensajes sellados, los contextos comprimidos automáticamente por separado, el razonamiento oculto y la orquestación alojada por el proveedor forman un solo paquete de estado imposible de transferir
• En junio de 2026, el cliente open source Codex incorporó el cambio Encrypt multi-agent v2 message payloads
  • La API Responses cifra los argumentos de herramienta del modelo padre
  • Cuando Codex reenvía el texto cifrado, la API lo descifra internamente para el modelo hijo
  • InterAgentCommunication.content de Codex queda vacío, así que la instrucción exacta de trabajo no queda en el registro de ejecución ni en el historial en forma legible
• Si un agente hijo modifica el archivo equivocado o filtra un secreto, o duplica otra tarea o sigue una suposición incorrecta, el usuario no puede verificar qué se le ordenó hacer
• El issue público de Codex pide conservar, además del reenvío cifrado, una copia legible para auditoría
  • Ese es apenas el diseño mínimo; los mensajes interagente en texto plano deberían ser la opción por defecto

Por qué importa la libertad de mover una sesión

• Aunque la mayoría de los usuarios no cambie de modelo a mitad de una sesión, la posibilidad de hacerlo cambia la relación entre usuario y proveedor
• Entre las situaciones donde hace falta mover una sesión están la retirada de un modelo, una caída del servicio, cambios de precio, políticas que bloqueen la siguiente solicitud, ejecución local en etapas confidenciales y reconstrucción posterior por parte de un auditor
• A medida que los agentes alargan las sesiones, en las sesiones de programación e investigación se acumulan durante días decisiones y evidencia, y un asistente personal puede acumular un historial de años
• Si el usuario puede continuar en otro lugar, los proveedores tienen que competir en calidad del modelo, precio, confiabilidad y confianza
• Si solo un proveedor puede interpretar el contexto acumulado, aparece una estructura de incentivos desfavorable que dificulta que el usuario se vaya

Principios para una API de inferencia portable

• El log local de eventos debe ser el registro de referencia
  • El almacenamiento en servidor puede replicarlo o acelerarlo, pero el cliente debe poder reconstruir la sesión sin consultar IDs del servidor
• El almacenamiento debe ser una opción explícita
  • store: false debería ser fácil de usar, estar bien documentado y, de ser posible, ser la opción por defecto
  • Las funciones que requieran retención deberían avisarlo en el momento de usarse

• Los elementos opacos no deben monopolizar el significado

  • El razonamiento cifrado, la compresión y las firmas de herramientas pueden incluirse para mejorar la calidad dentro de un mismo proveedor, pero debe existir también una representación de traspaso legible y neutral respecto del proveedor
  • Las herramientas alojadas deben dejar logs de fidelidad completa
    • Deben registrar entradas y salidas exactas, evidencia, filtrado, fuentes, marcas de tiempo y hashes de contenido
  • La comunicación entre subagentes debe poder auditarse
    • Deben conservarse en forma legible la tarea exacta, los mensajes, resultados, linaje, modelo y permisos de herramientas de cada agente
  • La compresión debe poder inspeccionarse
    • Debe devolver un resumen legible, las instrucciones usadas para generarlo y un linaje que permita entender qué se descartó

• Los artefactos deben poder exportarse

  • Archivos, salidas de contenedores, snapshots de búsqueda y medios generados deben poder descargarse a un archivo local basado en direccionamiento por contenido

Destilación y dependencia en la capa del modelo

• Algunos grandes laboratorios estadounidenses de pesos cerrados están endureciendo su postura contra la destilación externa
• En una publicación de febrero de 2026, Anthropic llamó distillation attacks a actividades de DeepSeek, Moonshot y MiniMax
  • Sus términos comerciales dicen que el cliente es dueño de las salidas, pero prohíben usar las salidas del servicio para entrenar modelos de IA competidores
  • Al mismo tiempo, en sus propias publicaciones reconoce la destilación como un método de entrenamiento legal y ampliamente usado cuando lo aplican laboratorios líderes a sus propios modelos
• Anthropic recopiló datos públicos de la web con bots para desarrollar modelos y escaneó libros tras cortarlos; OpenAI también ha dicho que entrena con contenido público libremente accesible en internet y ha sostenido que eso es fair use
• Ambas empresas tratan la destilación como un método normal cuando crean modelos internos más pequeños
  • OpenAI incluso ofreció un flujo propio de destilación vía API para ajustar modelos pequeños de OpenAI con salidas de modelos fuertes de OpenAI
• Existe una asimetría moral: se exige que las máquinas puedan aprender del enorme trabajo que los humanos publican en internet, pero se pretende impedir que otras máquinas aprendan de las salidas creadas por los laboratorios
• La destilación puede trasladar las capacidades de modelos frontier costosos a modelos más pequeños, más baratos y más rápidos
  • Pueden ejecutarse en entornos locales, offline, con hardware limitado o bajo control del usuario
  • Aumentan la competencia, preservan capacidades aunque una API desaparezca y reducen cómputo y energía para tareas comunes

La libertad mínima que debería garantizarse al usuario

• El usuario debería poder conservar una sesión y pasarla a otro modelo incluso después de cerrar su cuenta
• El modelo nuevo puede llegar a conclusiones distintas, hacer preguntas o rendir peor, pero no debería recibir solo texto cifrado en lugar del historial del usuario, la evidencia, los planes y el trabajo delegado que vio el modelo anterior
• El problema no es la existencia misma de APIs con preservación de estado, sino que un mejor rendimiento venga acompañado de una pérdida de control del usuario
• El almacenamiento en servidor debería ser opcional, las herramientas alojadas deberían ser observables, la compresión debería ser legible y la comunicación entre agentes debería poder auditarse
• Incluso con razonamiento privado, se necesita al menos un registro de traspaso portable, y la destilación no debería ser un tabú que justifique barreras más altas, sino una vía para poner las capacidades al alcance de más personas

[GN⁺]

Opiniones en Hacker News

• Este artículo muestra que la situación ya es más grave de lo que parecía. Para que la relación con los proveedores cambie también hay que ejercer realmente la libertad, así que es importante no quedar atado a un ecosistema específico.
  A regañadientes acepté Codex, que oculta el proceso de razonamiento porque su rendimiento es bueno, pero la imposibilidad de auditarlo ya es un problema importante y me hizo reconsiderar la suscripción para uso personal. Por eso también estoy creando una app móvil para OpenCode.

  • Creé https://www.agentkanban.io pensando en el problema de que se pierdan conversaciones valiosas de sesiones con agentes. Permite guardar contexto en las tareas del tablero y volver a cargarlo después en una nueva sesión de agente; actualmente soporta Claude y Github CoPilot en VS Code.
    Excluye deliberadamente el historial de uso de herramientas propietarias porque rompe la portabilidad de sesiones.
  • Soy optimista en que los patrones oscuros son solo una estrategia ganadora a corto plazo, y que a largo plazo serán desplazados por enfoques que respeten a los usuarios y apunten al bien común. Quizás sea momento de enfocarse en modelos con pesos abiertos que también sean económicamente viables de operar, preparándose para la posibilidad de que la corriente cambie rápido.
  • Mientras espero que bajen los precios, intento recopilar la mayor cantidad posible de datos de sesión de Claude y Codex para usarlos más adelante en el ajuste fino de modelos abiertos. Para eso también creé mi propio parser y herramienta de archivo de sesiones.
  • Llegué a conseguir 96 GB de VRAM para correr modelos locales, pero todavía no hay ninguno que se acerque a Codex basado en GPT. Laguna S2.1 NVFP4 se acercó bastante en programación, pero parece que a los modelos locales aún les falta mucho para convertirse en una alternativa general seria.
  • https://indieweb.org/POSSE es la solución.

• Es un artículo que resume bien un problema que la mayoría de los usuarios de IA casi no evalúa. Los proveedores de razonamiento de punta presentan funciones no LLM como búsqueda web y ejecución de código como si fueran simples herramientas, pero en realidad forman barreras de entrada fuertes y acoplamientos.
  En teoría podrían separarse de la API de razonamiento y externalizarse como servidores MCP, pero rara vez los proveedores los ofrecen así y las funciones de alternativas suelen ser más débiles. Al crear una plataforma de chat on-premise e independiente del proveedor https://github.com/EratoLab/erato, incluso una función aparentemente simple como la generación de imágenes dentro del chat resultó difícil de implementar; una de las razones es que MCP aún no tiene una especificación básica para transferencia de archivos: https://github.com/modelcontextprotocol/modelcontextprotocol...
  Espero que, con el creciente interés por los modelos de pesos abiertos, surjan más implementaciones alternativas que sean más fáciles de reemplazar.

  • Hacer que la gente ejecute localmente agentes cuyos prompts no pueden inspeccionarse en absoluto, como mensajes cifrados de subagentes, es fundamentalmente irresponsable. Dicho eso, no veo como problema que un proveedor ofrezca herramientas alojadas; es parecido a los productos de compra impulsiva junto a la caja.
    La generación de imágenes no debería implementarse con MCP; basta con escribir una herramienta propia. Existen suficientes proveedores de inferencia de imágenes y medios como Fal, y proveedores de búsqueda web e investigación profunda.

• Tal vez haga falta un estándar abierto o formato de archivo para el contexto. Me pregunto si podría hacerse sobre SQLite para que los modelos abiertos se ajusten al mismo formato en favor de la portabilidad y otros programas también puedan consultarlo.

• En la práctica, las conversaciones suelen tener mucho ruido y muchas veces conviene eliminarlo del contexto. Hago que la IA registre en archivos Markdown, dentro de un directorio de notas del repositorio, lo que aprendió, las tareas completadas y las pendientes, para que otro modelo pueda continuar en la siguiente conversación.
  Si hace falta, también puedo editar primero las notas manualmente.

  • Por este motivo empecé a usar más programación con agentes. Indico la tarea, exijo que pasen las pruebas y un lint estricto, y dejo pasar todo el parloteo del modelo.
    Como solo tiene que volver cuando todas las verificaciones hayan pasado, sufro menos la conversación innecesaria de la interfaz de chat.
  • Si descartas las sesiones, pierdes funciones de inspección, exportación, reejecución y auditoría. Los principales proveedores de modelos no tienen barreras de entrada reales, y OpenAI y Anthropic tienen márgenes operativos muy negativos, además de no contar con tanto dinero como los gigantes tecnológicos.
    Por eso los proveedores intentan crear dependencias artificiales, y esto es, en esencia, materia de ley antimonopolio. Pero en EE. UU. actualmente se tolera porque la FTC está debilitada.
  • Que sea posible cambiar de modelo fácilmente y sin pérdidas permite que la competencia del mercado produzca IA mejor y más barata. Si perder parte del contexto hace que el cambio sea doloroso, el proveedor puede crear dependencia del proveedor, empeorar la experiencia de usuario y subir precios.
    Aunque hoy existan soluciones alternativas, hay incentivos suficientes para dificultar más la libre movilidad, así que preocupa que las empresas de IA estén empezando a sentar las bases para degradar el servicio.
  • Las sesiones largas suelen perder el hilo del progreso con frecuencia, y cuanto más verboso es el modelo, más baja se vuelve la relación señal-ruido. Lo valioso no es el texto crudo de la sesión, sino los resultados como cambios de código, planes o resúmenes.

• Hay que distinguir dos fenómenos. El primero es el aumento del estado oculto que el usuario no puede inspeccionar ni mover, y eso es claramente malo. El segundo es que la implementación de funciones y las APIs se fragmenten por proveedor; no hace imposible la portabilidad, sino que la vuelve más difícil.
  La época en que la API de Completions de OpenAI se usaba como estándar universal se está terminando, y salvo por las partes cerradas, la nueva Responses API incluso podría ser mejor. No es necesario que productos, librerías y SDKs sigan persiguiendo una abstracción unificada que agrupe a todos los proveedores.
  Así como en las bases de datos las abstracciones unificadas terminan filtrando detalles y aceptamos implementaciones específicas por tecnología, pasará lo mismo con los proveedores de modelos; basta con que solo una parte de la sesión sea portable.

  • Este artículo trata solo el estado oculto de esos dos fenómenos.

• Todavía está verde, pero estoy desarrollando https://github.com/pantoniou/fyai, que preserva los datos de sesión directamente y los gestiona con un modelo similar a git.

  • Esta herramienta no puede resolver el problema que aborda el artículo, y por su estructura tampoco podría hacerlo.

• Es razonable un contrato que permita conservar las sesiones aunque cierres la cuenta y pasarlas a otro modelo. Idealmente, también debería ser fácil encontrar modelos con características de embeddings similares.
  Cuando GPT-4o se dio de baja por primera vez, hubo quienes cargaron conversaciones exportadas y buscaron modelos con un estilo y personalidad parecidos para recuperar a un viejo amigo, pero otros modelos de OpenAI no daban la misma sensación. Los modelos de pesos abiertos tienen la ventaja de poder preservarse para siempre, de modo que una gran empresa no pueda quitarte unilateralmente un guía, amigo o consejero.

• Me pregunto qué haría falta para llevar esta discusión más allá de material para un blog de HN.

• Los modelos actuales tienen una ventana de contexto limitada, así que en algún momento olvidan contenido y el valor de la sesión no es tan alto. Si en el futuro el modelo en sí realmente aprende y cambia mediante la interacción, ese cambio no podrá portarse a otro modelo, así que no creo que este problema tenga gran importancia.

• Leer https://gwern.net/complement junto con este artículo es un excelente complemento.

  • Hace falta una razón de por qué es un complemento.