O SynaBun foi construído conversando com o Claude. Essa parte é óbvia. Os hooks, os workflows, as histórias de guerra deste blog, todo o formato do produto até aqui. O Claude foi a IA que esteve na sala com a gente enquanto a maior parte deste sistema era construída.
Mas o SynaBun nunca foi feito para pertencer a um único modelo.
A ideia central do SynaBun é que a sua IA precisa de infraestrutura: memória que sobrevive, um navegador que continua logado, um quadro branco onde ela pode desenhar, um workspace que ela pode compartilhar e um registro do que aconteceu antes. Essa ideia é maior do que qualquer CLI.
Por isso estamos trazendo o Codex para o ecossistema do SynaBun.
Por que o Codex faz sentido aqui
Um workspace de IA fica mais útil quando para de presumir que só existe um cérebro válido ligado a ele.
Modelos diferentes são bons em coisas diferentes. Um é melhor em raciocínio de arquitetura. Outro é mais rápido na implementação. Um dá a resposta que você queria. Outro dá a resposta de que você realmente precisava. Se o seu workspace só funciona bem com um deles, o gargalo é o workspace.
O SynaBun deve ser o oposto disso. Deve ser a camada que torna boas ferramentas de IA mais úteis com o tempo, não a camada que obriga você a escolher um favorito para sempre.
O Codex se encaixa nessa direção naturalmente. É mais um agente de programação sério, com seu próprio workflow, seus próprios pontos fortes e seu próprio jeito de operar em uma base de código real. Não queremos o Codex do lado de fora do circuito do SynaBun. Queremos o Codex dentro do mesmo sistema de memória, do mesmo ambiente de projeto e do mesmo ambiente colaborativo.
Não se trata de substituir o Claude
O Claude não vai a lugar nenhum. Este não é um post de migração. É um post de expansão.
O objetivo não é "troque o Claude pelo Codex". O objetivo é "pare de tratar sessões de IA como ilhas isoladas".
Hoje, a maioria dos workflows de IA ainda está presa em silos de ferramentas. Você começa em um assistente, acumula contexto, toma decisões, mexe em arquivos, talvez guarde algumas anotações, e aí, se quiser envolver outro modelo, basicamente começa de novo. Mesmo quando os arquivos são compartilhados, a sessão não é. A cadeia de raciocínio não é. O ritmo não é.
Esse é o problema de verdade.
O problema: arquivos compartilhados, sessões fragmentadas
Um repositório compartilhado não é a mesma coisa que uma sessão de trabalho compartilhada.
Você pode ter o Claude e o Codex apontados para a mesma base de código e ainda assim perder um tempo absurdo explicando tudo de novo:
- qual é a tarefa de fato
- o que já foi tentado
- quais arquivos importam
- quais decisões são provisórias
- quais decisões estão fechadas
- qual é o bloqueio atual
- se o último agente estava planejando, depurando ou no meio de uma correção
Isso é atrito. E ele se acumula.
O SynaBun já resolve parte disso com memória persistente, workspaces compartilhados e sessões de terminal vinculadas. Mas o passo maior é tornar a própria sessão portável o bastante para que uma IA passe o trabalho para outra sem que você tenha que resumir tudo manualmente.
O objetivo não é fazer o Codex se comportar como o Claude, nem o Claude como o Codex. O objetivo é deixar os dois participarem da mesma sequência de trabalho de longa duração.
O que sessões compatíveis entre ferramentas significam na prática
Não estamos fingindo que o Claude e o Codex usam o mesmo protocolo nativo. Não usam. As ferramentas, os formatos e a semântica de sessão de cada um são diferentes.
Então compatibilidade entre ferramentas não significa uniformidade de fachada. Significa construir uma camada compartilhada de transferência de trabalho acima deles.
Em termos práticos, isso quer dizer que uma sessão do SynaBun deve conseguir levar de um modelo para outro as partes do trabalho que realmente importam:
- o projeto e os arquivos ativos
- o conjunto de memórias relevantes
- o resumo da tarefa e o objetivo atual
- as decisões recentes e as questões em aberto
- as saídas importantes das ferramentas
- o estado do workspace de que o próximo agente precisa para continuar
Comece no Claude. Passe para o Codex. Continue no mesmo workspace sem reescrever a história inteira do zero. Ou faça o contrário. Use o Codex para acelerar a implementação e depois traga o Claude de volta para revisão, planejamento ou limpeza.
Mesmo projeto. Mesma memória. Mesma sequência de trabalho. Outra IA.
Por que isso importa
Quando as sessões se tornam portáveis, a escolha do modelo passa a ser tática, não permanente.
Isso muda o formato do desenvolvimento com IA.
Você pode usar o modelo que é melhor para a fase em que está, em vez do modelo com que por acaso começou. As equipes podem manter o agente que preferem sem quebrar a colaboração. Os workspaces compartilhados passam a ser multiagente de verdade, não apenas multiterminal.
Isso também torna o SynaBun mais honesto como produto. Já acreditamos que a camada de infraestrutura importa mais do que a caixa de chat. Memória, estado do navegador, visibilidade do workspace e continuidade ao longo do tempo são as partes que duram. Se essa crença é para valer, o sistema deve funcionar com mais de um agente de programação sério.
O Codex é o próximo teste óbvio desse princípio.
O que vamos construir primeiro
Vamos fazer isso em fases.
Primeiro: o Codex se torna um participante de verdade no workspace do SynaBun.
Depois: fluxos explícitos de transferência de trabalho entre o Claude e o Codex, em que uma sessão pode empacotar o estado atual do trabalho para a outra.
Em seguida: uma compatibilidade de retomada mais profunda, em que a transferência não é só um resumo, mas uma camada estruturada de continuação, construída a partir de memória, artefatos, estado dos arquivos e rastros da sessão.
Essa é a direção. Não uma IA para governar o workspace. Um workspace que coordena várias IAs sem apagar o contexto a cada troca.
O SynaBun começou como um jeito de fazer a IA parar de esquecer. O próximo passo é impedir que as sessões fiquem presas dentro do modelo que as criou.
O Codex está chegando ao ecossistema. O Claude fica. A parte interessante é o que acontece quando os dois podem trabalhar na mesma sequência de trabalho sem começar do zero.