Cargando datos de benchmark…
EyesInAI·Cargando datos de benchmark en vivo
Una corrida de director es un modelo orquestador que recorre una base de código, destila lo que encuentra en trabajos acotados de una sola tarea y despacha un agente worker por trabajo, cada uno en su propio git worktree aislado, para que los workers no choquen. Después, el director revisa cada diff y lo vuelve a verificar de forma independiente antes de que se abra un pull request; la columna de verificación de abajo registra lo que esa comprobación realmente ejecutó. El uso de tokens se mide en toda la corrida, por worker. El costo facturado y el contrafactual a precio de lista se reportan como cifras separadas y nunca se suman.
La plataforma de licitaciones de Arkanu solo podía registrar una respuesta del cliente, o dar de alta una pregunta, mediante un agente que escribía una migración SQL que una persona pegaba en Supabase Studio y que luego se integraba como PR. Medido: 46 de las 65 migraciones desde el 2026-08-25 (70 %) fueron cambios operativos de datos, no de esquema. El director recorrió las rutas de escritura en línea, encontró tres restricciones que habrían roto cada una una implementación ingenua, y despachó un worker por cada pieza acotada: primero las funciones de base de datos, y después la interfaz y la superficie de preguntas en paralelo. El director revisó cada diff y lo volvió a verificar de forma independiente; esa revisión detectó un defecto en el trabajo de cada uno de los tres workers.
| Tarea | Repositorio | Modelo | Turnos | Tokens de salida | Escritura en caché | Lectura de caché | Costo de listacontrafactual | Facturadocobrado | PR | Verificación |
|---|---|---|---|---|---|---|---|---|---|---|
| promote_client_answer/withdraw_client_answer: anexar un hecho + fact_link, nunca hacer UPDATE de status; rechazar cualquier citation_verdict que no sea 'verified' | wm-mexico-takeoff | claude-opus-5 | 37 | 20,609 | 123,116 | 2,463,147 | USD 2.98 | USD 0.00 | integrado | el director volvió a ejecutar semicolon + la suite completa (304 pasan, 2 fallas comprobadas por stash como preexistentes); la migración se EJECUTÓ después en Studio y se confirmó en vivo con service-role: 3 funciones SECURITY DEFINER, 2 políticas INSERT, total de la licitación sin cambios. DEFECTO DETECTADO EN LA REVISIÓN: la autorización resolvía al cliente propietario solo a través de line_item_id, y los 77 hechos objetivo lo tienen en NULL, así que todos caían en la rama de administrador y un gerente de Arkanu no podía promover nada del rezago para el que existe la función. El director agregó dos rutas de resolución más y las extrajo a un único client_owning_fact() compartido, invocado por ambos verbos. |
| /respuestas: la superficie para el cliente que lista cada respuesta escalada del cliente, con promover/retirar una por una y una justificación escrita | wm-mexico-takeoff | claude-opus-5 | 51 | 18,493 | 147,000 | 4,677,753 | USD 4.40 | USD 0.00 | integrado | el director ejecutó tsc --noEmit (exit 0) sobre el master integrado, luego verificó el despliegue por sha EXACTO en /api/version (ce65b78) y sondeó la ruta (307 hacia el inicio de sesión, correcto para una superficie de cliente). Se mantuvo la restricción central: la interfaz llama a promote_client_answer por RPC y no contiene ninguna copia en TypeScript de ninguna protección, de modo que la ruta SQL y la ruta del clic no pueden divergir. |
| registrar / adjuntar / retirar una pregunta del cliente desde la página de la fila, más las políticas RLS INSERT que faltaban | wm-mexico-takeoff | claude-sonnet-5 | 66 | 26,715 | 147,536 | 7,001,424 | USD 2.26 | USD 0.00 | integrado | el director volvió a ejecutar la suite y confirmó que el handle se genera mediante handle_allocate (idempotente sobre entity_id) y que el retiro es un ANEXADO sin ruta de borrado. La migración se EJECUTÓ después y se confirmó en vivo. DEFECTO DETECTADO EN LA REVISIÓN: el SELECT del recibo estaba comentado, así que Studio habría impreso 'Success. No rows returned', una cadena idéntica a la de una ejecución en el proyecto equivocado, una ejecución sin efecto y una ejecución parcial. El director lo activó; un segundo PR (#326) corrigió después el valor esperado erróneo del PROPIO director en ese recibo, que fallaba en una ejecución correcta. |
Gasto de tokens nuevos del worker: 483,469 (salida + escritura en caché). Las lecturas de caché son el mismo contexto releído en cada turno, no tokens nuevos.
Presupuesto: tope autorizado de 3M de tokens NUEVOS; se usaron 483,469 tokens NUEVOS (16 %). Los 14.1M de lectura de caché son throughput y se reportan por separado, nunca sumados al gasto. USD 0.00 FACTURADO: los workers ejecutaron claude -p sin ANTHROPIC_API_KEY en el entorno (verificado antes del lanzamiento), por lo que los cubrió el plan Max; cada list_cost_usd aquí es un contrafactual a precio de lista, no una factura. Tres hallazgos del recorrido definieron el diseño de las tareas, y cada uno habría roto una implementación ingenua: (1) learned_fact es de solo anexado y status/confidence están en la lista de inmutables, por lo que la promoción no puede ser un UPDATE: anexa un hecho más un fact_link supersedes; (2) RLS era solo SELECT en las cuatro tablas, así que una interfaz perfecta se habría mostrado y habría fallado en silencio; (3) un trigger de cadena de hashes es dueño de prev_sha256/row_sha256/chain_seq bajo un bloqueo exclusivo de tabla. El orden importó: la migración corrió primero para que el worker de la interfaz tuviera una firma de función real que invocar, en lugar de una inventada. La línea decisiva de toda la corrida es una negativa: citation_verdict debe ser 'verified'. La clienta cita nuestros propios mensajes dentro de sus respuestas, y el 2026-08-25 un agente leyó un eco sin marcar como propuesta de ella y lo escribió en un PR ya integrado. Esa protección ahora vive en la base de datos, por lo que no la puede eludir una interfaz, un agente ni una migración apresurada. Límite honesto: la capacidad se entregó, el rezago no se resolvió. Quedan 77 respuestas de clientes escaladas y sin promover, y /respuestas todavía no ha sido usada por una persona; hasta que lo sea, «utilizable por la clienta» es una intención de diseño, no un hallazgo.
Auditoría de toda la superficie de la licitación de Walmart Atlacomulco (28 renglones, MX$7,992,126.64) después de una sesión en la que tres caídas de RLS estaban en verde en la base de datos y a oscuras en la página renderizada. La aritmética, los contadores de preguntas, las citas, las rutas, los documentos y la cadena de auditoría resultaron sólidos. El recorrido encontró la clase de defecto que predice CLAUDE.md: una corrección que se aplicó en un lugar y sobrevivió en otros. El derivation_basis visible para el cliente de PAV-1 todavía recita una cifra retractada de PAV-7 y un total reemplazado, aunque la cantidad almacenada es correcta. No tenía ruta de escritura en el producto.
| Tarea | Repositorio | Modelo | Turnos | Tokens de salida | Escritura en caché | Lectura de caché | Costo de listacontrafactual | Facturadocobrado | PR | Verificación |
|---|---|---|---|---|---|---|---|---|---|---|
| Extender reviseNote() para cubrir line_item.derivation_basis, el tercer campo de prosa visible para el cliente, que no tenía ruta de escritura | wm-mexico-takeoff | opus | 40 | 14,551 | 99,459 | 3,472,297 | USD 3.09 | USD 0.00 | abierto | Reverificado por el director, no aceptado por reporte: tsc --noEmit exit 0; eslint exit 0 en ambos archivos modificados; lista de permitidos probada de forma independiente con 11 pares objetivo/campo: quantity, unit_price, amount y protected fueron todos RECHAZADOS, por lo que la invariante del archivo de «nunca toca un número» se hace cumplir en tiempo de ejecución, no solo por tipos. |
Gasto de tokens nuevos del worker: 114,010 (salida + escritura en caché). Las lecturas de caché son el mismo contexto releído en cada turno, no tokens nuevos.
Presupuesto: 3M de tokens nuevos (salida + escritura en caché) declarados antes de lanzar; se usaron 114,010 (3.8 %). Las lecturas de caché se reportan por separado y no cuentan contra el tope. Los workers corrieron sin ANTHROPIC_API_KEY en el entorno (verificado con ps sobre el pid en vivo), por lo que el costo facturado es USD 0.00 y las cifras de lista son contrafactuales del plan Max. Segundo hallazgo, sin cambio de código: solo hay 5 dependencias de fuente declaradas, así que el banner de vigencia informa '2 notas se apoyan en una fuente que ya no está vigente' mientras otros dos hallazgos visibles para el cliente todavía afirman la tabla de volúmenes C09L retirada como autoridad vigente. Se dejó a una persona: corregir la prosa dirigida al cliente es, por diseño, un acto humano.
Un recorrido completo del motor de licitaciones de wm-mexico-takeoff: lógica de cálculo, extracción DXF/EMS, cada entrada de licitación y la ruta normal de leer, actualizar y finalizar una licitación. Tres defectos corregidos por workers acotados y dos hallazgos remitidos al operador como decisiones de producto, no como errores. El más costoso fue el IVA: la tasa del 16 % estaba declarada en exactamente UN archivo, la pantalla en vivo de la reunión con el cliente, que mostraba un total con impuestos mientras las exportaciones .xlsx y .csv de la MISMA licitación terminaban en una cifra antes de impuestos bajo una etiqueta TOTAL sin más, con una diferencia de MX$803,371 en la licitación de Atlacomulco, y el libro de cálculo es el artefacto que se envía por correo y del que se cotiza. Segundo, setUnitPrices (la acción detrás de esa misma pantalla de reunión) leía solo `id, quantity` y escribía cualquier fila que se le entregara, así que escribir un precio sobre una cifra ya firmada frente al cliente la cambiaba en silencio, eludiendo la ceremonia de motivo y desbloqueo que updateLineItem exige; PresentRow ni siquiera incluía completed_at. Tercero, la ruta de API medida estaba fijada al claude-opus-4-8, ya superado, mientras que las 10 llamadas de llenado de producción más recientes corrían con claude-opus-5 por la ruta de la suscripción. Una hipótesis se descartó en lugar de publicarse: seis cálculos independientes de totales usan `typeof x === 'number'` contra columnas numeric de Postgres, pero una consulta en vivo confirmó que PostgREST emite aquí números JSON reales, por lo que esos totales son correctos y no se levantó ningún hallazgo.
| Tarea | Repositorio | Modelo | Turnos | Tokens de salida | Escritura en caché | Lectura de caché | Costo de listacontrafactual | Facturadocobrado | PR | Verificación |
|---|---|---|---|---|---|---|---|---|---|---|
| Una sola tasa de IVA: extraer lib/totals.ts para que la pantalla de la reunión y ambas exportaciones coincidan | wm-mexico-takeoff | claude-opus-5 | 37 | 12,569 | 91,281 | 2,725,974 | USD 2.59 | USD 0.00 | integrado | El director volvió a ejecutar npx tsc --noEmit de forma independiente: exit 0, limpio. Invariancia aritmética comprobada en seis casos, incluidos los dos subtotales reales de licitaciones vivas: la fórmula anterior y la nueva son idénticas (5,021,069.06 -> 803,371.05 de IVA / 5,824,440.11 de total). |
| Respetar el bloqueo de firma en la ruta de precios masivos (setUnitPrices + tabla de presentación) | wm-mexico-takeoff | claude-opus-5 | 53 | 20,034 | 132,503 | 5,367,400 | USD 4.51 | USD 0.00 | integrado | El director volvió a ejecutar npx tsc --noEmit de forma independiente: exit 0, limpio; scripts/check_behaviour_claims.py 16 ok / 0 rotos / 0 indeterminados, incluido present-view-prices-only, que verifica este archivo. Delta de lint 0 frente a la línea base con stash. |
| Fijar la ruta de llenado por API medida a claude-opus-5, no al opus-4-8 ya superado | wm-mexico-takeoff | claude-sonnet-5 | 20 | 4,646 | 60,478 | 1,453,831 | USD 0.87 | USD 0.00 | integrado | El director volvió a importar el módulo de forma independiente: MODEL = claude-opus-5, MAX_TOKENS = 24000. pytest 1 fallida / 167 aprobadas; el director confirmó que esa única falla (test_migration_hygiene) ya existía en el checkout main sin modificar, en lugar de fiarse de la línea base con stash del worker. |
Gasto de tokens nuevos del worker: 321,511 (salida + escritura en caché). Las lecturas de caché son el mismo contexto releído en cada turno, no tokens nuevos.
Se revisó contra origin/master, no contra la rama del checkout: el master local estaba dos commits atrasado, justo la trampa que produce hallazgos sobre código que nadie ejecuta. Las cifras de los workers son textuales de cada envolvente de uso de claude -p --output-format json; la fila del director es la envolvente medida de esta sesión orquestadora. Plan Max sin ANTHROPIC_API_KEY en el entorno de ningún worker (verificado por pid), así que el facturado es USD 0.00 y list_cost es el contrafactual, no dinero cobrado. Los tokens NUEVOS de todos los workers (salida + escritura en caché) fueron 321,511 frente a un tope declarado de 3M. Dos hallazgos NO los corrigió deliberadamente un worker porque son decisiones de producto: ninguna ruta de código asigna bid.status='ready' (el ciclo de vida se detiene en 'review'; falta construir un paso de finalización, aunque la restricción de la base de datos, un trigger de bloqueo y una insignia de la interfaz implican que existe), y fill/scope_gate.py es código muerto, nunca importado, construido para un asistente que se convirtió en el bot alojado de EyesInAI. Ambos se remitieron al operador, quien los encargó como trabajo de seguimiento. Nota de proceso: el worker 2 escribió archivos en el worktree del worker 1 por ruta absoluta; el worker 1 lo detectó, se negó a confirmar un diff que no compilaría en un checkout limpio y lo informó; no se perdió trabajo.
El director recorrió cinco subsistemas en línea, destiló tres defectos acotados y despachó un worker por cada corrección, cada uno en un git worktree aislado y en su propia rama. El director revisó cada diff y lo volvió a verificar de forma independiente antes de que se abriera cualquier PR.
| Tarea | Repositorio | Modelo | Turnos | Tokens de salida | Escritura en caché | Lectura de caché | Costo de listacontrafactual | Facturadocobrado | PR | Verificación |
|---|---|---|---|---|---|---|---|---|---|---|
| enforceCitations eliminaba citas correctas que llevaban una cadena de consulta (query string) | eyesinai | claude-sonnet-5 | 22 | 5,192 | 96,616 | 1,621,074 | USD 1.14 | USD 0.00 | integrado | los nuevos fixtures se comprobaron por stash como fallidos en el código anterior; pasan las 25/25 verificaciones de linkfab; tsc limpio |
| agregación de la clasificación sin duplicados; 18 filas tenían precio de un proveedor equivocado | eyesinai | claude-opus-5 | 40 | 16,265 | 98,019 | 2,745,674 | USD 2.76 | USD 0.00 | integrado | repetición en vivo de la forma de los datos en la red: 0 diferencias ajenas a precios en 249 resultados; build con exit 0 |
| el gateway construía un cliente HTTP nuevo por solicitud en 3 puntos de la ruta crítica; expulsión de caché O(n) | ai-bench-tools | claude-sonnet-5 | 29 | 7,353 | 75,941 | 2,269,561 | USD 1.25 | USD 0.00 | integrado | cargo test 57/0, incluida la invariante de que traced es igual a untraced; clippy idéntico a la línea base |
Gasto de tokens nuevos del worker: 299,386 (salida + escritura en caché). Las lecturas de caché son el mismo contexto releído en cada turno, no tokens nuevos.
Todos los modelos corrieron en un plan de suscripción sin clave de API en el entorno: el costo facturado marginal fue de USD 0.00; list_cost_usd es el contrafactual a precio de lista. El gasto de tokens nuevos de los workers fue de ~300k (28.8k de salida + 271k de escritura en caché) frente a un tope de 3M; la cifra de 6.6M de lectura de caché es el mismo contexto releído de la caché en cada turno, no gasto nuevo.
Seguimiento de una sola tarea señalado por el worker de la corrida 1: el reporte de ahorros/portal/MCP fijaba el precio de los turnos con un mapa indexado por id donde gana el último, de modo que un turno atendido por groq podía costearse con la tarifa de otro proveedor. La corrección resuelve primero el precio propio del host que atendió y conserva el comportamiento anterior exacto como respaldo, de modo que ninguna fila que tenía precio queda sin precio. La tercera copia artesanal del mapa de precios se eliminó en favor de un único helper compartido.
| Tarea | Repositorio | Modelo | Turnos | Tokens de salida | Escritura en caché | Lectura de caché | Costo de listacontrafactual | Facturadocobrado | PR | Verificación |
|---|---|---|---|---|---|---|---|---|---|---|
| precios por proveedor en savings-agg; eliminar la tercera copia del mapa de precios | eyesinai | claude-opus-5 | 39 | 15,483 | 98,926 | 3,068,472 | USD 2.91 | USD 0.00 | integrado | el nuevo check-savings-pricing.mts se comprobó por stash: el caso compuesto devolvía USD 0 de nvidia donde USD 0.75 de groq era lo correcto en el código anterior; 8/8 pasan con la corrección; build con exit 0 |
Gasto de tokens nuevos del worker: 114,409 (salida + escritura en caché). Las lecturas de caché son el mismo contexto releído en cada turno, no tokens nuevos.
Las cifras del director son el delta de la sesión desde que se registró la fila de la corrida 1 (misma base de medición: esa fila cubría la sesión hasta ese punto). Todos los modelos en un plan de suscripción sin clave de API: facturado USD 0.00; list_cost_usd es el contrafactual a precio de lista. El gasto de tokens nuevos del worker fue de ~114k (15.5k de salida + 99k de escritura en caché) frente a un tope declarado de 1M.
Una revisión de seguridad en línea dirigida por el director, sin agentes worker: una corrección de seguridad de esquema llega a producción como una migración SQL en Studio aplicada por el operador, nunca por un agente, por lo que la ruta de workers con worktree/PR no aplica. servicerole-eye, los advisors de supa-eye y un sondeo PostgREST en vivo con la clave anon sobre las 118 tablas públicas encontraron que la clave pública del navegador lee seis tablas. Tres son públicas por diseño. Tres filtraban: admin_notes publicaba TODAS las filas mediante una política USING(true), incluidos los envíos de contacto de visitantes con kind='request' (correo en el cuerpo), que en otros lugares solo se leen con service-role; system_prompts y prompt_scripts exponían sus filas de nivel administrador mediante políticas llamadas literalmente 'Admin prompts readable by all' y 'Anyone can view admin scripts'. La aplicación propietaria (second-brain) lee estas dos últimas con service-role detrás de is_user_admin(), así que cerrar la ruta anon no puede romperla, y las páginas públicas /notes de eyesinai conservan todos los tipos de visualización. Una migración restringió admin_notes a kind<>'request' y eliminó las dos políticas de lectura de administrador abiertas a todos. Nuevo sondeo tras aplicarla: filas request de 3 a 0, administrador en system_prompts de 16 a 0, administrador en prompt_scripts de 8 a 0, /notes sigue respondiendo 200.
Esta corrida no tiene agentes worker: la corrección se entregó como una migración de base de datos que aplica el operador, no como un cambio de código para el que un worker pudiera abrir un pull request, así que el director hizo todo el recorrido y la verificación en línea.
No se lanzaron workers claude -p: una corrección de seguridad de esquema se entrega como una migración en Studio (sql-migration-handoff), no como un PR de código en un worktree. Las cifras del director son la envolvente medida completa de esta sesión orquestadora (plan Max, por lo que facturado USD 0.00; list_cost es el contrafactual, no dinero cobrado). Verificado al sondear de nuevo la clave anon pública después de que el operador aplicó la migración. Endurecimiento pendiente: tres vistas SECURITY DEFINER public_* deberían ser security_invoker=true.