Sessões que você não pode levar: a nova dependência criada pelas APIs de inferência

• À medida que as APIs de inferência escondem inferência criptografada, resultados de busca, estado compactado e mensagens de subagentes dentro do provedor, o histórico de conversas mantido pelo usuário está se tornando não uma sessão completa, mas uma cópia apenas parcialmente visível
• Portabilidade de sessão não é reproduzir a mesma saída em outro modelo, mas obter um registro semanticamente completo que possa ser inspecionado, exportado, reproduzido, auditado e excluído sem consulta de IDs ou descriptografia pelo provedor original
• As respostas armazenadas e a inferência privada da OpenAI, Anthropic e Google, junto com busca hospedada e compactação opaca, aumentam a continuidade dentro do mesmo ecossistema, mas acumulam um estado selado pelo provedor que outro provedor não consegue assumir
• Em sistemas multiagente, até delegações e mensagens entre agentes são criptografadas; combinadas com compactação automática e instruções ocultas, isso torna difícil auditar qual tarefa foi instruída quando ocorre uma edição incorreta de arquivos ou vazamento de segredos
• Uma API portátil deve usar o log de eventos local como registro de referência, tornar o armazenamento uma escolha explícita e permitir um histórico completo legível de busca, compactação, comunicação entre agentes e artefatos, além de destilação (distillation) sob controle do usuário

---

Como as APIs de inferência mudam a propriedade da sessão

• A promessa das primeiras APIs de inferência era que, ao enviar uma entrada e receber uma saída, se você guardasse as duas, poderia inspecionar, arquivar, reproduzir a conversa ou passá-la para outro modelo
• Essa abstração nunca foi completa desde o início
  • O cache de prompt existe nas GPUs do provedor
  • Cada modelo tem tokenização diferente, e a amostragem também não é reproduzida intencionalmente
• Ainda assim, o usuário podia possuir um registro semântico contendo instruções, mensagens, chamadas de ferramentas e resultados, e outro modelo suficientemente capaz podia entender o trabalho anterior e continuá-lo
• APIs recentes retornam, junto com texto, um estado preso ao provedor
  • Tokens de inferência cobrados, mas retornados apenas como ciphertext opaco ou resumos limitados
  • Busca na web em que o cliente não recebe o texto original visto pelo modelo
  • Contexto compactado que só o provedor original consegue descriptografar
  • Instruções e mensagens de subagentes invisíveis para a aplicação
  • Referências a arquivos, vector stores, contêineres e caches que não podem ser interpretadas em outro ambiente
  • Respostas e estado de conversa acessíveis apenas por IDs armazenados no servidor do provedor
• Cada um desses elementos tem justificativas de conveniência ou qualidade para o usuário, mas, juntos, fazem do registro local não a sessão inteira, e sim uma visão parcial de uma sessão cujo estado operacional é propriedade do provedor

Cinco critérios para julgar a portabilidade de sessão

• Ser portátil não significa que, ao trocar de modelo, o próximo token deva ser o mesmo
  • Modelos diferem em capacidade, tendências aprendidas, janela de contexto e forma de usar ferramentas, e a própria saída é não determinística
• O registro exportado deve conter informações compreensíveis o suficiente para que um novo modelo continue a tarefa, sem precisar que o provedor anterior consulte IDs, descriptografe ciphertext ou restaure resultados de busca ou resumos
• Inspeção (Inspection): o usuário deve poder ver as informações vistas pelo modelo, as ações executadas pelas ferramentas e o que os agentes trocaram entre si
• Exportação (Export): exceto por artefatos comuns que possam ser baixados separadamente, a sessão em si deve ser autocontida
• Reprodução (Replay): outra implementação deve conseguir reconstruir um contexto semanticamente equivalente
• Auditoria (Audit): uma pessoa deve conseguir explicar, depois do fato, por que o sistema realizou determinada ação
• Exclusão (Deletion): deve ser possível identificar e remover todas as cópias do lado do servidor das quais a sessão depende
• Um ID de resposta que é chave para dados no servidor não é histórico de conversa, e ciphertext que o usuário não consegue abrir também não é estado sob controle do usuário
• Uma lista de URLs citadas não substitui o material de evidência que de fato entrou no contexto do modelo durante a busca

Criptografia que o usuário não consegue abrir

• O nome encrypted_content parece um recurso de privacidade controlado pelo usuário, mas geralmente é uma cápsula que o cliente não consegue ler e que só o provedor pode abrir
• Como o provedor escolhe a chave, descriptografa para seu próprio modelo e decide em qual ambiente isso pode ser reproduzido, o nome mais preciso é estado selado pelo provedor (provider-sealed state)
• O selo do provedor pode trazer benefícios reais de privacidade
  • A OpenAI retorna inferência criptografada ao cliente com store: false e pode descriptografar o estado intermediário em memória na próxima solicitação sem armazená-lo
  • Isso é especialmente melhor do que exigir armazenamento de conversas no servidor para clientes de Zero Data Retention
• Mas essa criptografia não esconde os dados do provedor de inferência; ela os esconde apenas do usuário

Como conversas armazenadas transformam registros em ponteiros

• A OpenAI Responses API armazena respostas por padrão e, segundo a documentação, preserva o objeto de resposta por pelo menos 30 dias
• Ao usar store: false, os dados não são armazenados nos servidores da OpenAI, aproximando-se do método antigo de completions
• A Gemini Interactions API também tem store: true como padrão
  • O nível pago preserva interações por 55 dias
  • O nível gratuito preserva por 1 dia
• O armazenamento no servidor reduz a quantidade de dados enviada pela aplicação, mantém inferência oculta e estado de ferramentas e facilita o roteamento de cache
• Mas, se a aplicação local registra apenas mensagens do usuário e o texto final, o ID de resposta usado em previousResponseId vira uma chave estrangeira de um banco de dados externo que o usuário não controla

Registros de inferência não divulgados

• Os principais laboratórios de IA entendem que há motivos para não divulgar o raciocínio bruto (chain of thought) e geralmente não expõem tokens de inferência de modelos de pesos fechados na API
• Na OpenAI, é possível recuperar a inferência anterior de respostas armazenadas via previous_response_id
  • Com store: false, o cliente precisa guardar encrypted_content e reenviá-lo na próxima solicitação
  • Mesmo que reasoning.context: "all_turns" permita usá-la em gerações futuras, a inferência armazenada continua opaca
• A Anthropic retorna o thinking completo criptografado no campo signature
  • O texto de thinking legível que pode ser ativado não é o raciocínio bruto, mas um resumo criado por outro modelo
  • Em turnos com uso de ferramentas, os blocos de thinking devem ser devolvidos sem alteração
  • Blocos de thinking ficam vinculados ao modelo que os gerou e precisam ser removidos ao trocar de modelo, portanto nem dentro da Anthropic eles miram portabilidade
• Esses métodos oferecem continuidade dentro do mesmo ecossistema, mas não criam um histórico de conversa portátil que modelos de outro provedor consigam interpretar

Lacunas de registro deixadas pela busca hospedada

• Uma ferramenta de busca do lado do cliente pode registrar consulta, horário da busca, URLs e títulos dos resultados e trechos extraídos
  • O usuário pode inspecionar rankings e trechos, buscar as páginas novamente ou salvar cópias para entregar a mesma evidência a outro modelo
• Na busca hospedada, o provedor executa um loop de ferramenta privado
  • OpenAI, Google e Anthropic fornecem ações de busca, citações e URLs de fonte opcionais, mas não o contexto textual completo usado para gerar a resposta
  • O conteúdo das URLs pode mudar, e talvez apenas trechos mais curtos tenham sido enviados ao modelo, portanto isso não é um registro de reprodução estável
• Mesmo que o próximo modelo tente comparar uma fonte específica ou revalidar um número controverso, ele não recebe o ranking dos resultados, os trechos extraídos, o material filtrado nem a evidência exata vista pelo modelo anterior
• Recarregar as páginas citadas não reproduz exatamente os dados usados naquele momento; por isso, mesmo depois que a próxima solicitação passa para outro lugar, o provedor anterior permanece como parte da sessão
• A busca hospedada precisa de uma exportação de fidelidade completa contendo consultas, metadados dos resultados, trechos de busca, timestamps e conteúdo preservado; citações resumidas não devem ser o único registro

Compactação opaca de contexto

• Sessões longas com agentes precisam de compactação, e resumos legíveis controlados pelo cliente podem ser inspecionados, editados e transferidos, mesmo com perdas
• A compactação do lado do servidor da OpenAI retorna itens de compaction criptografados que não foram feitos para interpretação humana
  • /responses/compact retorna uma canonical next context window que o cliente precisa reenviar tal como está
  • A OpenAI consegue continuar o significado compactado, mas outros provedores recebem apenas ciphertext e parte do contexto recente
• Compactação opaca não é tecnicamente inevitável
  • A compactação do lado do servidor da Anthropic retorna um bloco compaction com um campo content legível
  • O cliente pode fornecer instruções de resumo personalizadas, inspecionar o resultado ou enviá-lo a outro modelo
  • A compactação do lado do cliente também é possível em todos os provedores
• Artefatos selados da OpenAI podem preservar melhor o estado específico do modelo do que resumos comuns e oferecer melhor desempenho no modelo original, mas devem ser uma otimização opcional acompanhada de um resumo de handoff legível

Delegação e comunicação ocultas em sistemas multiagente

• Em sistemas multiagente, há não um único registro, mas uma árvore de sessões e fluxos de mensagens entre agentes, o que amplia o problema de portabilidade
• O beta Multi-agent da OpenAI Responses adiciona itens multi_agent_call, multi_agent_call_output e agent_message
  • O argumento message do exemplo spawn_agent é criptografado
  • Mensagens entre agentes contêm apenas encrypted_content
  • Ao ativar Multi-agent, a compactação automática do lado do servidor é aplicada a todos os agentes, mesmo sem solicitação do cliente
  • Resumos de inferência não são suportados, e também são injetadas instruções de raiz e de subagentes que desenvolvedores não podem editar nem remover
• Como resultado, delegações e mensagens seladas, contextos compactados automaticamente de forma separada, inferência oculta e orquestração hospedada pelo provedor formam um pacote de estado impossível de migrar
• Em junho de 2026, o cliente open source Codex recebeu a mudança Encrypt multi-agent v2 message payloads
  • A Responses API criptografa os argumentos de ferramenta do modelo pai
  • Quando o Codex transmite o ciphertext, a API o descriptografa internamente para o modelo filho
  • InterAgentCommunication.content no Codex fica vazio, de modo que a instrução exata da tarefa não permanece no log de execução e no histórico legíveis
• Quando um agente filho altera o arquivo errado, vaza um segredo, duplica outra tarefa ou segue uma suposição incorreta, o usuário não consegue verificar o que foi instruído a fazer
• Uma issue pública do Codex pede a preservação de uma cópia de auditoria legível separada do encaminhamento criptografado
  • Esse é um desenho mínimo; mensagens em texto claro entre agentes deveriam ser o padrão

Por que é preciso liberdade para mover sessões

• Mesmo que a maioria dos usuários não troque de modelo no meio de uma sessão, a possibilidade de migrar muda a relação entre usuário e provedor
• Situações que exigem transferência de sessão incluem descontinuação de modelo, falha de serviço, mudança de preço, políticas que bloqueiam a próxima solicitação, execução local de etapas confidenciais e reconstrução posterior por auditores
• À medida que agentes tornam as sessões mais longas, sessões de programação e pesquisa acumulam dias de decisões e evidências, e assistentes pessoais podem acumular anos de histórico
• Se o usuário puder continuar em outro lugar, os provedores precisam competir em qualidade de modelo, preço, confiabilidade e confiança
• Quando só um provedor consegue interpretar o contexto acumulado, surge uma estrutura de incentivos desfavorável que dificulta a saída do usuário

Princípios para APIs de inferência portáteis

• O log de eventos local deve ser o registro de referência
  • O armazenamento no servidor pode replicá-lo ou acelerá-lo, mas o cliente deve conseguir reconstruir a sessão sem consultar IDs no servidor
• O armazenamento deve ser uma escolha explícita
  • store: false deve ser fácil de usar e bem documentado, e de preferência ser o padrão
  • Recursos que exigem retenção devem informar isso no momento de uso

• Itens opacos não devem monopolizar o significado

  • Inferência criptografada, compactação e assinaturas de ferramentas podem ser incluídas para melhorar a qualidade no mesmo provedor, mas também deve haver uma representação de handoff legível e neutra em relação ao provedor
  • Ferramentas hospedadas devem deixar logs de fidelidade completa
    • Devem registrar entradas e saídas exatas, evidências, filtragem, fontes, timestamps e hashes de conteúdo
  • A comunicação entre subagentes deve ser auditável
    • A tarefa exata, mensagens, resultados, linhagem, modelo e permissões de ferramentas de cada agente devem ser preservados de forma legível
  • A compactação deve ser inspecionável
    • Deve retornar resumos legíveis, as instruções usadas para criar o resumo e uma linhagem que permita entender o que foi descartado

• Artefatos devem ser exportáveis

  • Arquivos, saídas de contêiner, snapshots de busca e mídia gerada devem poder ser baixados como arquivos locais endereçados por conteúdo

Dependência de destilação e da hierarquia de modelos

• Alguns grandes laboratórios americanos de pesos fechados vêm endurecendo sua postura contra a destilação externa
• Em uma publicação de fevereiro de 2026, a Anthropic chamou atividades da DeepSeek, Moonshot e MiniMax de distillation attacks
  • Os termos comerciais estabelecem que clientes são donos das saídas, mas proíbem usar saídas do serviço para treinar modelos de IA concorrentes
  • Ao mesmo tempo, sua própria publicação reconhece a destilação como um método de treinamento legítimo e amplamente usado quando laboratórios líderes a aplicam a seus próprios modelos
• A Anthropic coletou dados públicos da web com robôs e cortou livros para escaneá-los para desenvolvimento de modelos, e a OpenAI também afirmou treinar com conteúdo público da internet livremente acessível e defendeu isso como fair use
• As duas empresas tratam a destilação internamente como um método comum ao criar modelos menores
  • A OpenAI também ofereceu seu próprio workflow de destilação via API para ajustar modelos OpenAI menores com saídas de modelos OpenAI fortes
• Há uma assimetria moral: exige-se que máquinas possam aprender com o vasto trabalho que humanos publicaram na internet, mas impede-se que outras máquinas aprendam com saídas produzidas por laboratórios
• A destilação pode transferir capacidades de modelos de fronteira caros para modelos menores, mais baratos e mais rápidos
  • Ela pode rodar em ambientes locais, offline, em hardware restrito ou sob controle do usuário
  • Aumenta a concorrência, preserva capacidades mesmo que uma API desapareça e reduz o uso de computação e energia em tarefas comuns

Liberdades mínimas que os usuários devem ter garantidas

• Usuários devem poder manter sessões e passá-las para outro modelo mesmo depois de encerrar a conta
• O novo modelo pode fazer julgamentos diferentes, fazer perguntas ou ter desempenho inferior, mas não deve receber apenas ciphertext no lugar do histórico, evidências, planos e tarefas delegadas que o modelo anterior viu
• O problema não é a API com preservação de estado em si, mas o acoplamento entre melhor desempenho e redução do controle do usuário
• O armazenamento no servidor deve ser opcional, ferramentas hospedadas devem ser observáveis, a compactação deve ser legível e a comunicação entre agentes deve ser auditável
• Mesmo na inferência privada, é necessário pelo menos um registro de handoff portátil, e a destilação deve ser um caminho para ampliar o acesso a capacidades, não um tabu que justifique barreiras mais altas

[GN⁺]

Comentários no Hacker News

• Este texto mostra que a situação já ficou séria mais rápido do que parece. É importante não ficar dependente de um ecossistema específico, porque só quando a liberdade é realmente exercida a relação com o fornecedor muda também
  Aceitei a contragosto o Codex, que esconde o processo de raciocínio por ter bom desempenho, mas a impossibilidade de auditoria já é um problema grande o bastante para me fazer repensar minha assinatura pessoal. Por isso também estou criando um app móvel para o OpenCode

  • Criei o https://www.agentkanban.io tendo em mente o problema de perder conversas valiosas de sessões com agentes. Ele salva o contexto nas tarefas do quadro e permite recarregá-lo depois em uma nova sessão de agente; atualmente oferece suporte ao Claude e ao Github CoPilot no VS Code
    O histórico de uso de ferramentas proprietárias foi excluído de propósito, porque quebra a portabilidade de sessão
  • Estou otimista de que dark patterns são apenas uma estratégia de vitória de curto prazo e, no longo prazo, serão superados por abordagens que respeitam o usuário e buscam o bem público. Diante da possibilidade de a tendência mudar rápido, talvez seja a hora de focar em modelos com pesos abertos e operação economicamente viável
  • Enquanto espero os preços caírem, pretendo coletar o máximo possível de dados de sessão do Claude e do Codex para usar depois no ajuste fino de modelos abertos. Para isso, também criei meu próprio parser de sessões e ferramentas de arquivamento
  • Cheguei a montar até 96GB de VRAM para rodar modelos locais, mas ainda não existe nada que chegue perto do Codex baseado em GPT. O Laguna S2.1 NVFP4 chegou bem perto em programação, mas ainda parece haver um longo caminho até que modelos locais se tornem uma alternativa séria de uso geral
  • https://indieweb.org/POSSE é a solução

• É um texto que organiza bem um problema que a maioria dos usuários de IA quase não avalia. Fornecedores de ponta de inferência empacotam recursos não-LLM como busca na web e execução de código como se fossem ferramentas simples, mas na prática isso forma forte barreira de entrada e acoplamento
  Em teoria, isso poderia ser separado da API de inferência e externalizado como servidor MCP, mas raramente os fornecedores oferecem isso dessa forma, e as funções dos concorrentes em geral são fracas. Ao criar a plataforma de chat on-premises e independente de fornecedor https://github.com/EratoLab/erato, até recursos que parecem simples, como geração de imagem dentro do chat, foram difíceis de implementar; um motivo é que o MCP ainda não tem uma especificação básica de transferência de arquivos: https://github.com/modelcontextprotocol/modelcontextprotocol...
  Com o interesse crescente em modelos com pesos abertos, espero que surjam mais implementações alternativas fáceis de substituir

  • Fazer agentes rodarem localmente sem que se possa inspecionar seus prompts de forma alguma, como mensagens criptografadas de subagentes, é fundamentalmente irresponsável. Ainda assim, não vejo problema no fato de o fornecedor oferecer ferramentas hospedadas em si, algo parecido com produtos de compra por impulso no caixa
    Geração de imagem não deve ser implementada com MCP; basta escrever uma ferramenta própria. Já existem fornecedores suficientes de inferência de imagem e mídia, como o Fal, além de fornecedores de busca na web e pesquisa aprofundada

• Talvez precisemos de um padrão aberto ou formato de arquivo para contexto. Fico imaginando se modelos abertos poderiam seguir o mesmo formato para garantir portabilidade, e se isso poderia ser feito com base em SQLite para também permitir consulta por outros programas

• Na prática, conversas costumam ter muito ruído, então muitas vezes é melhor removê-lo do contexto. Faço a IA registrar em arquivos Markdown, num diretório de memos do repositório, o que ela aprendeu, o que concluiu e o que ainda falta; depois, outro modelo assume a conversa seguinte
  Se necessário, também posso editar esses memos manualmente antes

  • É por isso que venho usando mais codificação com agentes. Eu defino a tarefa, exijo testes e passagem em lint rigoroso, e deixo passar o processo em que o modelo fala demais
    Basta ele voltar quando tiver passado em todas as verificações, então acabo sofrendo menos com conversas desnecessárias da interface de chat
  • Ao descartar a sessão, você perde funções de inspeção, exportação, reexecução e auditoria. Os grandes fornecedores de modelos não têm barreiras de entrada substanciais; OpenAI e Anthropic operam com margens fortemente negativas e também não têm o mesmo capital das big techs
    Portanto, os fornecedores estão tentando criar dependência artificialmente e isso é, em essência, caso para legislação antitruste. Mas nos EUA de hoje isso está sendo tolerado porque a FTC está enfraquecida
  • Ser capaz de trocar de modelo de forma fácil e sem perdas tornaria o mercado mais competitivo e a IA melhor e mais barata. Se a troca se torna dolorosa por causa da perda de parte do contexto, o fornecedor consegue criar lock-in de fornecedor, piorar a experiência do usuário e aumentar preços
    Mesmo que hoje existam contornos, já há incentivo suficiente para dificultar ainda mais a livre migração, então preocupa ver empresas de IA começando a lançar as bases para a degradação do serviço
  • Sessões longas frequentemente perdem o fio do progresso e, quanto mais prolixo o modelo, menor fica a relação sinal-ruído. O que tem valor não é o texto bruto da sessão, mas os resultados, como mudanças no código ou planos e resumos

• É preciso distinguir dois fenômenos. O primeiro é o aumento de estado oculto que o usuário não pode inspecionar nem mover, e isso é claramente ruim. O segundo é a divergência entre implementações de recursos e APIs por fornecedor; aí o problema não é a impossibilidade de portar, mas a dificuldade maior
  A era em que a OpenAI Completions API era usada como padrão universal está acabando e, excluindo as partes fechadas, a nova Responses API talvez seja melhor. Não é necessário que produtos, bibliotecas e SDKs continuem perseguindo uma abstração unificada que reúna todos os fornecedores em um só
  Assim como em bancos de dados a abstração unificada apresentou vazamentos e acabou aceitando implementações específicas de cada tecnologia, o mesmo deve acontecer com fornecedores de modelos; mesmo que só parte da sessão seja portável, isso já basta

  • Este texto está tratando apenas do estado oculto entre esses dois fenômenos

• Ainda está bruto, mas estou desenvolvendo o https://github.com/pantoniou/fyai, que preserva diretamente os dados de sessão e os gerencia com um modelo parecido com git

  • Com essa ferramenta não dá para resolver o problema tratado no texto, e pela estrutura dela isso também é impossível

• Faz sentido haver um contrato segundo o qual, mesmo ao encerrar a conta, você possa manter suas sessões e passá-las para outros modelos. Idealmente, também deveria ser fácil encontrar modelos com características de embedding parecidas
  Quando o GPT-4o original foi encerrado, houve quem carregasse conversas exportadas tentando reencontrar um velho amigo ao procurar um modelo com tom de fala e personalidade semelhantes, mas outros modelos da OpenAI não davam a mesma sensação. Modelos com pesos abertos têm a vantagem de poder ser preservados para sempre, de modo que um guia, amigo ou conselheiro não possa ser tirado unilateralmente por uma big tech

• Fico curioso sobre o que seria necessário para levar essa discussão além de um tema de blog do HN

• Os modelos atuais têm janela de contexto limitada, então em algum momento esquecem o conteúdo e, por isso, o valor da sessão não é tão alto. Se no futuro o próprio modelo realmente aprender e mudar com a interação, essa mudança não poderá ser portada para outro modelo, então não vejo esse problema como algo tão significativo

• Ler https://gwern.net/complement junto com este texto é um excelente material complementar

  • É preciso explicar por que isso é material complementar