{"id":771,"date":"2026-10-10T18:33:59","date_gmt":"2026-10-10T21:33:59","guid":{"rendered":"https:\/\/yellowkode.com\/blog\/talorys-agente-pessoal-cloudflare-gratuita\/"},"modified":"2026-10-10T18:33:59","modified_gmt":"2026-10-10T21:33:59","slug":"talorys-agente-pessoal-cloudflare-gratuita","status":"publish","type":"post","link":"https:\/\/yellowkode.com\/blog\/talorys-agente-pessoal-cloudflare-gratuita\/","title":{"rendered":"Talorys: Como um Agente Pessoal Roda Inteiro Dentro de uma Conta Cloudflare Gratuita"},"content":{"rendered":"

No fim de setembro de 2026 apareceu no GitHub o Talorys<\/strong>, um projeto open source (MIT) que se descreve como um agente pessoal de IA, single-user, que roda inteiro dentro da sua pr\u00f3pria conta Cloudflare e cabe no free tier. O deploy \u00e9 um comando: npx create-talorys@latest<\/code>. O reposit\u00f3rio \u00e9 mantido por rociiu e est\u00e1 em github.com\/rociiu\/talorys<\/code>.<\/p>\n

O que faz o projeto interessante n\u00e3o \u00e9 a lista de features (chat, mem\u00f3ria, tarefas, notas, lembretes agendados). Isso qualquer agente tem. O interessante \u00e9 a arquitetura<\/em>: tudo, inclusive banco de dados e scheduler, mora dentro de um \u00fanico Durable Object com SQLite embutido. Zero servidor pr\u00f3prio, zero banco externo, zero telemetria. Vale entender como isso funciona por baixo, porque \u00e9 um padr\u00e3o novo e d\u00e1 para reaproveitar em projeto pr\u00f3prio.<\/p>\n

Como o Talorys funciona por baixo do cap\u00f4<\/h2>\n

O fluxo tem tr\u00eas camadas, e cada uma mora em um lugar espec\u00edfico da Cloudflare:<\/p>\n

Browser\n \u2502 HTTPS\n \u25bc\nCloudflare Pages (React + \/api Pages Function)\n \u2502 service binding (sem URL p\u00fablica)\n \u25bc\nWorker privado (Hono router)\n \u2502 getAgentByName(\"personal-agent\")\n \u25bc\nTalorysAgent (Durable Object com SQLite)\n \u251c\u2500 tabelas: conversations, memories, tasks, notes, projects, automations, sessions, settings, usage\n \u251c\u2500 Workers AI: @cf\/zai-org\/glm-4.7-flash (streaming + tool calling)\n \u2514\u2500 Alarms: lembretes e schedules recorrentes<\/code><\/pre>\n
O ponto chave \u00e9 o Durable Object. Antes de entrar nele, uma analogia que carrega a mec\u00e2nica, n\u00e3o s\u00f3 o nome.<\/p>\n
Pense num escrit\u00f3rio que fecha a chave quando ningu\u00e9m est\u00e1 dentro<\/h3>\n
Imagine um escrit\u00f3rio pequeno com uma \u00fanica mesa, um fich\u00e1rio trancado e um despertador. Quando ningu\u00e9m entra, as luzes se apagam, ningu\u00e9m est\u00e1 pagando aluguel. Quando chega uma carta, uma liga\u00e7\u00e3o ou toca o despertador, algu\u00e9m acende a luz, abre o fich\u00e1rio, atende, anota, e sai. O fich\u00e1rio continua ali, com tudo que foi escrito antes. \u00c9 o mesmo escrit\u00f3rio sempre, com o mesmo fich\u00e1rio, com o mesmo despertador configurado.<\/p>\n
Durable Object \u00e9 esse escrit\u00f3rio. O Agents SDK \u00e9 constru\u00eddo 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 \u00e9 uma entidade endere\u00e7\u00e1vel com seu pr\u00f3prio banco SQLite. Consome zero compute quando est\u00e1 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\u00f3rio f\u00edsico voc\u00ea precisa de algu\u00e9m para abrir a porta. No Durable Object, a pr\u00f3pria Cloudflare instancia o objeto sob demanda. N\u00e3o existe equivalente a atraso humano, \u00e9 milissegundos.<\/p>\n
O SQLite mora dentro do agente, n\u00e3o ao lado<\/h3>\n
Essa \u00e9 a parte que mais foge do padr\u00e3o cl\u00e1ssico (app em um lugar, banco em outro). Como o storage fica colocalizado com o Durable Object, as queries t\u00eam lat\u00eancia efetivamente zero. O SQLite roda n\u00e3o s\u00f3 no mesmo data center, mas na mesma thread do compute do Durable Object. As queries s\u00e3o s\u00edncronas, porque executam t\u00e3o rapidamente que n\u00e3o h\u00e1 motivo para serem ass\u00edncronas.<\/p>\n
Em n\u00fameros: comparado ao storage key-value, os limites s\u00e3o bem maiores em SQLite-backed Durable Objects. D\u00e1 para armazenar at\u00e9 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 \u00e9 mais do que suficiente por anos.<\/p>\n
Service binding: o Worker do agente n\u00e3o tem URL p\u00fablica<\/h3>\n
No modelo tradicional, o front chama uma API em algum dom\u00ednio. Aqui n\u00e3o. O browser s\u00f3 fala com o site *.pages.dev<\/code>. Qualquer request para \/api\/*<\/code> cai numa Pages Function, que encaminha a chamada via service binding<\/em> para o Worker do agente. Service binding \u00e9 uma chamada interna entre Workers da mesma conta, sem passar pela internet p\u00fablica.<\/p>\n
O Worker do agente \u00e9 deployado com workers_dev: false<\/code> e preview_urls: false<\/code>: ele n\u00e3o tem URL p\u00fablica nenhuma. Autentica\u00e7\u00e3o e autoriza\u00e7\u00e3o acontecem no Worker, n\u00e3o no frontend. O chat responde via Server-Sent Events ponta a ponta.<\/p>\n
O efeito pr\u00e1tico: n\u00e3o existe endpoint do agente para atacar na internet. S\u00f3 o Pages, que \u00e9 s\u00f3 HTML, JS e a Function proxy que exige o cookie de sess\u00e3o.<\/p>\n
Alarms: o scheduler que n\u00e3o precisa de servidor rodando<\/h3>\n
Lembretes agendados e rotinas recorrentes s\u00e3o o problema cl\u00e1ssico que normalmente exige um worker sempre acordado ou um cron externo. No Talorys isso usa Durable Object alarms<\/strong>: o pr\u00f3prio DO agenda a hora em que quer ser acordado. Chegou a hora, a plataforma instancia o DO, executa o handler alarm()<\/code>, grava a notifica\u00e7\u00e3o na tabela e volta a hibernar.<\/p>\n
H\u00e1 uma pegadinha conhecida da plataforma: por baixo isso roda sobre alarms de Durable Object, e como um Durable Object permite s\u00f3 um alarme por vez, o SDK multiplexa. Ou seja, para N lembretes futuros, o agente mant\u00e9m uma fila interna no SQLite e sempre marca o alarme da pr\u00f3xima ocorr\u00eancia. Quando dispara, calcula o pr\u00f3ximo e remarca.<\/p>\n
O modelo de IA e o fallback sem IA<\/h3>\n
O modelo usado para o chat \u00e9 o @cf\/zai-org\/glm-4.7-flash<\/code>, rodando dentro de Workers AI com streaming e tool calling. Workers AI \u00e9 a camada da Cloudflare que roda infer\u00eancia em GPU na borda e cobra em Neurons<\/em>, uma unidade de compute. H\u00e1 uma aloca\u00e7\u00e3o gratuita de 10.000 Neurons por dia nos planos Free e Paid, que reseta diariamente \u00e0s 00:00 UTC. Muitas features pequenas rodam inteiras dentro dessa aloca\u00e7\u00e3o. Al\u00e9m disso, \u00e9 cobrado 0,011 d\u00f3lar por 1.000 Neurons.<\/p>\n
O Talorys trata esse limite como condi\u00e7\u00e3o normal de opera\u00e7\u00e3o: quando a cota acaba, o chat mostra uma mensagem clara e volta no reset di\u00e1rio. Tarefas, notas, mem\u00f3rias e lembretes continuam funcionando, porque nada disso precisa do LLM. Lembretes simples e digests de tarefas nunca usam IA.<\/p>\n
O que isso significa na pr\u00e1tica<\/h2>\n
O deploy real cabe num par\u00e1grafo. Voc\u00ea roda npx create-talorys@latest<\/code>, o instalador checa a vers\u00e3o do Node (20.18+), abre o fluxo OAuth do Wrangler no navegador, pede uma senha de dono (hasheada com PBKDF2-SHA256 e guardada s\u00f3 como secret da Cloudflare), gera nomes \u00fanicos de recurso (talorys-<id>-agent<\/code> e talorys-<id>-web<\/code>), cria o Worker privado, instancia o Durable Object SQLite, cria o Pages com o service binding e verifica a sa\u00fade do deploy sem gastar Neuron. No fim imprime a URL pages.dev<\/code> real.<\/p>\n
Se o processo for interrompido, roda o mesmo comando de novo. Ele reconcilia o que j\u00e1 existe: n\u00e3o duplica recurso, n\u00e3o repete o prompt de senha, n\u00e3o apaga dado. Isso \u00e9 importante porque o padr\u00e3o oposto (installer que s\u00f3 funciona se tudo estiver limpo) \u00e9 o motivo de muita gente abandonar self-host.<\/p>\n
Pelas screenshots do pr\u00f3prio reposit\u00f3rio d\u00e1 para ver as tr\u00eas \u00e1reas principais em uso. Na tela de chat, o usu\u00e1rio pediu em texto corrido para adicionar uma tarefa (“prepare slides for Monday”) e o agente confirmou a cria\u00e7\u00e3o, 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\u00edvel pelo chat e pela UI. Na tela de mem\u00f3ria est\u00e3o fatos pessoais estruturados (prefere respostas concisas, al\u00e9rgico a amendoim, treina para uma meia maratona em maio) e o claim do README \u00e9 que, a cada turno de conversa, s\u00f3 as mem\u00f3rias mais relevantes v\u00e3o para o prompt. Isso \u00e9 o padr\u00e3o cl\u00e1ssico de mem\u00f3ria por recupera\u00e7\u00e3o: o agente n\u00e3o manda tudo que sabe, ele seleciona.<\/p>\n
Falando em agente de uso pessoal que vira ferramenta de trabalho, no StartAtende, meu agente de suporte no WhatsApp<\/strong>, a li\u00e7\u00e3o que vale aqui \u00e9 parecida: o valor n\u00e3o aparece na primeira conversa, aparece quando o agente come\u00e7a a usar o pr\u00f3prio hist\u00f3rico como fonte de decis\u00e3o. Um agente que esquece tudo \u00e9 um chatbot. Um agente com mem\u00f3ria edit\u00e1vel e persistente \u00e9 outra coisa.<\/p>\n
Onde isso quebra<\/h2>\n
Nenhuma destas limita\u00e7\u00f5es \u00e9 tapada pelo README, ent\u00e3o vale listar.<\/p>\n
Single-user por design.<\/strong> N\u00e3o tem multi-tenant, n\u00e3o tem equipe, n\u00e3o tem convites. Se voc\u00ea quer compartilhar com outra pessoa, cada uma precisa da pr\u00f3pria instala\u00e7\u00e3o na pr\u00f3pria conta Cloudflare. Isso \u00e9 escolha, n\u00e3o bug, mas \u00e9 bom saber antes.<\/p>\n
10.000 Neurons por dia \u00e9 pouco para chat intenso.<\/strong> Em outros levantamentos, uma resposta de ~500 tokens de Llama 3 custa entre 400 e 600 Neurons, o que d\u00e1 cerca de 15 a 25 chamadas de texto por dia gr\u00e1tis, suficiente para prototipagem, projetos pessoais e demos. O modelo que o Talorys usa \u00e9 diferente, mas a ordem de grandeza \u00e9 essa. Se o seu uso for “conversar o dia inteiro”, voc\u00ea vai bater a cota r\u00e1pido e precisa aceitar o reset di\u00e1rio ou habilitar o plano pago.<\/p>\n
Dado s\u00f3 na Cloudflare \u00e9 dado em uma \u00fanica jurisdi\u00e7\u00e3o.<\/strong> Todo o SQLite mora em um \u00fanico Durable Object. D\u00e1 para fazer backup pela UI (Settings \u2192 Privacy \u2192 Download backup), gera um JSON com conversas, mem\u00f3rias, tarefas, notas, projetos, settings e automa\u00e7\u00f5es. Mas n\u00e3o h\u00e1 replica\u00e7\u00e3o multi-regi\u00e3o. Se o DO sofrer uma indisponibilidade regional, voc\u00ea fica sem acesso naquela janela.<\/p>\n
Reset de senha \u00e9 CLI only.<\/strong> Esqueceu a senha, s\u00f3 reseta rodando npx create-talorys@latest reset-password<\/code> do diret\u00f3rio talorys\/<\/code> local. Se perdeu tamb\u00e9m o diret\u00f3rio, precisa recriar do zero.<\/p>\n
Modelo pr\u00e9-escolhido.<\/strong> O chat est\u00e1 amarrado em @cf\/zai-org\/glm-4.7-flash<\/code>. Trocar modelo \u00e9 fork, n\u00e3o config exposta na UI.<\/p>\n
Como contraponto honesto: em projetos onde escrevo sobre a tecnologia primeiro para depois usar, como nos livros que escrevi, entre eles a s\u00e9rie IA na Pr\u00e1tica<\/strong>, essa amarra\u00e7\u00e3o em um modelo espec\u00edfico \u00e9 o tipo de decis\u00e3o que envelhece r\u00e1pido. Em seis meses o nome do modelo preferido muda, e c\u00f3digo amarrado precisa de refactor. N\u00e3o \u00e9 motivo para n\u00e3o usar, \u00e9 motivo para olhar o packages\/shared<\/code> antes de depender dele a longo prazo.<\/p>\n
O que n\u00e3o d\u00e1 para afirmar ainda<\/h2>\n
N\u00e3o testei o deploy ponta a ponta na minha conta, ent\u00e3o n\u00e3o posso cravar quanto Neuron uma conversa t\u00edpica consome na pr\u00e1tica com o glm-4.7-flash<\/code> (o n\u00famero 400-600 que citei \u00e9 de Llama 3, n\u00e3o deste modelo). Tamb\u00e9m n\u00e3o d\u00e1 para dizer se o projeto vai ser mantido: o reposit\u00f3rio tinha 302 stars, 18 forks e 12 commits no snapshot que vi, e o Agents SDK em si \u00e9 um release pr\u00e9-1.0 que muda com frequ\u00eancia, enquanto o substrato Durable Object em que ele \u00e9 constru\u00eddo \u00e9 generally available e j\u00e1 em produ\u00e7\u00e3o, incluindo o storage SQLite. Ou seja, o ch\u00e3o \u00e9 s\u00f3lido, a camada de cima ainda se mexe.<\/p>\n
Tamb\u00e9m n\u00e3o sei dizer como o Talorys se comporta quando o SQLite cresce muito (dezenas de milhares de mensagens, por exemplo). O limite te\u00f3rico de 10GB por DO \u00e9 folgado, mas performance de queries com hist\u00f3rico grande depende dos \u00edndices que o projeto define, e isso s\u00f3 olhando o c\u00f3digo em apps\/agent<\/code>.<\/p>\n
Como testar isso voc\u00ea mesmo<\/h2>\n
Caminho m\u00ednimo, sem gastar nada:<\/p>\n
    \n
  1. Clone o reposit\u00f3rio: git clone https:\/\/github.com\/rociiu\/talorys.git && cd talorys<\/code><\/li>\n
  2. Instale: npm install<\/code><\/li>\n
  3. Rode em modo local: npm run dev<\/code>. 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\u00edstico, ent\u00e3o voc\u00ea v\u00ea o fluxo inteiro sem precisar logar na Cloudflare.<\/li>\n
  4. Senha local de dev \u00e9 talorys-dev-password<\/code> (d\u00e1 para sobrescrever com a env TALORYS_DEV_PASSWORD<\/code>).<\/li>\n
  5. Abra o navegador em http:\/\/localhost:5173<\/code>, mande uma mensagem, crie uma tarefa pelo chat, veja aparecer na aba de tarefas.<\/li>\n<\/ol>\n
    Se quiser fazer o deploy real depois, a\u00ed sim npx create-talorys@latest<\/code>, com uma conta Cloudflare criada. Com login OAuth no browser, o \u00fanico segredo que voc\u00ea digita \u00e9 a senha de dono. O instalador faz o resto.<\/p>\n
    O que vale observar enquanto testa, mesmo em modo local: olhe o wrangler.jsonc<\/code> do apps\/agent<\/code>, procure a declara\u00e7\u00e3o do Durable Object com storage: \"sqlite\"<\/code> e a migration new_sqlite_classes<\/code>. Esse \u00e9 o pedacinho de config que amarra toda a arquitetura descrita acima. \u00c9 tamb\u00e9m o template que voc\u00ea copia se um dia for construir seu pr\u00f3prio agente nesse mesmo padr\u00e3o.<\/p>\n","protected":false},"excerpt":{"rendered":"
    Como o Talorys usa Durable Objects com SQLite embutido, Workers AI e service bindings para rodar um agente de IA pessoal no free tier da Cloudflare.<\/p>\n","protected":false},"author":2,"featured_media":770,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[],"class_list":["post-771","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-uncategorized"],"_links":{"self":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/771","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/users\/2"}],"replies":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/comments?post=771"}],"version-history":[{"count":0,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/posts\/771\/revisions"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media\/770"}],"wp:attachment":[{"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/media?parent=771"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/categories?post=771"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/yellowkode.com\/blog\/wp-json\/wp\/v2\/tags?post=771"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}