No fim de setembro de 2026 apareceu no GitHub o Talorys, um projeto open source (MIT) que se descreve como um agente pessoal de IA, single-user, que roda inteiro dentro da sua própria conta Cloudflare e cabe no free tier. O deploy é um comando: npx create-talorys@latest. O repositório é mantido por rociiu e está em github.com/rociiu/talorys.
O que faz o projeto interessante não é a lista de features (chat, memória, tarefas, notas, lembretes agendados). Isso qualquer agente tem. O interessante é a arquitetura: tudo, inclusive banco de dados e scheduler, mora dentro de um único Durable Object com SQLite embutido. Zero servidor próprio, zero banco externo, zero telemetria. Vale entender como isso funciona por baixo, porque é um padrão novo e dá para reaproveitar em projeto próprio.
Como o Talorys funciona por baixo do capô
O fluxo tem três camadas, e cada uma mora em um lugar específico da Cloudflare:
Browser
│ HTTPS
▼
Cloudflare Pages (React + /api Pages Function)
│ service binding (sem URL pública)
▼
Worker privado (Hono router)
│ getAgentByName("personal-agent")
▼
TalorysAgent (Durable Object com SQLite)
├─ tabelas: conversations, memories, tasks, notes, projects, automations, sessions, settings, usage
├─ Workers AI: @cf/zai-org/glm-4.7-flash (streaming + tool calling)
└─ Alarms: lembretes e schedules recorrentesO ponto chave é o Durable Object. Antes de entrar nele, uma analogia que carrega a mecânica, não só o nome.
Pense num escritório que fecha a chave quando ninguém está dentro
Imagine um escritório pequeno com uma única mesa, um fichário trancado e um despertador. Quando ninguém entra, as luzes se apagam, ninguém está pagando aluguel. Quando chega uma carta, uma ligação ou toca o despertador, alguém acende a luz, abre o fichário, atende, anota, e sai. O fichário continua ali, com tudo que foi escrito antes. É o mesmo escritório sempre, com o mesmo fichário, com o mesmo despertador configurado.
Durable Object é esse escritório. O Agents SDK é construído em cima de Durable Objects para dar a cada agente uma identidade, estado persistente e a capacidade de acordar quando chega uma mensagem. Cada agente é uma entidade endereçável com seu próprio banco SQLite. Consome zero compute quando está hibernado. Quando algo acontece (uma request HTTP, uma mensagem WebSocket, um alarme agendado, um email), a plataforma acorda o agente, carrega o estado e entrega o evento. O agente faz o trabalho e volta a dormir. O limite da analogia: no escritório físico você precisa de alguém para abrir a porta. No Durable Object, a própria Cloudflare instancia o objeto sob demanda. Não existe equivalente a atraso humano, é milissegundos.
O SQLite mora dentro do agente, não ao lado
Essa é a parte que mais foge do padrão clássico (app em um lugar, banco em outro). Como o storage fica colocalizado com o Durable Object, as queries têm latência efetivamente zero. O SQLite roda não só no mesmo data center, mas na mesma thread do compute do Durable Object. As queries são síncronas, porque executam tão rapidamente que não há motivo para serem assíncronas.
Em números: comparado ao storage key-value, os limites são bem maiores em SQLite-backed Durable Objects. Dá para armazenar até 10GB por Durable Object, sem limite de dados agregados por conta (nota: o plano free limita a 5GB). Para um agente pessoal single-user isso é mais do que suficiente por anos.
Service binding: o Worker do agente não tem URL pública
No modelo tradicional, o front chama uma API em algum domínio. Aqui não. O browser só fala com o site *.pages.dev. Qualquer request para /api/* cai numa Pages Function, que encaminha a chamada via service binding para o Worker do agente. Service binding é uma chamada interna entre Workers da mesma conta, sem passar pela internet pública.
O Worker do agente é deployado com workers_dev: false e preview_urls: false: ele não tem URL pública nenhuma. Autenticação e autorização acontecem no Worker, não no frontend. O chat responde via Server-Sent Events ponta a ponta.
O efeito prático: não existe endpoint do agente para atacar na internet. Só o Pages, que é só HTML, JS e a Function proxy que exige o cookie de sessão.
Alarms: o scheduler que não precisa de servidor rodando
Lembretes agendados e rotinas recorrentes são o problema clássico que normalmente exige um worker sempre acordado ou um cron externo. No Talorys isso usa Durable Object alarms: o próprio DO agenda a hora em que quer ser acordado. Chegou a hora, a plataforma instancia o DO, executa o handler alarm(), grava a notificação na tabela e volta a hibernar.
Há uma pegadinha conhecida da plataforma: por baixo isso roda sobre alarms de Durable Object, e como um Durable Object permite só um alarme por vez, o SDK multiplexa. Ou seja, para N lembretes futuros, o agente mantém uma fila interna no SQLite e sempre marca o alarme da próxima ocorrência. Quando dispara, calcula o próximo e remarca.
O modelo de IA e o fallback sem IA
O modelo usado para o chat é o @cf/zai-org/glm-4.7-flash, rodando dentro de Workers AI com streaming e tool calling. Workers AI é a camada da Cloudflare que roda inferência em GPU na borda e cobra em Neurons, uma unidade de compute. Há uma alocação gratuita de 10.000 Neurons por dia nos planos Free e Paid, que reseta diariamente às 00:00 UTC. Muitas features pequenas rodam inteiras dentro dessa alocação. Além disso, é cobrado 0,011 dólar por 1.000 Neurons.
O Talorys trata esse limite como condição normal de operação: quando a cota acaba, o chat mostra uma mensagem clara e volta no reset diário. Tarefas, notas, memórias e lembretes continuam funcionando, porque nada disso precisa do LLM. Lembretes simples e digests de tarefas nunca usam IA.
O que isso significa na prática
O deploy real cabe num parágrafo. Você roda npx create-talorys@latest, o instalador checa a versão do Node (20.18+), abre o fluxo OAuth do Wrangler no navegador, pede uma senha de dono (hasheada com PBKDF2-SHA256 e guardada só como secret da Cloudflare), gera nomes únicos de recurso (talorys-<id>-agent e talorys-<id>-web), cria o Worker privado, instancia o Durable Object SQLite, cria o Pages com o service binding e verifica a saúde do deploy sem gastar Neuron. No fim imprime a URL pages.dev real.
Se o processo for interrompido, roda o mesmo comando de novo. Ele reconcilia o que já existe: não duplica recurso, não repete o prompt de senha, não apaga dado. Isso é importante porque o padrão oposto (installer que só funciona se tudo estiver limpo) é o motivo de muita gente abandonar self-host.
Pelas screenshots do próprio repositório dá para ver as três áreas principais em uso. Na tela de chat, o usuário pediu em texto corrido para adicionar uma tarefa (“prepare slides for Monday”) e o agente confirmou a criação, com indicador de atividade de ferramenta. Na tela de tarefas aparecem itens como “Call the plumber about the kitchen sink” e “Review quarterly budget”, com data e prioridade, ou seja, o mesmo CRUD acessível pelo chat e pela UI. Na tela de memória estão fatos pessoais estruturados (prefere respostas concisas, alérgico a amendoim, treina para uma meia maratona em maio) e o claim do README é que, a cada turno de conversa, só as memórias mais relevantes vão para o prompt. Isso é o padrão clássico de memória por recuperação: o agente não manda tudo que sabe, ele seleciona.
Falando em agente de uso pessoal que vira ferramenta de trabalho, no StartAtende, meu agente de suporte no WhatsApp, a lição que vale aqui é parecida: o valor não aparece na primeira conversa, aparece quando o agente começa a usar o próprio histórico como fonte de decisão. Um agente que esquece tudo é um chatbot. Um agente com memória editável e persistente é outra coisa.
Onde isso quebra
Nenhuma destas limitações é tapada pelo README, então vale listar.
Single-user por design. Não tem multi-tenant, não tem equipe, não tem convites. Se você quer compartilhar com outra pessoa, cada uma precisa da própria instalação na própria conta Cloudflare. Isso é escolha, não bug, mas é bom saber antes.
10.000 Neurons por dia é pouco para chat intenso. Em outros levantamentos, uma resposta de ~500 tokens de Llama 3 custa entre 400 e 600 Neurons, o que dá cerca de 15 a 25 chamadas de texto por dia grátis, suficiente para prototipagem, projetos pessoais e demos. O modelo que o Talorys usa é diferente, mas a ordem de grandeza é essa. Se o seu uso for “conversar o dia inteiro”, você vai bater a cota rápido e precisa aceitar o reset diário ou habilitar o plano pago.
Dado só na Cloudflare é dado em uma única jurisdição. Todo o SQLite mora em um único Durable Object. Dá para fazer backup pela UI (Settings → Privacy → Download backup), gera um JSON com conversas, memórias, tarefas, notas, projetos, settings e automações. Mas não há replicação multi-região. Se o DO sofrer uma indisponibilidade regional, você fica sem acesso naquela janela.
Reset de senha é CLI only. Esqueceu a senha, só reseta rodando npx create-talorys@latest reset-password do diretório talorys/ local. Se perdeu também o diretório, precisa recriar do zero.
Modelo pré-escolhido. O chat está amarrado em @cf/zai-org/glm-4.7-flash. Trocar modelo é fork, não config exposta na UI.
Como contraponto honesto: em projetos onde escrevo sobre a tecnologia primeiro para depois usar, como nos livros que escrevi, entre eles a série IA na Prática, essa amarração em um modelo específico é o tipo de decisão que envelhece rápido. Em seis meses o nome do modelo preferido muda, e código amarrado precisa de refactor. Não é motivo para não usar, é motivo para olhar o packages/shared antes de depender dele a longo prazo.
O que não dá para afirmar ainda
Não testei o deploy ponta a ponta na minha conta, então não posso cravar quanto Neuron uma conversa típica consome na prática com o glm-4.7-flash (o número 400-600 que citei é de Llama 3, não deste modelo). Também não dá para dizer se o projeto vai ser mantido: o repositório tinha 302 stars, 18 forks e 12 commits no snapshot que vi, e o Agents SDK em si é um release pré-1.0 que muda com frequência, enquanto o substrato Durable Object em que ele é construído é generally available e já em produção, incluindo o storage SQLite. Ou seja, o chão é sólido, a camada de cima ainda se mexe.
Também não sei dizer como o Talorys se comporta quando o SQLite cresce muito (dezenas de milhares de mensagens, por exemplo). O limite teórico de 10GB por DO é folgado, mas performance de queries com histórico grande depende dos índices que o projeto define, e isso só olhando o código em apps/agent.
Como testar isso você mesmo
Caminho mínimo, sem gastar nada:
- Clone o repositório:
git clone https://github.com/rociiu/talorys.git && cd talorys - Instale:
npm install - Rode em modo local:
npm run dev. Isso sobe o Worker em 8787, a Pages Function em 8788 e a UI Vite em 5173, tudo em um terminal. Usa um provider de IA mock determinístico, então você vê o fluxo inteiro sem precisar logar na Cloudflare. - Senha local de dev é
talorys-dev-password(dá para sobrescrever com a envTALORYS_DEV_PASSWORD). - Abra o navegador em
http://localhost:5173, mande uma mensagem, crie uma tarefa pelo chat, veja aparecer na aba de tarefas.
Se quiser fazer o deploy real depois, aí sim npx create-talorys@latest, com uma conta Cloudflare criada. Com login OAuth no browser, o único segredo que você digita é a senha de dono. O instalador faz o resto.
O que vale observar enquanto testa, mesmo em modo local: olhe o wrangler.jsonc do apps/agent, procure a declaração do Durable Object com storage: "sqlite" e a migration new_sqlite_classes. Esse é o pedacinho de config que amarra toda a arquitetura descrita acima. É também o template que você copia se um dia for construir seu próprio agente nesse mesmo padrão.
