Open WebUI 0.10.2: a independência dos modelos de fronteira acaba de ganhar uma nova versão, e todos precisamos de prestar atenção

Olá a todos!

Quem me lê aqui há algum tempo já sabe que eu bato nesta tecla até gastar o teclado: a dependência de modelos de fronteira proprietários não é só um problema técnico, é um problema estratégico, político e, em última análise, existencial para quem quer manter controlo sobre a sua própria infraestrutura de inteligência artificial. Escrevi sobre isso quando a Anthropic cortou o acesso aos seus modelos de topo para todos os estrangeiros do planeta sem aviso prévio. Escrevi sobre isso quando vos mostrei o LiteLLM, o MAESTRO, e cada vez que apareceu uma ferramenta que nos devolve o volante. E vou continuar a escrever, porque o problema não desapareceu. Ficou pior.

Mas hoje não venho cá falar de problemas. Venho falar de uma solução que acaba de dar um salto tão grande que merece que parem o que estão a fazer e prestem atenção. O Open WebUI lançou a versão 0.10.2 no dia 1 de Julho de 2026, a consolidação da nova linha 0.10.x, e o que está dentro desta release não é uma lista cosmética de ajustes de interface. É uma redefinição daquilo que é possível fazer com modelos locais, sem precisar de pedir licença a ninguém, sem enviar um único token para fora da vossa rede, e sem ficar à mercê de uma carta de controlo de exportação que chega a meio da tarde de uma quinta-feira. A vossa soberania digital.

Vamos a isto.

Primeiro, o contexto: porque é que o Open WebUI importa mais do que nunca

Para quem não conhece, o Open WebUI é uma interface web open source que serve de camada de interação com modelos de linguagem. Fala com o Ollama, fala com APIs compatíveis com o OpenAI, fala com praticamente tudo o que consiga responder a um pedido HTTP formatado correctamente. O projecto nasceu com a ambição de dar às pessoas uma alternativa self-hosted ao ChatGPT, e foi crescendo até se tornar, na minha opinião, a plataforma de referência para quem quer correr IA localmente com uma experiência de utilizador que não envergonha ninguém.

E é aqui que mora a diferença fundamental. Quando usam o ChatGPT, o Claude, ou o Gemini através das suas interfaces web, estão a entregar os vossos dados a uma empresa americana, sujeita a legislação americana, que pode ser obrigada a cortar-vos o acesso a qualquer momento. Já vimos isto acontecer. Não é teoria da conspiração. É facto documentado. Quando usam o Open WebUI a apontar para um modelo local servido pelo Ollama, os vossos dados ficam na vossa máquina, na vossa rede, sob as vossas regras. E a cada versão que passa, a distância entre aquilo que conseguem fazer localmente e aquilo que os serviços proprietários oferecem vai encolhendo.

A linha 0.10, que a versão 0.10.2 acaba de estabilizar, encolheu essa distância de uma forma que eu não estava à espera. E vou explicar porquê.

Compactação automática de contexto: conversas infinitas com modelos finitos

Uma das limitações mais frustrantes de trabalhar com modelos locais sempre foi a janela de contexto. Os modelos de fronteira como o Claude ou o GPT-5 têm janelas enormes, de centenas de milhares de tokens, e isso permite conversas longas e complexas sem perder o fio à meada. Os modelos locais, mesmo os bons, tendem a ter janelas mais modestas. E quando a conversa ultrapassa esse limite, ou o modelo começa a alucinar, ou pura e simplesmente rebenta.

A linha 0.10 resolve isto com uma funcionalidade que parece simples mas que muda completamente o jogo: compactação automática de contexto. Quando uma conversa ultrapassa um limiar de tokens configurável, o Open WebUI resume automaticamente a conversa anterior para que ela caiba dentro da janela do modelo. O utilizador recebe uma notificação a avisar que isto está a acontecer, e a conversa continua sem interrupção.

Para quem trabalha com modelos locais, isto é transformador. Significa que podem ter conversas longas e estruturadas com um Llama, um Mistral, ou um Qwen sem se preocuparem com o momento em que a conversa vai ultrapassar o limite e começar a degenerar. O administrador define o limiar, pode personalizar o prompt de sumarização, e pode até ajustar o limite por modelo. É exactamente o tipo de funcionalidade que os serviços proprietários fazem nos bastidores sem vos dizerem, e que agora podem fazer na vossa própria máquina com total transparência sobre o processo.

Pensem nisto: uma das razões pelas quais muita gente ainda se sente presa aos modelos de fronteira é a capacidade de manter conversas longas e densas. Essa desculpa acabou de cair.

Raciocínio em streaming: ver o modelo a pensar em directo

Esta é nova na 0.10.2 e chega na altura certa. Os modelos que emitem conteúdo de raciocínio, o chamado thinking, passam a mostrá-lo à medida que ele é gerado, em vez de o esconderem até ao fim da resposta. E esse conteúdo é renderizado correctamente na vista geral do chat e nas conversas exportadas.

Para quem corre modelos de raciocínio localmente, e cada vez somos mais, isto muda a experiência de forma tangível. Um DeepSeek-R1 ou um Qwen em modo thinking pode passar trinta ou quarenta segundos a mastigar um problema antes de responder. Até agora, esse tempo era um cursor a piscar e um acto de fé. Agora vêem o raciocínio a desenrolar-se em directo, o que não só torna a espera suportável como vos permite perceber quando o modelo está a ir por um caminho errado e vale a pena cancelar e reformular a pergunta.

Os serviços proprietários transformaram o “mostrar o raciocínio” em espectáculo de marketing. Aqui está ele, na vossa máquina, com modelos que ninguém vos pode desligar.

Open WebUI Computer: o vosso próprio agente de computador, sem cloud

Se há uma funcionalidade nesta linha que me fez levantar da cadeira, foi esta. O Open WebUI Computer é um sistema de agentes que permite que os vossos chats executem sessões completas na vossa máquina, com acesso a ficheiros, terminal, git e navegação web. Tudo isto através de um gateway compatível com a API do OpenAI, o que significa que qualquer modelo que já estejam a usar pode, em princípio, operar como um agente que interage com o vosso sistema operativo.

Leiam outra vez. O vosso modelo local, a correr na vossa máquina, a executar comandos no vosso terminal, a navegar na web, a manipular ficheiros, a interagir com repositórios git. Sem enviar nada para fora. Sem depender de nenhum serviço externo. Sem precisar de uma subscrição de 200 euros por mês num plano “Pro” de uma empresa californiana.

Isto é o tipo de funcionalidade que a Anthropic anda a promover com o Claude Code e que a OpenAI vende como parte da oferta premium dos seus agentes. A diferença é que aqui, corre tudo em vossa casa. O código está no GitHub, podem auditar cada linha, podem limitar o acesso como quiserem, e ninguém vos pode desligar o botão.

Para quem trabalha em ambientes onde a segurança e a privacidade não são opcionais, isto não é um brinquedo. É uma ferramenta de trabalho séria que acaba de ficar acessível sem compromissos.

Pesquisa híbrida nativa em bases de conhecimento grandes: RAG que finalmente escala

Quem já tentou montar um sistema de RAG (Retrieval-Augmented Generation) em casa sabe que a teoria é bonita e a prática é dolorosa. A partir de um certo volume de documentos, a pesquisa torna-se lenta, a memória explode, e o que devia ser uma ferramenta produtiva transforma-se num exercício de paciência.

A linha 0.10 resolve este problema de uma forma elegante. A pesquisa híbrida agora corre nativamente na base de dados, em setups com pgvector, em vez de carregar uma colecção inteira para memória. O efeito prático é que consultar bases de conhecimento grandes passou de “vou fazer um café enquanto espero” para “está feito”. Dramaticamente mais rápido, segundo as notas de lançamento. E quem conhece o projecto sabe que quando eles dizem “dramaticamente”, não estão a exagerar.

E a 0.10.2 acrescenta um detalhe que quem gere bases de conhecimento grandes vai agradecer: arrastar uma pasta para uma base de conhecimento, ou sincronizá-la, passa a recriar a estrutura de subpastas em vez de despejar tudo numa pilha de ficheiros soltos. Parece cosmético e não é. A estrutura de pastas carrega informação: um “manual.pdf” dentro de “produto-A/2024/” não é o mesmo documento que um “manual.pdf” dentro de “produto-B/arquivo/”. Quando a plataforma esmagava tudo para o mesmo nível, essa informação perdia-se.

Isto é importante porque uma das grandes promessas dos modelos de fronteira é a capacidade de processar grandes volumes de informação. Quando montam um sistema RAG local que funciona bem e escala, estão a replicar uma das funcionalidades mais valiosas dos serviços proprietários, mas com os vossos documentos a ficarem na vossa infraestrutura. Para empresas que lidam com informação sensível, como escritórios de advogados, clínicas, consultoras, ou departamentos de I&D, isto é a diferença entre poder adoptar IA local a sério ou continuar a olhar para ela como um brinquedo de fim de semana.

Bases de conhecimento externas: o RAG deixou de ser uma ilha

E por falar em bases de conhecimento, a linha 0.10 traz outra novidade que complementa perfeitamente a anterior: bases de conhecimento externas. O Open WebUI agora permite ligar fontes de recuperação externas configuráveis, o que significa que podem pesquisar um sistema existente directamente a partir do chat, em vez de dependerem exclusivamente do armazenamento interno do Open WebUI.

Traduzindo para linguagem humana: se já têm um Elasticsearch, um Weaviate, ou qualquer outro sistema de pesquisa vetorial a correr na vossa infraestrutura, podem ligá-lo ao Open WebUI e usar os vossos modelos locais para fazer perguntas contra essa base de dados. Sem duplicar dados, sem migrações dolorosas, sem reconstruir tudo do zero.

Isto transforma o Open WebUI numa camada de orquestração que se senta por cima da vossa infraestrutura existente, em vez de ser mais um silo isolado. E é exactamente isto que as equipas de operações precisam para levar a IA local a sério.

O novo sistema de memória: o modelo finalmente lembra-se de quem vocês são

Outra funcionalidade que sempre separou os modelos de fronteira das alternativas locais era a memória persistente. O ChatGPT lembra-se das vossas preferências, do vosso nome, do vosso estilo de escrita, e aplica isso a cada conversa. Os modelos locais, por definição, começam cada conversa do zero.

A linha 0.10 reformulou completamente o sistema de memória do Open WebUI. Agora existem tipos de memória distintos: memórias pessoais de longo prazo e contexto por conversa. Estas memórias são geridas através de um fluxo estruturado de adição, actualização e eliminação, o que dá aos modelos uma forma muito mais fiável de lembrar e aplicar aquilo que aprenderam sobre cada utilizador.

Na prática, isto significa que o vosso modelo local pode começar a conhecer-vos. Pode lembrar-se de que preferem respostas concisas, de que trabalham em Python e não em JavaScript, de que o vosso projecto se chama “Aurora” e envolve processamento de imagens médicas. E pode aplicar esse contexto de forma consistente, sem que tenham de repetir a mesma informação no início de cada conversa.

A 0.10.2 afina este sistema em dois pontos que mostram que a equipa está a ouvir quem o usa no dia-a-dia. Primeiro, os administradores ganharam um interruptor novo, o Memory System Context, que permite manter as ferramentas de memória disponíveis sem injectar automaticamente as memórias guardadas no contexto de sistema. O modelo pode consultar e gerir memórias quando faz sentido, mas elas não vão à boleia em todos os pedidos: menos tokens gastos, menos contexto poluído, mais controlo. Segundo, as memórias guardadas automaticamente ficaram mais criteriosas. Passam a concentrar-se em detalhes duradouros, como preferências e objectivos, e a ignorar trivialidades como o que almoçaram ou a disposição do momento, a menos que peçam explicitamente para guardar. Quem experimentou sistemas de memória automática sabe que o problema nunca foi lembrar. Foi lembrar lixo.

Mais uma vez, funcionalidade que antes só existia nos serviços proprietários, agora disponível em código aberto, a correr na vossa máquina, com os vossos dados a ficarem vossos.

Event Functions: a plataforma que se programa a si própria

Esta é para os mais técnicos, mas merece destaque porque altera fundamentalmente o que o Open WebUI pode ser. Até agora, os plugins do Open WebUI (pipe, filter, action) funcionavam todos dentro do contexto de uma conversa. A linha 0.10 introduz um novo tipo de primitiva: a Event Function.

Uma Event Function é código Python que corre em resposta a eventos emitidos pelo sistema inteiro: registos de utilizadores, alterações de configuração, uploads de ficheiros, mudanças de role, eliminações, arranque e encerramento do servidor, e por aí fora. Isto abre uma classe completamente nova de comportamentos que podem ser implementados directamente dentro do Open WebUI, desde onboarding automático e controlo de acessos até auditoria, automação de ciclo de vida e integrações externas.

Combinado com o novo sistema de eventos e webhooks, que permite enviar estes eventos para serviços externos, para utilizadores ou grupos específicos, e gerir tudo a partir de uma página de administração dedicada, o Open WebUI deixou de ser simplesmente uma interface de chat. Passou a ser uma plataforma extensível que pode ser adaptada a praticamente qualquer workflow empresarial.

E a 0.10.2 alimenta este sistema com mais uma fonte preciosa: os pedidos falhados a providers Ollama ou compatíveis com OpenAI passam a emitir um evento estruturado com o tipo de erro, o provider e o estado. Para quem gere uma instância para uma equipa, isto significa visibilidade real sobre falhas a montante, em vez do clássico “está lento, não sei porquê”. Podem agora construir fluxos automatizados sem sair da plataforma: quando um utilizador se regista, criar automaticamente um espaço de trabalho; quando um ficheiro é carregado, notificar o administrador; quando um provider falha, disparar um alerta. Tudo isto sem ferramentas externas, sem Zapier, sem n8n. Ou com eles, se preferirem, via webhooks.

Partilha de pastas: colaboração sem cloud

A colaboração sempre foi um dos pontos fortes dos serviços cloud proprietários. “Partilha este chat com a equipa” é trivial no ChatGPT Teams ou no Claude Enterprise. No Open WebUI, até agora, era complicado.

A linha 0.10 resolve isto de forma limpa. Podem agora partilhar uma pasta e os chats dentro dela com utilizadores específicos, grupos, ou toda a gente, com permissões de leitura ou escrita. As pessoas com quem partilham vêem as pastas partilhadas na sua barra lateral e abrem os chats numa vista de leitura quando não são os proprietários. Os administradores controlam quem pode partilhar pastas com uma nova permissão dedicada que vem desactivada por defeito.

Isto pode parecer uma funcionalidade menor, mas para equipas que trabalham juntas em projectos de IA, é fundamental. Significa que podem ter um espaço partilhado onde os prompts, as conversas de investigação, e as interacções com os modelos ficam disponíveis para toda a equipa, sem que nada saia da vossa infraestrutura.

Segurança: uma lista de correcções que mete respeito

Não vou listar todas as correcções de segurança, porque são dezenas ao longo da linha 0.10 e este post já vai longo. Mas quero destacar a seriedade com que estas releases trataram a segurança, porque é exactamente o tipo de coisa que distingue um projecto open source maduro de um brinquedo.

A linha 0.10 corrigiu vulnerabilidades de DNS rebinding no fetch de URLs, fechou caminhos de path traversal que podiam ser explorados através de URLs fortemente encodadas, endureceu o controlo de acessos em praticamente todos os endpoints da API, adicionou proteção contra timing attacks no login (o tempo de resposta já não revela se uma conta existe ou não), garantiu que sessões revogadas são rejeitadas em conexões WebSocket e de terminal, adicionou encriptação opcional para valores sensíveis guardados em ferramentas e funções, e introduziu suporte para hashing de passwords com Argon2.

A 0.10.2 continua o trabalho e traz o seu próprio aviso de segurança formal, com correcções de segurança e de controlo de acessos. Duas merecem destaque especial. As regras de permissão e bloqueio de domínios na pesquisa web passaram a ser validadas contra o host do URL, fechando uma brecha que permitia a alguns endereços escapar ao filtro. E os workflows de geração de imagens deixaram de ser escritos nos logs do servidor ao nível de log por omissão, o que significa que os prompts dos vossos utilizadores já não ficam à vista de quem opera a máquina. Privacidade não é só proteger os dados de terceiros lá fora. É também não os espalhar desnecessariamente cá dentro.

Há também uma nota explícita a dizer que nem todas as correcções de segurança estão listadas, para dar tempo aos administradores de actualizar antes que os detalhes se tornem públicos. Isto é comportamento de projecto que leva segurança a sério.

Para quem corre o Open WebUI num ambiente empresarial, esta release é uma actualização que devem fazer o mais rapidamente possível. E para quem ainda hesita em adoptar a plataforma por preocupações de segurança, esta lista de correcções é o tipo de evidência concreta que devem apresentar à vossa equipa de segurança.

Performance: morte à latência

Um dos problemas crónicos das interfaces de chat self-hosted é a performance. Quando a coisa funciona mas demora, a adopção cai porque as pessoas comparam com a experiência fluida do ChatGPT e decidem que não vale a pena.

A equipa do Open WebUI atacou isto de frente na linha 0.10. As melhorias de performance são tantas que é quase mais fácil dizer o que não foi optimizado. A renderização de Markdown agora só configura extensões uma vez em vez de em cada render. Blocos de código em modo de leitura saltam a detecção automática de linguagem. O carregamento de modelos de áudio já não bloqueia o servidor. As verificações de segurança de URLs deixaram de bloquear o loop principal. As reações e respostas em canais agora usam queries em batch. O streaming de respostas deixou de reprocessar conteúdo que não mudou. Os downloads de modelos grandes do Ollama já não bloqueiam o servidor. Os uploads e fetch de links agora correm fora do loop principal. Backends inacessíveis já não atrasam o carregamento da lista de modelos. E as actualizações de streaming agora agrupam pequenas actualizações do mesmo tipo antes de as enviar.

A soma de todas estas micro-optimizações resulta numa experiência perceptivelmente mais rápida e responsiva. E numa plataforma de chat, a responsividade é tudo. Ninguém quer esperar dois segundos a olhar para um cursor a piscar antes de o texto começar a aparecer.

Autenticação configurável pelo painel de administração

Outra funcionalidade que parecia menor mas que na prática era um obstáculo enorme para a adopção empresarial: as definições de LDAP e OAuth/OIDC agora podem ser configuradas directamente a partir do painel de administração, numa página dedicada de autenticação.

Para quem já tentou configurar LDAP no Open WebUI através de variáveis de ambiente num ficheiro docker-compose, sabe do que estou a falar. Cada alteração exigia reiniciar o container, rezar para que não houvesse um typo, e recomeçar o processo quando inevitavelmente havia. Agora fazem-no pela interface, com feedback imediato, e sem derrubar o serviço.

E para quem prefere o caminho inverso, o da infraestrutura declarativa, a 0.10.2 também dá cartas: as configurações por conexão do Ollama e de APIs OpenAI podem agora ser definidas através das variáveis de ambiente “OLLAMA_API_CONFIGS” e “OPENAI_API_CONFIGS”, e os modelos de arena para avaliação através de “EVALUATION_ARENA_MODELS”. Quem faz deploy por docker-compose, Ansible ou GitOps sabe o valor disto: a configuração vive no repositório, versionada, auditável, reproduzível.

Isto remove uma das últimas barreiras para integrar o Open WebUI em ambientes corporativos com directórios de utilizadores existentes. E quando combinado com as novas permissões granulares (controlo sobre importação de chats, webhooks por grupo, permissões separadas para importação e exportação de skills, e por aí fora), o Open WebUI passa a ter um modelo de governação que se aproxima daquilo que as plataformas empresariais proprietárias oferecem.

Tokenizer configurável para text splitting: um detalhe que faz toda a diferença

Esta é uma daquelas funcionalidades que só quem trabalhou com RAG a sério vai apreciar plenamente. O text splitting baseado em tokens agora permite usar um tokenizer configurável do Hugging Face, o que significa que o chunking dos documentos pode corresponder exactamente ao tokenizer do modelo que estão a usar.

Porquê que isto importa? Porque quando o tokenizer do splitting não corresponde ao tokenizer do modelo, os chunks resultantes podem cortar palavras ao meio, separar frases de formas estranhas, e degradar a qualidade da recuperação de informação. Com esta funcionalidade, os chunks ficam alinhados com a forma como o modelo realmente processa o texto, o que melhora directamente a qualidade das respostas em cenários de RAG.

É o tipo de detalhe técnico que ninguém nota quando está bem feito, mas que faz toda a diferença entre um RAG que “mais ou menos funciona” e um RAG que devolve resultados consistentemente bons.

Tool calling nativo como padrão: os modelos locais ganham mãos

Uma mudança subtil mas com consequências enormes: o tool calling nativo é agora o modo por defeito. Isto significa que todos os chats e modelos que não tinham escolhido explicitamente um modo de chamada de ferramentas passam a usar o suporte nativo do modelo, em vez do modo legacy que o Open WebUI implementava por cima.

Para quem trabalha com modelos locais que suportam function calling (e os bons modelos recentes todos suportam), isto significa que as ferramentas, os skills, e as integrações externas passam a funcionar de forma mais fiável e eficiente. O modelo decide quando e como chamar uma ferramenta, em vez de depender de heurísticas do lado da plataforma.

Combinado com a correcção que garante que chamadas de ferramentas paralelas funcionam correctamente na API compatível com Anthropic, e com a preservação do prompt caching nessa mesma API, o Open WebUI torna-se um proxy robusto não só para modelos locais mas também para cenários híbridos onde se usa uma combinação de modelos locais e APIs externas.

Pyodide agora corre em sandbox: código do lado do cliente com isolamento real

Uma mudança que merece atenção especial pela forma como equilibra funcionalidade com segurança: o Python do lado do cliente (Pyodide) agora corre dentro de uma iframe sandboxed com origem opaca. Isto significa que o código Python executado no browser fica isolado da vossa sessão, cookies, local storage, e dos endpoints da própria aplicação.

Isto é importante porque uma das formas mais comuns de explorar plataformas de chat com execução de código é injectar instruções que fazem o modelo gerar código malicioso que depois acede aos dados da sessão do utilizador. Com esta sandbox, mesmo que o modelo seja convencido a gerar código hostil, esse código não consegue aceder a nada de útil.

O Python completo, o JavaScript, e o acesso à rede continuam a funcionar normalmente. O que mudou é que código que tentasse aceder aos endpoints do Open WebUI a partir do Pyodide já não consegue. A 0.10.2 corrigiu ainda as falhas de arranque desta sandbox que andavam a partir a execução de código nas primeiras versões da linha, por isso o interpretador volta a carregar de forma fiável. E o Pyodide do lado do cliente foi marcado como legacy nas definições de administração, o que sugere que a equipa está a empurrar a execução de código para soluções mais robustas como o Open WebUI Computer que mencionei acima.

O polimento que se sente todos os dias

Como qualquer versão de consolidação, a 0.10.2 traz também um punhado de correcções que não dão títulos de artigo mas atacam irritações reais. Um único pedido a devolver erro de autorização já não vos atira para fora da sessão, porque a aplicação passou a confirmar o estado da sessão antes de redireccionar para o login. O modelo seleccionado deixa de desaparecer quando recarregam a página. Fechar um diálogo de ferramenta a clicar fora dele cancela o pedido pendente, em vez de deixar o chat a girar eternamente. Os utilizadores sem privilégios de administração voltaram a conseguir gravar as suas definições de interface. E as migrações de base de dados em SQLite, que nas primeiras versões da linha 0.10 podiam falhar a meio e bloquear o arranque, foram corrigidas.

Nenhuma destas correcções é glamorosa. Todas juntas dão aquilo que realmente importa numa ferramenta de trabalho: previsibilidade. E é por isso que digo que a 0.10.2, e não a 0.10.0, é a versão para a qual devem saltar.

O que isto tudo significa na prática

Vou ser directo, como costumo ser. A linha 0.10 do Open WebUI, agora estabilizada na versão 0.10.2, não é mais uma actualização incremental. É o momento em que a plataforma cruzou uma linha invisível e passou de “alternativa decente para entusiastas” a “plataforma séria que pode substituir serviços proprietários em contextos empresariais”.

Pensem no que esta versão oferece em conjunto: conversas longas sem limites artificiais, raciocínio visível em tempo real, um sistema de agentes que controla a vossa máquina, pesquisa RAG que escala, bases de conhecimento externas, memória persistente com controlo fino, um sistema de eventos e plugins extensível, colaboração de equipa, autenticação empresarial, segurança endurecida, e performance optimizada de ponta a ponta.

Isto não é uma lista de features. É a definição de uma plataforma completa de IA empresarial, open source, self-hosted, e sob o vosso controlo.

E é exactamente aqui que quero aterrar. Porque não é por acidente que esta release chega numa altura em que os riscos da dependência de modelos de fronteira proprietários nunca foram tão visíveis. Vimos governos a cortar acessos sem aviso. Vimos empresas a mudar preços e condições de um dia para o outro. Vimos dados de empresas europeias a serem processados sob jurisdição americana sem que os donos desses dados tenham qualquer recurso legal.

O Open WebUI 0.10.2 não vos obriga a abandonar os modelos de fronteira. Podem continuar a usar o Claude, o GPT, o Gemini através da plataforma se quiserem. Mas dá-vos algo que nenhum serviço proprietário pode dar: a opção de não depender deles. E quando o próximo corte acontecer, e vai acontecer, a diferença entre quem tem essa opção e quem não tem vai ser a diferença entre uma segunda-feira chata e uma segunda-feira catastrófica.

Como actualizar

Para quem já corre o Open WebUI, a actualização é o processo habitual. Atenção que a linha 0.10 inclui migrações de base de dados, por isso façam backup antes de actualizar. A reversão depois da migração não é suportada. A boa notícia para quem vem de versões anteriores é que, ao saltar directamente para a 0.10.2, apanham a migração já corrigida em vez de tropeçarem nos problemas que apanhou quem actualizou no primeiro dia da 0.10.0.

Revejam as definições de eventos e webhooks depois de actualizar, porque o novo sistema de eventos começa a emitir eventos automaticamente para uma série de actividades do sistema, incluindo agora as falhas de providers, e os webhooks que já tiverem configurados podem começar a receber chamadas para eventos que antes não existiam.

Notem também que o tool calling nativo é agora o padrão. Se os vossos modelos dependiam do modo legacy, vão ter de mudar explicitamente para esse modo por chat, por modelo, ou globalmente nos parâmetros por defeito.

Conclusão: a independência não se pede, constrói-se

Eu sei que muitos de vocês vão ler isto e pensar “sim, mas o Claude continua a ser melhor para X” ou “o GPT-5 ainda faz Y muito melhor”. E provavelmente têm razão, para agora. Os modelos de fronteira continuam a ser, em muitas tarefas, superiores aos melhores modelos que podem correr localmente.

Mas a distância está a diminuir todos os dias. E mais importante do que a qualidade do modelo é a qualidade da infraestrutura que vos rodeia. Um modelo ligeiramente inferior que corre na vossa máquina, com as vossas bases de conhecimento, com a vossa memória, com os vossos agentes, com a vossa segurança, e que ninguém vos pode tirar, vale infinitamente mais do que o melhor modelo do mundo que pode ser desligado por alguém que vocês nunca vão conhecer.

O Open WebUI 0.10.2 é mais um passo, e um passo grande, nessa direcção. Actualizem. Explorem. Construam sobre isto. A independência tecnológica não é um destino a que se chega de uma vez. É um caminho que se percorre com cada decisão, cada ferramenta, cada linha de código que escolhem correr sob o vosso tecto.

E se precisarem de ajuda para montar isto, sabem onde me encontrar.

Até à próxima.