A Cloudflare abriu a API Dynamic Worker Loader para executar código carregado em runtime dentro de isolates V8. Um agente pode escrever uma função TypeScript que combina várias operações, enviar esse programa para um Worker e receber apenas o resultado final.
O formato troca uma sequência de tool calls visível ao modelo por código que faz a composição perto dos serviços. A Cloudflare chama esse padrão de code mode. Seu próprio servidor MCP expõe a API inteira da plataforma por duas ferramentas, busca e execução, com uma descrição inferior a mil tokens.
Há uma vantagem plausível de contexto: resultados intermediários não precisam voltar todos para a conversa. Há também uma fronteira de segurança nova. O código gerado passa a executar com rede e capacidades definidas pelo loader. Se essas permissões forem amplas, uma interface compacta apenas torna o erro mais rápido.
Isolate curto muda a unidade de execução
Segundo a Cloudflare, um isolate inicia em poucos milissegundos, usa poucos megabytes e pode subir cerca de cem vezes mais rápido que um container típico, com consumo de memória de dez a cem vezes menor. São números publicados pelo fornecedor, úteis para entender a proposta, sem valer como benchmark universal contra qualquer runtime de containers.
A leveza permite criar um Worker para uma única solicitação, executar poucas linhas e descartá-lo. Isso combina com agentes porque o programa pode ser diferente a cada tarefa. Em vez de manter uma imagem pronta para toda possibilidade, o loader recebe módulos no momento da execução.
O limite é deliberado: o caminho preferido é JavaScript ou TypeScript. Workers também aceitam Python e WebAssembly em alguns cenários, mas a própria Cloudflare recomenda JavaScript para trechos gerados sob demanda por carregar mais rápido. Quem precisa de binários nativos, processos arbitrários ou uma imagem Linux completa continua diante de outro tipo de sandbox.
Essa separação evita escolher infraestrutura pelo rótulo "agente". Se a tarefa compõe APIs e transforma dados, um isolate pode ser suficiente. Se exige ferramentas do sistema, pacotes nativos ou execução longa, a diferença de boot perde importância diante das capacidades ausentes.
A API tipada reduz contexto e concentra autoridade
Descrever centenas de operações como schemas de ferramentas ocupa contexto antes da tarefa começar. Uma interface TypeScript compacta deixa o modelo pesquisar a superfície e escrever a composição. A Cloudflare relatou redução de 81% no consumo de tokens ao converter um servidor MCP para esse formato em seu experimento.
O ganho depende de como a interface é desenhada. Entregar um cliente genérico com acesso administrativo a toda API preserva poucos tokens e cria uma permissão difícil de revisar. Um binding estreito pode oferecer buscarPedido, calcularFrete e registrarNota com validação dentro do loader. O Worker dinâmico vê somente os métodos concedidos.
A documentação de bindings recomenda implementar essas capacidades no Worker carregador, onde autenticação, escopo por cliente, logs e rejeições ficam sob controle da aplicação. Segredos não precisam entrar no código gerado. O loader pode anexar credenciais ao encaminhar uma chamada.
Para mim, esse é o ponto arquitetural mais interessante. O contrato tipado pode servir ao modelo e, ao mesmo tempo, formar a fronteira de autorização. Só funciona quando os métodos representam capacidades pequenas. Um executeAnything(token) desfaz a vantagem.
Rede aberta é o default que precisa de decisão
No WorkerCode, a opção globalOutbound controla fetch() e connect(). Se ela for omitida, o Worker dinâmico herda o acesso de rede do pai, normalmente com saída para a internet pública. Definir globalOutbound: null bloqueia a rede. Também é possível redirecionar toda saída para um gateway, que limita destinos, injeta credenciais e registra chamadas.
Esse comportamento deveria aparecer num checklist de criação, sem ficar escondido num exemplo. Código gerado a partir de texto externo pode receber instruções maliciosas. Um sandbox de CPU e memória não impede exfiltração quando a rede continua aberta e dados sensíveis estão disponíveis.
Eu começaria com rede bloqueada e bindings explícitos. Depois liberaria destinos por caso de uso, com limites de tempo, tamanho de resposta e custo. O log precisa dizer qual código ou hash executou, quais capacidades foram chamadas e qual identidade iniciou a tarefa. Guardar cada detalhe do raciocínio do modelo não substitui esse registro operacional.
O preço já saiu da fase gratuita do beta
O anúncio original dizia que a taxa de US$ 0,002 por Worker único carregado por dia seria dispensada durante o beta. A página atual de preços informa que a cobrança começou em 26 de maio de 2026. Dynamic Workers está disponível no plano Workers Paid.
O plano inclui mil Dynamic Workers únicos por mês. Acima disso, a tabela cobra US$ 0,002 por Worker por dia, além de requests e tempo de CPU nas taxas padrão de Workers. Uma identidade estável pode carregar o mesmo Worker várias vezes no dia sem contar como vários Workers únicos; código realmente descartável tende a criar novas unidades cobradas.
Para estimar, eu usaria o padrão de identidade real da aplicação. Um Worker por cliente, por automação persistente e por execução única produzem curvas diferentes. O custo de inferência ainda pode dominar, como observa a Cloudflare, mas isso precisa sair dos números do produto.
Um piloto cabe em uma composição pequena
O teste mais informativo não é portar todas as ferramentas. Escolha um fluxo com três ou quatro chamadas, respostas intermediárias volumosas e um resultado verificável. Implemente a mesma tarefa como tool calls sequenciais e como função executada no Dynamic Worker.
Compare tokens enviados ao modelo, latência total, custo, qualidade da saída e facilidade de investigar uma falha. Inclua um caso de rede bloqueada e outro de argumento inválido. Se o code mode economizar contexto enquanto o gateway mantém a autoridade pequena, ele ganhou um lugar concreto.
Dynamic Workers não elimina ferramentas. Move a composição para um programa temporário e transforma bindings em interface de segurança. A parte veloz já vem da plataforma; a parte segura depende do que o loader decide expor.
