BookinglyTech News
Inteligencia artificial

PennyWyze, un CLI que comprueba si necesitas el Claude más caro

El proyecto de OSLabs lanza tu prompt contra Opus, Sonnet y Haiku con tus propios ejemplos etiquetados, mide aciertos y calcula el coste real de API para quedarse con el más barato que aprueba.

2 min de lecturaDev.to0 vistas

Tres desarrolladores de OSLabs han publicado PennyWyze, un CLI de código abierto que responde a una pregunta concreta: cuál de los niveles de Claude —Opus, Sonnet o Haiku— es el más barato que sigue cumpliendo tu listón de calidad. Se le da el prompt que ya usas en producción y un puñado de ejemplos con la respuesta que ya sabes que es correcta. La herramienta los lanza contra cada nivel, mide aciertos y calcula el gasto con los tokens que devuelve la propia API, no con una estimación.

Qué entra y qué sale

Dos entradas: el prompt tal cual lo envías en producción y un golden dataset en JSONL con pares de entrada y respuesta esperada, del estilo {"input": "me han cobrado dos veces este mes", "expected": "facturación"}. Después se lanza con pennywyze audit --prompt prompt.md --dataset dataset.jsonl --pass-rate 90, donde el umbral de pass-rate marca el mínimo que estás dispuesto a aceptar. El informe trae, por modelo, la precisión y el coste mensual proyectado a tu volumen real.

En una de las auditorías que enseñan, con 50 preguntas: opus acertó 49, sonnet 48 y haiku 49. En dinero, 205,94 dólares al mes el primero, 77,30 el segundo y 26,26 el tercero. El veredicto del CLI fue pasarse a haiku y ahorrar unos 179,68 dólares al mes. La auditoría entera costó 0,15 dólares.

Ahí está lo interesante del ejercicio: sonnet quedó por debajo de los otros dos y costaba casi el triple que haiku. En esa tarea, la diferencia de precisión no justificaba el sobreprecio.

La corrección es estricta, y eso recorta el alcance

Antes de comparar, el CLI normaliza ambas partes: fuera comillas envolventes, bloques de código, diferencias de mayúsculas y puntuación final. Luego exige coincidencia exacta. Si tu aplicación espera la palabra "facturación" y el modelo contesta "creo que es facturación", cuenta como fallo, y es a propósito: en producción eso rompe el parseo. El precio de esa estrictez es que hoy solo vale para tareas con una única respuesta correcta —clasificación, extracción de campos, enrutado— y no para generación abierta. La evaluación con un LLM como juez está en la hoja de ruta.

Instalarlo es un npm install -g pennywyze, una clave de Anthropic en un .env y ejecutar la primera auditoría.

El proyecto no nació así. El equipo arrancó con memoria de conversación, para dejar de reenviar el historial completo en cada mensaje, y lo abandonó al encontrarse con Mem0, Zep y Letta ya instalados en ese terreno y con Anthropic enviando compactación automática de contexto.

De fondo queda una decisión que casi nadie revisa. Elegir el modelo más capaz cuando montas la primera versión de una función tiene sentido; el problema es que ese default se congela. Lo que frena la revisión no es la duda, es el trabajo de montar un banco de pruebas con dataset y criterio de corrección. PennyWyze es ese banco de pruebas, y el repo es el sitio donde ver si aguanta.