Como o Talorys roda agentes de IA com estado no serverless

Aqui vai minha opinião contrária, e vou defendê-la: um agente de IA pessoal se encaixa melhor na infraestrutura serverless do que no Raspberry Pi embaixo da sua mesa. O projeto Talorys — um assistente pessoal de código aberto que é implantado na sua própria conta Cloudflare com um único npx create-talorys@latest — é a melhor evidência até agora de que o problema de agentes de IA com estado em serverless sem estado não é apenas solucionável, mas um encaixe natural. E a galera do Hacker News discutindo se isso conta como “autohospedado” está tendo a discussão errada por completo.

Passei anos rodando infraestrutura e limpando a bagunça que ela deixa. O que mata software pessoal autohospedado não é o deploy — é o terceiro mês, quando o disco enche de logs, o certificado TLS expira e você não lembra qual unit do systemd cuida do agendamento. O Talorys contorna toda essa classe de falhas simplesmente não tendo servidor nenhum. Tudo o que ele precisa — chat, memória, tarefas, lembretes agendados — roda no plano gratuito da Cloudflare: Pages para o frontend, um Worker privado para a API, um Durable Object com SQLite para todo o estado e o Workers AI para o modelo. Custo mensal total para um único usuário: zero.

O Problema Real: Agentes têm Estado, Serverless Não

Um agente de IA é um conjunto de estado de longa duração fingindo ser uma aplicação de requisição e resposta. Ele precisa de histórico de conversa, memórias duráveis, uma lista de tarefas, jobs agendados que disparam às 7h, esteja alguém logado ou não, e algum lugar para guardar as saídas de ferramentas enquanto uma cadeia de múltiplos passos roda. Cada uma dessas peças é hostil ao modelo serverless clássico, onde sua função é um peixinho dourado: acorda, atende uma requisição e esquece tudo.

A resposta padrão da indústria é remontar o estado nas bordas: Redis para dados de sessão, Postgres para registros duráveis, uma fila mais um agendador para cron, um banco vetorial para recuperação semântica. Funciona, mas você acabou de reconstruir uma fazenda de servidores com serviços gerenciados, com a conta e a superfície operacional correspondentes. Já vi times gastarem mais tempo de engenharia conectando cinco serviços com estado para um agente do que escrevendo a lógica do agente em si. Como já argumentei antes, agentes de LLM são apenas sistemas distribuídos — e sistemas distribuídos são onde as boas intenções vão morrer.

O Talorys faz a aposta oposta: colocar todo o estado em exatamente um lugar. Um único Durable Object, chamado personal-agent, guarda o mundo inteiro — conversas, memórias, tarefas, notas, projetos, automações, sessões, configurações e rastreamento de uso — no seu banco SQLite embutido. Nada de KV, D1, R2 ou Vectorize. O README deixa explícito que nenhum deles é provisionado. Isso não é acidente; é a arquitetura.

Durable Objects são o atalho secreto

Durable Objects são a primitiva mais discretamente radical da computação em nuvem hoje, e não acho que isso seja exagero. Um Durable Object é um pedaço de código de instância única, com armazenamento transacional e fortemente consistente, fisicamente colocado junto dele. Quando chega uma requisição endereçada ao objeto personal-agent, a Cloudflare acorda esse objeto — em milissegundos, a partir do zero —, roda seu código sobre o SQLite local e o congela de novo quando fica ocioso. Você tem a ergonomia de um processo de servidor de longa duração com o modelo de cobrança de um Lambda.

Para um agente pessoal de usuário único, as limitações famosas desse modelo viram virtudes:

• Escritor único é um recurso. Um usuário significa um escritor. Todo o horror de concorrência de estado multi-tenant desaparece; você ganha acesso serializado e transacional a tudo de graça.
• Colocalização mata a latência. As consultas de memória do agente, buscas de tarefas e histórico de conversa são leituras SQLite no disco local, e não viagens de ida e volta de rede até um banco em outra zona de disponibilidade.
• Alarmes substituem o cron. Os alarmes de Durable Objects permitem que o objeto agende os próprios despertares. Lembretes, rotinas recorrentes e resumos diários disparam sem nenhuma máquina ficar online — o objeto dorme, o alarme o acorda, ele faz o trabalho e volta a dormir.
• Hibernação é grátis. Tempo ocioso não custa nada. Um assistente pessoal que fica ocioso 23 horas por dia é exatamente a carga de trabalho para a qual o preço serverless foi inventado.

Essa é a ideia que eu gostaria que mais gente levasse deste projeto. Se sua aplicação é naturalmente de usuário único — uma ferramenta pessoal, um workspace por cliente, um coordenador por dispositivo —, o padrão “um Durable Object por tenant” oferece algo que antes exigia um VPS: um pequeno computador que conceitualmente está sempre rodando, não custa nada quando ocioso e nunca precisa de um sysadmin. Só a história do agendamento já vale o ingresso. Quem já teve uma caixinha pessoal com cron conhece o modo de falha: a máquina reinicia, o daemon do cron não volta, e você descobre duas semanas depois que seus lembretes pararam silenciosamente. Alarmes são agendamento gerenciado pela própria infraestrutura, e isso é uma coisa a menos para vigiar.

O Modelo de Rede é Melhor que a Maioria dos Setups de Produção

Aqui está a parte que me fez sentar direito, vindo de um background de segurança. O Worker do agente no Talorys é implantado com workers_dev: false e preview_urls: false. Ele não tem URL pública nenhuma. O navegador só fala com um site *.pages.dev; uma Pages Function em /api/* encaminha as requisições para o Worker por meio de um service binding — a fiação interna e privada da Cloudflare entre computações da mesma conta. Autenticação e autorização acontecem no Worker, não no frontend.

Pense no que isso elimina. Nenhum endpoint de API público para escanear. Nenhuma regra de firewall para configurar errado. Nenhum reverse proxy para esquecer de atualizar. A superfície de ataque do backend do agente é, na prática, “você precisa passar pelo fluxo de autenticação do frontend”. Já revisei deployments de produção em empresas de verdade — com orçamento e time de segurança — que tinham uma postura de rede mais frouxa que esse projeto paralelo. O padrão de incidente mais comum que vi em ambientes de nuvem foi um serviço interno que era “acessível apenas internamente” até o dia em que não era mais, porque alguém errou a configuração de um load balancer. Você não consegue errar um service binding a ponto de torná-lo público; a URL simplesmente não existe.

O instalador também merece menção. Ele gera o hash da senha do dono localmente com PBKDF2-SHA256 e guarda apenas o hash como secret da Cloudflare, gera um segredo de sessão de 256 bits, dá nomes únicos aos recursos e então verifica o deployment ao vivo — inclusive checando se requisições não autenticadas são de fato rejeitadas — sem gastar nenhuma cota de inferência de IA. Uma verificação pós-deploy que confirma que a autenticação realmente nega acesso a quem não está autenticado é o tipo de coisa que já escrevi em postmortems de incidentes. Ver isso num instalador de um único comando é uma surpresa agradável.

Viver no Plano Gratuito Sem Se Enganar

O plano gratuito é real, mas é um orçamento, não um bufê livre. A Cloudflare dá às contas gratuitas uma cota diária do Workers AI medida em “Neurons” — 10.000 por dia — além de cotas de requisições e de uso de Durable Objects. Esses números são definidos pela Cloudflare e podem mudar. O Talorys lida com isso de forma mais honesta do que a maioria dos projetos “gratuitos” que já vi: quando a cota de IA acaba, o chat avisa claramente e volta após o reset diário, enquanto tarefas, notas, memórias e lembretes continuam funcionando, porque nenhum deles precisa do modelo.

As salvaguardas valem a pena ser copiadas nos seus próprios projetos. O Talorys traz limites configuráveis para máximo de tokens de saída, máximo de tokens de contexto (históricos mais antigos são resumidos em vez de cortados silenciosamente), máximo de chamadas de ferramentas e passos de raciocínio por requisição, máximo de requisições de IA por dia e máximo de execuções agendadas com IA por dia. Isso é uma postura madura. Loops de agente sem limite são como você acorda com uma conta alta ou com um outage por cota, e “o agente decidiu chamar a ferramenta 40 vezes” é um modo de falha que já vi queimar dinheiro de verdade em produção. Relacionado: a decisão do projeto de fazer com que lembretes simples e resumos nunca usem IA está exatamente certa. Se um caminho de código é determinístico, não o roteie por um modelo probabilístico. É a mesma disciplina por trás de restringir a saída do modelo a decisões estruturadas — use o modelo apenas onde o julgamento é realmente necessário.

Uma ressalva de guerra vinda da comunidade: várias pessoas relatam surpresas de cobrança opacas ao combinar o Workers AI com planos pagos do Workers, com a contabilidade de Neurons não batendo com os limites documentados e tickets de suporte sem resposta. Não consigo verificar os detalhes, mas isso combina com um padrão que conheço bem — cobrança medida de IA é confusa em todo lugar, e “amigável ao plano gratuito” não é o mesmo que “impossível de ser cobrado”. Se você implantar isso num plano pago, configure um alerta de gasto no painel da Cloudflare já no primeiro dia. Trate a interface de uso do provedor como fonte da verdade, e não as estimativas locais do app.

A Briga do “Autohospedado” Erra o Ponto

Agora, a concessão que minha afirmação inicial exige. Os comentários mais votados sobre esse projeto são uma guerra de chamas sobre a palavra “autohospedado”, e os pedantes têm um ponto real: isso depende inteiramente da Cloudflare. Seus dados ficam nos data centers deles, sua inferência roda nas GPUs deles, e se eles mudarem o plano gratuito amanhã, seu assistente muda junto. Chamar isso de autohospedagem estica a palavra até ela quebrar. A leitura caridosa — nenhum terceiro além de uma conta Cloudflare que você já controla, nenhuma telemetria para os desenvolvedores, nenhum operador no meio — é melhor descrita como “autoproprietário” ou “autocustodiado”. Palavras importam, e o projeto levaria menos porrada com termos melhores.

Mas aqui é onde os pedantes me perdem. O modelo de ameaça real para software pessoal não é “os termos de serviço de uma corporação podem mudar”. É exfiltração de dados, telemetria e o desenvolvedor indo à falência e desligando a versão hospedada. Nos três pontos, o Talorys é genuinamente forte: não há código de analytics ou rastreamento, nada manda dados para os autores, e não existe versão hospedada para desligar. Além disso, o código é licenciado sob MIT, e, como um comentarista observou, apontar as chamadas de IA para um servidor de modelo local é um pequeno patch — a stack inteira até roda localmente com wrangler dev usando um provedor de IA simulado. Se a Cloudflare um dia se tornar inaceitável, a saída é curta. Compare isso com o “autohospedado” médio, que na prática é um arquivo Docker Compose puxando imagens do registry de alguém e fazendo checagens de licença por trás dos panos.

Também há uma crítica mais justa enterrada na thread: não há evidência de que o assistente seja de fato bom. Uma interface de chat, CRUD de memória, embeddings e cron são cada um trivial de construir; o harness, o prompting, a política de recuperação de memória e os schemas de ferramentas é onde assistentes pessoais vivem ou morrem, e nada disso é demonstrado por um diagrama de arquitetura limpo. Isso vale para quase todo projeto desse gênero, e é justamente o que vale ser cético. Avalie o Talorys como infraestrutura — um chassi bem projetado — e não como um copiloto comprovado. Se você está avaliando modelos para algo assim, nosso texto sobre rodar LLMs no seu próprio hardware cobre a outra ponta do espectro de soberania.

O Que Você Deveria Copiar Deste Design

Mesmo que você nunca implante o Talorys, a arquitetura é uma referência que vale internalizar. As ideias transferíveis:

1. Um objeto por tenant. Se sua aplicação é de usuário único ou pode ser particionada de forma limpa, coloque código e estado juntos em um Durable Object e elimine sua camada de cache, sua fila de mensagens e seu connection pooler.
2. Nenhuma URL pública de backend. Service bindings com workers_dev: false são a vitória de segurança mais barata do serverless. Um serviço que não pode ser alcançado não pode ser atacado.
3. Alarmes no lugar de caixas de cron. Agendamento que vive junto da infraestrutura sobrevive a reinicializações, redeploys e à sua própria desatenção.
4. Degradação consciente de cota. Projete a aplicação para que a dependência cara (o modelo) possa falhar ou esgotar enquanto o produto principal continua funcionando. Degradação deve ser um recurso, não um outage.
5. Migrações somente de adição. O namespace do Durable Object nunca é recriado numa atualização; migrações de schema rodam de forma transacional na primeira requisição. É assim que você atualiza serverless com estado sem roleta de perda de dados.

A lição mais ampla é sobre para onde o software pessoal está indo. Por vinte anos, a escolha foi binária: confiar seus dados a uma empresa SaaS ou virar um sysadmin de meio período. Durable Objects — e as primitivas copiadas que outras nuvens inevitavelmente vão lançar — abrem um terceiro caminho: software que só você controla, operado por uma infraestrutura que você aluga, custando zero na escala pessoal. Não é autohospedagem. Pode ser melhor.