[Benchmark] Fiz um LLM Coder Router e tive ~76% menos CUSTO que Sonnet e Codex e com entrega similar.
Olá, malta do TabNews! 👋
Sou o dev por trás do claudin.io, um roteador simples e esperto para LLMs que usa o https://openrouter.ai pra direcionar queries pros modelos certos com base na complexidade da tarefa. Fiz isso pra mim mesmo, curando prompts de roteamento e uma lista de modelos que equilibram custo e qualidade. A ideia é compartilhar essa "curadoria" por só $3,99/mês! Pra quem, como eu, quer rodar IA sem faturas exorbitantes, mas com resultados que não envergonham. Não é pra bater de frente com os titãs como o Claude Sonnet 4.5 (que é um monstro), mas pra ser o sidekick confiável em tarefas cotidianas, poupando seus agentes premium pros momentos críticos.
Já tenho usado, inclusive no próprio site do claudin.io.
Pq criei o claudin.io?
Por causa dessa imagem:
E também tenho um apelido para o Claude que é Claudineo, então dai vem o nome Claudin.io.
Sobre o Benchmark
Pra validar, botei o claudin.io pra suar num benchmark prático: um desafio de codificação simples, mas com pegadinhas de validação e renderização. Compartilhei o benchmark completo com os códigos gerados e testes no Google Drive, baixem e testem vocês mesmos! O foco? Comparar custo, performance e se o resultado "cola" na real.
Usei o https://kilocode.ai como base mesmo tendo a certeza de que eles poderiam ter feito melhor ou mais rápido com os seus CLIs (claude-code e codex). Minha intenção era mantê-los no mesmo "campo".
O Desafio: Um Servidor HTTP Mínimo pra Conversão de Unidades
O prompt era direto: implementar um server Node.js (Express, single-file) que serve uma página HTML pra converter Celsius/Fahrenheit. GET / com form, validação de input, resultado com 2 casas decimais, e tratamento de erros (N/A pra inválidos). Sem deps extras, logs ou frescuras – só o essencial. Aqui vai o prompt completo pra contextualizar:
Implement a minimal HTTP server that serves an HTML page for unit conversion with the following requirements.
Task
• Language/stack: Node.js (>=18) with Express in a single file named server.js.
• Endpoint:
◦ GET / returns an HTML page (no external assets) containing:
▪ A <form> with:
▪ A number <input> named value
▪ A <select> named direction with options:
▪ c_to_f (Celsius to Fahrenheit)
▪ f_to_c (Fahrenheit to Celsius)
▪ A submit <button>
▪ When submitted (method GET), the server reads query params (value, direction), performs the conversion server-side, and renders the same page with:
▪ The input fields prefilled with the submitted values
▪ A bold line showing Result: <number> with exactly 2 decimal places
• Server details:
◦ Listen on port from env PORT or default 3000.
◦ Strictly no extra dependencies beyond express.
◦ No external CSS/JS; inline CSS permitted.
◦ Input validation:
▪ If value is missing or not a finite number, show Result: N/A and display a small inline error under the input: Please enter a valid number.
Conversions
• Celsius to Fahrenheit: F = C * 9/5 + 32
• Fahrenheit to Celsius: C = (F - 32) * 5/9
• Result must always render with exactly 2 decimal places when valid.
Determinism constraints
• Do not print logs except the single line Server listening on port <port>.
• No comments in code.
• No additional files or routes.
• Do not minify HTML; keep it readable.
• Use CommonJS require style.
Output format
Return only one fenced code block with language hint javascript containing the complete server.js file. Do not include any explanation before or after the code block.
Quick acceptance checklist
• Starts with const express = require('express')
• Binds to process.env.PORT || 3000
• Single GET / that renders HTML including the form and, if query present, the computed result
• Result shows 2 decimals (e.g., 21.11)
• Invalid/missing input shows Result: N/A and inline error text
• No extraneous logs, comments, or files
Example manual test (not to be included in output)
• Start: PORT=5050 node server.js
• Open: http://localhost:5050/?value=100&direction=c_to_f → Result: 212.00
• Open: http://localhost:5050/?value=32&direction=f_to_c → Result: 0.00
• Open: http://localhost:5050/?value=abc&direction=f_to_c → Result: N/A and error visible
Videos deles agindo:
Claudin.io: https://youtu.be/r1sj6TaRTOk ✅✅
Sonnet 4.5: https://youtu.be/xPyqkAwBjX8 ✅✅✅
GPT-5-Codex Medium: https://youtu.be/osXGsLxszpw ❌
Testei localmente: build de primeira, conversões exatas, validação funcionando. Simples, mas cobre os basics de um app web real.
Resultados: O Que Cada Um Entregou (e Custou)
Rodei o mesmo prompt, via OpenRouter. Aqui o breakdown:
| Métrica | Claude Sonnet 4.5 | claudin.io Router | OpenAI GPT-5 Codex Medium |
|---|---|---|---|
| Requests | 24 | 24 | 22 |
| Tokens | 586K | 299K | 399K |
| Gasto | $0.444 | $0.034 | $0.446 |
| Performance no Desafio | Excelente: Código funcional + testes visuais extras (surpreendente!) | Sólido: Código funcional, build OK | Fraco: Não terminou, build falhou na 1ª tentativa |
Destaques sinceros:
- Sonnet 4.5: Foi além! Gerou código perfeito e até simulou testes visuais (coisa de agente parrudo). Mas o custo? Uau, premium tem seu preço. Ideal pros jobs complexos, mas rate limits de horas/semanas matam o flow.
- GPT-5 Codex Medium: Decepcionou. Parou no meio, não buildou direito. Tokens altos pra um resultado meia-boca, clássico de "quase lá, mas não".
- claudin.io: Fiquei felizão com o output! Código direto ao ponto, sem frescuras, build na mosca. Não inovou como o Sonnet, mas entregou o que pedi, com tokens otimizados e custo irrisório. Economia de ~76% vs. os gigantes (0.444 → 0.034).
Screenshots do dashboard OpenRouter:
Sonnet: Poder bruto, mas fatura salgada.
Claudin.io: Eficiente, low-cost, mesmo volume, bolso intacto.
Codex: Tokens voando, mas entrega capenga.
Tabela de chaves pra transparência:
| Modelo/Chave | Gasto Total | Limite |
|---|---|---|
| Claude Sonnet 4.5 (sk-or-v1-e0e...) | $0.444 | Ilimitado |
| OpenAI GPT-5 Codex (sk-or-v1-f95...) | $0.446 | Ilimitado |
| Auth: claudin.io (sk-or-v1-6f...) | $0.034 | Ilimitado |
Por Que Isso Muda o Jogo (Sem Hipérbole)
Não tô aqui pra dizer que o claudin.io é "melhor" que Sonnet ou Codex, longe disso. O Sonnet é rei em profundidade (e me surpreendeu com aqueles testes extras). Mas pra tarefas como essa (codificação básica, protótipos rápidos), ele é um provedor acessível que mantém o custo controlado. Junte com um agente parrudo pros casos edge, e você tem: velocidade, economia e zero rate limit hell.
Desenvolvi isso porque cansei de escolher entre qualidade e falência. O roteamento curado (modelos + prompts) garante que queries simples vão pros "baratos/bons", e só escalam pros caros se precisar. Teste grátis no site, pluge sua API key do OpenRouter e veja na prática.
Vejam o benchmark no Google Drive aqui tem os códigos raw. O que rola com vocês? Já sofreram com custos de LLM?
Fonte: https://claudin.io
