Custo de IA em frameworks JavaScript: comparação e teste

Para uma aplicação focada em conteúdo, comece por Hono+htmx e Astro quando o custo da programação com IA for importante. No benchmark de Nolan Lawson, Hono+htmx teve a menor mediana de custo estimado de API: $2.67, contra $4.97 do Angular. Para um projeto existente, teste uma alteração representativa antes de escolher outro framework.

Qual framework teve o menor custo de IA?

Use estes resultados para selecionar os frameworks que você vai testar em uma aplicação focada em conteúdo. Lawson publicou o experimento em 28 de outubro de 2026. As execuções e medições publicadas usaram Claude Code 2.1.310 com claude-opus-5-5 no nível de esforço high.

Cada agente criou a mesma aplicação com PokéAPI, busca, filtros e páginas de detalhes. A tabela reúne os resultados publicados até 2026-11-06. As versões identificam os pacotes testados, sem recomendar que você instale essas versões hoje.

Framework e versão testada	Custo estimado de API, USD: mediana (mín.–máx.)	Minutos	Tokens, milhões	Linhas de código-fonte
Hono 4.13.14 + htmx 2.0.11	$2.67 ($2.23–$3.19)	8.6	4.26	1,370
Astro 7.4.2	$2.76 ($2.16–$3.63)	8.2	4.13	1,461
Nuxt 4.6.2	$2.82 ($2.39–$4.25)	9.0	3.85	1,415
Vanilla com Vite 8.3.5	$2.98 ($2.24–$3.37)	10.1	5.00	1,492
Next.js 16.4.3	$3.14 ($2.58–$4.13)	10.9	4.99	1,539
Qwik 1.20.2 / 1.20.3	$3.27 ($2.35–$3.80)	10.7	5.64	1,744
TanStack Start 1.169.4	$3.54 ($3.11–$3.96)	10.3	7.07	1,697
SolidStart 2.1.0	$3.79 ($2.84–$4.81)	11.2	7.13	1,630
React Router 8.5.0	$3.81 ($2.82–$3.97)	12.5	7.58	1,564
SvelteKit 3.1.0	$4.28 ($3.59–$4.65)	10.8	8.53	1,611
Gracile 0.11.0 + Lit 3.3.3	$4.65 ($3.92–$5.07)	12.1	9.04	1,717
Angular 22.2.3	$4.97 ($3.19–$6.82)	17.2	9.76	2,009

A mediana de cada métrica foi calculada separadamente. Custo, tempo e tokens incluem cinco tentativas por framework. O tamanho do código do Angular considera três aplicações, pois não foi possível medir as outras duas por trás do proxy reverso.

O total de tokens inclui entrada sem cache, gravações no cache, leituras do cache e saída ao longo da sessão. A contagem de linhas exclui linhas em branco, JSON, lockfiles, testes, arquivos gerados e cópias dos arquivos de design fornecidos. Comentários entram na contagem.

Esses valores são os custos de API informados pelo Claude Code. Lawson usou uma assinatura, portanto a tabela não representa o que ele pagou por cada aplicação. Ela também não inclui sua conta de hospedagem nem o tempo de revisão humana.

Pelas medianas arredondadas, a diferença é $4.97 − $2.67 = $2.30. A razão entre os custos é 4.97 / 2.67 ≈ 1.86. Nesta tarefa, Angular custou cerca de 86% a mais que Hono+htmx.

Next.js e Astro diferem em $0.38 por aplicação, com sobreposição entre os intervalos observados. Hono+htmx e Astro diferem em apenas $0.09. Essas diferenças orientam um teste pequeno, mas não sustentam uma classificação universal com segurança.

Por que SvelteKit e Angular custaram mais?

Leituras extras de documentação e aplicações geradas com mais código podem contribuir, mas o experimento não isola esses efeitos.

Lawson observou o agente do SvelteKit lendo o guia de migração para v3 em todas as execuções. Ele sugeriu que v3 talvez fosse mais recente que os dados de treinamento do modelo. O guia oficial de migração documenta mudanças reais, incluindo a transferência da configuração para o Vite. Esse guia não comprova o que o modelo aprendeu no treinamento.

No Gracile, Lawson relata que o agente clonou o repositório ou consultou arquivos compilados em node_modules. Isso exige trabalho adicional de pesquisa. O benchmark não mede que parcela da diferença de custo veio dessas leituras.

Angular gerou uma mediana de 2,009 linhas de código-fonte, contra 1,370 do Hono+htmx. O segundo valor é cerca de 68% do primeiro, em linha com a comparação aproximada de 70% feita por Lawson. Arquivos maiores podem aumentar o trabalho de leitura e edição em alterações futuras, mas o experimento não mediu custos de manutenção.

Os totais de tokens também exigem cuidado. Nuxt teve a menor mediana de tokens, 3.85 milhões, mas não a menor mediana em dólares. O uso do cache muda a relação entre o total de tokens e o preço. Mantenha as categorias de tokens separadas ao interpretar o custo.

Servidores MCP e skills dos frameworks ajudam?

Este benchmark não demonstra se servidores MCP ou skills reduzem custos. Ele registra diferenças no uso das ferramentas disponíveis, sem comparar cada framework com essas ferramentas ativadas e desativadas.

Lawson instalou as ferramentas oficiais quando estavam disponíveis. Vários frameworks não tinham essas ferramentas. Entre as observações dele:

Framework	Uso observado nas cinco execuções
Hono+htmx	Ferramenta Skill do Hono usada em 5/5
SvelteKit	MCP usado em 5/5
Nuxt	MCP usado em 0/5
Next.js	Arquivos de skill lidos em 1/5; AGENTS.md lido em 2/5
TanStack Start	Arquivos de skills incluídos no pacote encontrados em 2/5

O MCP do Nuxt não ter sido usado não prova que ele seja ineficaz. O custo maior do SvelteKit também não prova que seu MCP causou a diferença. Instalar uma ferramenta, usá-la e reduzir o custo de uma tarefa concluída são questões distintas.

As orientações atuais do Next.js separam a documentação correspondente à versão instalada das skills que coordenam o trabalho. Registre qual recurso o agente realmente usou, em vez de contar toda leitura de documentação como uma chamada MCP.

Para testar no seu projeto, verifique a disponibilidade do servidor com claude mcp list ou /mcp. Depois, inspecione as chamadas efetivamente feitas. Compare um framework sem ferramentas, com ferramentas disponíveis e com uma instrução explícita para usá-las. O guia para medir o contexto de MCP detalha esse tipo de avaliação.

Quais são os limites do experimento?

Trate os resultados como uma triagem para pequenas aplicações focadas em conteúdo. Quatro limitações devem orientar o uso dos dados:

• Tipo de aplicação: um catálogo com pouca interação não representa um editor complexo, um painel de controle ou um jogo. Os agentes também escolheram a arquitetura de renderização.
• Amostra: cinco tentativas fornecem exemplos e intervalos úteis, mas a ordem entre resultados próximos continua incerta. Os intervalos mostram mínimos e máximos observados, não intervalos de confiança.
• Ambiente: o teste usou um modelo, um agente e um nível de esforço. Qwik passou de 1.20.2 para 1.20.3 após a primeira execução. A combinação solicitada Gracile+Lit também gerou duas implementações sem Lit.
• Resultado: as medições de carregamento de página do Lighthouse com configurações móveis não cobrem toda interação ou exigência de produção. As linhas de código medem tamanho, sem demonstrar o custo futuro de manutenção.

O caso do Angular também importa. O arquivo de resultados registra aprovação nos testes de aceitação nas cinco tentativas, embora duas medições das aplicações em modo de produção tenham falhado. Registre separadamente a aprovação nos testes e o sucesso da implantação no seu experimento.

Como medir o custo do Claude Code no seu projeto

Comece com dois candidatos e três novas tentativas para cada um. Aumente para cinco quando os resultados estiverem próximos. Este é um plano proposto para um teste inicial, não um resultado adicional do benchmark.

1. Defina a tarefa e o estado inicial

Compare uma funcionalidade bem delimitada com as mesmas verificações de aceitação. Em um produto existente, inclua o framework atual entre os candidatos. Prepare os dois projetos iniciais antes de cronometrar um teste de edição; inclua a preparação nos dois se quiser medir a criação do zero.

Descreva uma tarefa concreta em SPEC.md. Por exemplo, prepare páginas de catálogo equivalentes e os mesmos dados de teste dos produtos. Em seguida, peça:

Add case-insensitive name search to the catalog.
Read products from the existing fixture.
Persist the search query in the URL across reloads.
Show an accessible empty state when nothing matches.
Keep existing routes and the acceptance tests unchanged.

Defina versões fixas para as dependências e preserve os lockfiles. Instale as dependências antes do teste de edição. Verifique se ambos os projetos oferecem npm run build e npm test. Guarde uma cópia dos testes de aceitação sem alterações.

Use a mesma base de código, prompt, modelo e nível de esforço em cada tentativa. Mantenha também as permissões, as ferramentas do framework e a forma de acesso e cobrança. Inicie uma conversa nova em uma cópia limpa a cada tentativa. Alterne a ordem dos frameworks e registre o uso do cache.

Registre também instruções do usuário, hooks e plugins que possam mudar o comportamento. Se preferir a aplicação original e suas verificações prontas, comece pelos scripts do benchmark de Lawson.

2. Registre uma execução e seu resultado final

Use Bash com Claude Code autenticado e jq instalado. Confira a autenticação com claude auth status --text. Se necessário, use claude auth login antes do teste.

Execute em um contêiner de desenvolvimento descartável. A lista de permissões abaixo autoriza automaticamente alterações em arquivos e comandos do shell. Aprove previamente as chamadas MCP previstas com regras de permissão que sejam carregadas em cada ambiente de teste. Conectar o servidor, por si só, não basta.

Defina um trial_label diferente para cada condição. O exemplo usa o modo não interativo documentado da CLI e cria um diretório de saída exclusivo.

trial_label=astro-01
trial_dir=$(mktemp -d "/tmp/${trial_label}.XXXXXX") || exit 1

claude --version > "$trial_dir/claude-version.txt"
git rev-parse HEAD > "$trial_dir/commit.txt"

trial_status=0
CLAUDE_CODE_EFFORT_LEVEL=high claude -p \
  --model claude-opus-5-5 \
  --max-budget-usd 10 \
  --allowedTools "Read,Edit,Write,Bash" \
  --output-format stream-json --verbose \
  "Implement SPEC.md without changing dependencies or acceptance tests. Run npm run build and npm test. Report incomplete work." \
  > "$trial_dir/session.jsonl" 2> "$trial_dir/stderr.log" \
  || trial_status=$?

printf '%s\n' "$trial_status" > "$trial_dir/exit-code.txt"

jq -s '
  [.[] | select(.type == "result")] | last
  | if . == null then error("No final result; record an incomplete run")
    else {
      session_id,
      subtype,
      is_error,
      estimated_usd: .total_cost_usd,
      reported_wall_minutes: (.duration_ms / 60000),
      modelUsage,
      permission_denials
    } end
' "$trial_dir/session.jsonl" > "$trial_dir/summary.json"

cat "$trial_dir/summary.json"
printf 'Results: %s\n' "$trial_dir"

O valor de $10 é um orçamento de exemplo. --max-budget-usd usa o gasto estimado de API, e os gastos podem ultrapassar o limite. Aplique o mesmo valor a todas as condições e registre as interrupções por orçamento.

Em 2026-11-06, CLAUDE_CODE_EFFORT_LEVEL tem prioridade sobre --effort. As restrições de esforço da organização ainda podem limitar o nível selecionado. Se o modelo não carregar, ajuste a configuração do Opus 5.5 antes de continuar a comparação.

O resumo deve conter estimated_usd, reported_wall_minutes, modelUsage e eventuais permission_denials. O registro JSONL preserva os eventos das ferramentas para inspeção. Confirme que o modelo previsto aparece e anote quaisquer modelos adicionais usados.

3. Compare os resultados aprovados e contabilize as falhas

Use modelUsage para contabilizar os tokens do agente e dos subagentes. Mantenha inputTokens, outputTokens, cacheReadInputTokens e cacheCreationInputTokens separados. O campo usage no resultado final não inclui a atividade dos subagentes.

Leia o resultado final uma vez. Não some os totais acumulados de vários resultados nem reutilize uma sessão retomada como uma nova tentativa.

Execute você mesmo os testes sem alterações e o build de produção. Confirme que os arquivos de dependências e testes não mudaram. O agente informar sucesso não prova que a aplicação atende à especificação.

Se o resultado final estiver ausente ou malformado, examine stderr.log. Registre uma execução incompleta com custo desconhecido. Não registre zero. Resolva as recusas de permissão antes de atribuir o não uso de MCP ao comportamento do agente.

Para cada framework, informe quantas tentativas foram aprovadas e quantas foram feitas no total. Apresente medianas e intervalos das execuções bem-sucedidas, além do custo estimado total de todas as tentativas. Calcule o custo por resultado aprovado dividindo o custo total de todas as tentativas pelo número de resultados aprovados:

Total quoted cost of all attempts / Number of accepted results

Se qualquer tentativa não tiver dados de custo, marque o custo total como incompleto. Sem resultados aprovados, informe a falha, em vez de apresentar um custo unitário finito. Registre o tempo de revisão humana separadamente.

Em sessões manuais, o relatório de custos atual do Claude Code mostra o mesmo tipo de estimativa em /usage. A referência de comandos lista /cost como um alias em 2026-11-06. As cotas da assinatura e as cobranças reais do provedor permanecem separadas dessa estimativa.

Mantenha a stack atual se uma pequena economia de tokens não compensar o esforço de revisão ou o trabalho de migração. Mude essa recomendação quando o candidato passar repetidamente nas mesmas verificações com custos aceitáveis para manter e operar o projeto.

Após escolher um framework, teste outro modelo ou forma de acesso em um experimento separado. A comparação de modelos para programação pode ajudar a escolher candidatos sem mudar vários fatores ao mesmo tempo no teste dos frameworks.