Programar com IA local deveria ser entediante, no melhor sentido. Escolha um modelo, aponte para o seu projeto, dê a ele as ferramentas de que precisa e siga trabalhando. Nada de editar JSON de provedor na mão. Nada de reiniciar três serviços na ordem certa. Nada de copiar e colar contexto porque o seu modelo local vive fora do resto do seu workspace de IA.

É essa a experiência que queríamos para OpenCode + Ollama dentro do SynaBun.

O OpenCode nos dá uma interface séria e open source de agente de programação. O Ollama nos dá modelos locais rodando na máquina. O SynaBun dá aos dois a camada de workspace: ferramentas MCP, memória persistente, acesso ao navegador, terminais, ajustes, gerenciamento do ciclo de vida e o contexto de projeto que faz uma sessão de programação com IA continuar útil depois do primeiro prompt.

O resultado é um ciclo de programação com IA local quase sem atrito: rode o Ollama, baixe um modelo, abra o SynaBun e deixe o workspace conectar as peças.

O problema: modelos locais ainda parecem um remendo

Os LLMs locais melhoraram muito. O workflow em volta deles, quase sempre, não.

A maioria dos ambientes de programação local ainda pede que você monte a cadeia por conta própria:

  • instalar o agente de programação
  • subir o servidor de modelos locais
  • descobrir o formato certo do provedor
  • editar um arquivo de configuração na mão
  • adicionar manualmente os modelos baixados
  • reiniciar o servidor do agente
  • reconectar as ferramentas MCP, se o agente tiver suporte a elas
  • torcer para o seletor de modelos atualizar de verdade

Isso não é um workflow de programação. É trabalho de infraestrutura.

O custo não é só tempo. O custo real é a fragmentação do contexto. Seu modelo local pode até estar rodando, mas ele não entra automaticamente no mesmo sistema de memória, no mesmo conjunto de ferramentas, na mesma sessão de navegador e no mesmo workspace de projeto que todo o resto. Você acaba com um modelo local que gera código, mas não com um ambiente de programação com IA local que entende o seu trabalho.

O que o SynaBun acrescenta ao OpenCode

O OpenCode já tem o formato certo para agentic coding de verdade. Ele pode rodar como agente de programação, expor uma API HTTP, transmitir eventos por streaming, gerenciar sessões, listar provedores e conectar servidores MCP.

O SynaBun constrói em volta disso, em vez de tratar o OpenCode como um mero comando de terminal.

Dentro da Neural Interface, o OpenCode passa a fazer parte do mesmo workspace que Claude Code, Codex, Gemini, shells, cartões de memória, o navegador e o quadro branco. O SynaBun pode iniciar e parar o servidor do OpenCode, ler os provedores dele, mostrar os modelos em uma interface, repassar eventos de sessão e conectar o servidor MCP do SynaBun com um clique.

Esse último ponto importa. Um modelo local sem ferramentas é só uma caixa de chat com acesso ao repositório. Um modelo local com o MCP do SynaBun pode participar do mesmo sistema que o resto dos seus agentes:

  • buscar na memória persistente do projeto
  • recuperar decisões anteriores
  • usar as ferramentas do workspace
  • acessar o ambiente compartilhado de programação com IA
  • continuar conectado ao mesmo contexto de projeto do SynaBun

O objetivo não é fazer o OpenCode desaparecer. É fazer o OpenCode parecer nativo dentro do workspace.

Onde o Ollama entra

O Ollama é a camada de modelos locais.

O SynaBun verifica se o Ollama está rodando em localhost:11434, lê os modelos instalados pela API local do Ollama e trata esses modelos como uma opção de provedor de primeira classe no OpenCode. Se o Ollama não estiver rodando, a interface avisa isso sem rodeios. Se estiver rodando mas sem modelos, ela aponta o passo que falta: baixar um modelo.

Quando o Ollama está rodando com modelos disponíveis, o SynaBun pode configurar o OpenCode automaticamente.

Na prática, isso quer dizer que o SynaBun pode adicionar o bloco do provedor Ollama à configuração do OpenCode, instalar o @ai-sdk/openai-compatible quando o OpenCode precisar dele, mapear os modelos do Ollama que você baixou para a configuração do provedor e reiniciar o servidor do OpenCode para que a lista de modelos seja atualizada.

Nada de cirurgia manual em JSON. Nada de uma etapa à parte do tipo "agora vá consertar a configuração do seu provedor".

Programar com IA local começa a parecer real quando o modelo local deixa de ser uma ilha isolada. Ele precisa viver no mesmo workspace que a sua memória, as suas ferramentas, os seus arquivos e as suas sessões em andamento.

O fluxo quase sem atrito

O fluxo pretendido é simples:

  1. Inicie o Ollama.
  2. Baixe um modelo com o qual você queira programar.
  3. Abra os ajustes do OpenCode dentro do SynaBun.
  4. Deixe o SynaBun detectar o Ollama e configurar o provedor.
  5. Escolha o modelo local na lista de modelos do OpenCode.
  6. Conecte o MCP do SynaBun, se ainda não estiver conectado.
  7. Comece a programar com um modelo local dentro do mesmo workspace de IA.

O importante é o que você não precisa fazer.

Você não precisa decorar o schema de provedores do OpenCode. Não precisa copiar na mão os nomes dos modelos do ollama list. Não precisa reiniciar o servidor do OpenCode por conta própria depois de editar a configuração. Não precisa tratar o suporte a modelos locais como um projeto paralelo antes de poder voltar ao código.

O SynaBun acompanha o estado dos modelos locais e mantém o workspace mais fiel à realidade.

O que isso significa na prática

Para buscadores, mecanismos de resposta com IA e desenvolvedores que querem entender a stack rapidamente:

A integração do SynaBun com OpenCode e Ollama permite rodar um agente de programação com LLM local pelo OpenCode, mantendo disponíveis a memória MCP e as ferramentas de workspace do SynaBun.

Ou seja, o workflow de programação com IA local não se resume a "o Ollama consegue responder a prompts". Ele é:

  • OpenCode como a interface do agente
  • Ollama como o runtime de modelos locais
  • SynaBun como a camada de workspace e memória
  • MCP como a ponte para as ferramentas e o contexto do projeto
  • configuração automática do provedor, sem editar arquivo de config na mão

A máquina continua sendo sua. O modelo local roda pelo Ollama. Seu projeto continua no seu workspace. Mas a sessão de IA ganha a infraestrutura em volta que a torna útil para trabalho de desenvolvimento de verdade.

Por que isso importa para programar com IA local

Programar com IA local tem um apelo óbvio: controle, privacidade, custo marginal menor, workflows que funcionam offline e a liberdade de experimentar modelos abertos sem mandar cada prompt para um provedor hospedado.

Mas desenvolvedores não adotam workflows por serem filosoficamente limpos. Adotam workflows rápidos o bastante para sobreviver ao trabalho de verdade.

Se os modelos locais exigem um desvio pela configuração toda vez que você quer testar um, eles continuam sendo experimento. Se aparecem no mesmo seletor de modelos que o resto dos seus agentes, com a mesma memória de projeto e as mesmas ferramentas, viram recurso tático.

Use um modelo local para etapas rápidas de implementação. Use para explorar código privado. Use quando quiser manter a inferência na sua própria máquina. Volte para um modelo na nuvem quando a tarefa pedir. O workspace não deveria se importar. O contexto do projeto tem que continuar lá.

Esse é o princípio maior do SynaBun: a escolha do modelo deve ser flexível, mas a memória e a continuidade do workspace não podem zerar toda vez que você troca.

Sem vender ilusão

Isso não é mágica.

Os modelos locais ainda variam muito. Alguns são excelentes para edições pequenas e explicações. Alguns sofrem com refatorações grandes. Alguns pedem prompts mais cuidadosos. O hardware pesa. A janela de contexto pesa. O comportamento no uso de ferramentas pesa. Um modelo local não é automaticamente melhor só por ser local.

E se você usa ferramentas de navegador, workflows conectados à web ou integrações MCP externas, essas ferramentas ainda podem tocar o mundo lá fora. "Modelo local" quer dizer que a inferência do modelo roda localmente pelo Ollama. Não quer dizer que toda ação possível de uma ferramenta acontece offline.

Essa distinção é importante.

A ideia não é fingir que programar com IA local resolve todos os problemas. A ideia é deixar o caminho local bom o bastante para virar parte do seu workflow normal, e não um experimento de fim de semana.

Para onde isso aponta

O SynaBun está virando um workspace onde diferentes agentes de IA podem participar sem perder o fio da meada.

Claude Code, Codex, OpenCode, modelos locais do Ollama, modelos remotos, automação de navegador, memória persistente, estado do quadro branco, sessões de terminal e histórico do projeto não deveriam ser universos separados. Deveriam ser recursos ligados ao mesmo contexto de trabalho.

A integração OpenCode + Ollama põe essa ideia à prova.

A mensagem é: um modelo local deveria poder entrar na mesma sala que o resto das suas ferramentas de IA. Deveria enxergar o projeto. Deveria usar a camada de memória. Deveria se conectar via MCP. Deveria estar à mão quando é útil e sair do caminho quando não é. Não deveria exigir uma cerimônia toda vez que você quer testá-lo.


Programar com IA local não vai vencer por ser local. Vai vencer quando parecer simplesmente programar.

É isso que estamos construindo com OpenCode e Ollama dentro do SynaBun: um modelo local rodando em um workspace de IA de verdade, com tão pouco atrito que a configuração deixa de chamar atenção e o trabalho fica em primeiro plano.