Contexto
Edu detecta el coste de la API de Anthropic del Bibliotecario y plantea (a raíz de evaluar el relay frugalrelay.me, descartado — ver Idea Market) si optimizarlo. Auditoría + cuantificación con datos reales en s83 (25-05-2026).
Cuantificación (factura Anthropic, 01–25 may 2026)
- Total: $50,95/mes. Sonnet 4.6 $43,68 (86%) · Haiku 4.5 $7,26 (14%). Todo bajo una sola API key (
crearack-ingest). - El foco es el ingest deep (Sonnet): ~215 sesiones “deep” /30d; 60% de ingests se filtran gratis en TIER 1. El componente más caro de Sonnet es el
output. bib_ask, wiki-translate → Gemma (Google, no Anthropic). Reindex AST → sin LLM.
Palancas
| Palanca | Estado |
|---|---|
| P1 · recortar ingest Sonnet (max_tokens 10K→5K, iter 25→12) | ✅ Hecho (d002d95/eeeb5e8) |
| P5 · Sync Cascade ediciones, no body completo | ✅ Hecho (PR #84) |
Prompt reforzado + fix bib_search_nodes + andamiaje A/B | ✅ Hecho (PR #41 Pro + #85 ws) |
Pre-carga de contexto del grafo (opt-in BIB_INGEST_PRELOAD_CONTEXT) | ✅ Hecho (fbfef54 Pro + d6374cb ws) |
| P4 · Sonnet→Haiku como deep model | ✅ Hecho s84 (25-05) · PR Pro #42 + ws #86 |
| B · instrumentar coste en Pulse | ✅ Implementada s147 (17-06) · migración D1 0044 (bib_wiki_log += model/input/output/cache_read/cache_write/cost_usd) · bib_ingest.py (ambos repos) calcula cost_usd real e inyecta model+tokens+coste en wiki_log_event(ingest) · wikiLogEvent+tools.ts persisten · hot-cache agrega cost_30d por modelo · tarjeta “Coste IA · 30 d” en PulsePanel. El coste cubre TODAS las operaciones Anthropic del Bibliotecario (no solo ingest): curator, lint-contradictions, drift-batch y triage de archive-answer cablean su coste Haiku real (haikuCostUsd) al bib_wiki_log (s147, 2ª tanda). bib_explain_node/bib_generate_tour (manuales, raros) reportan coste en su respuesta pero no van a bib_wiki_log. Sin datos hasta reactivar el Ingest (1-jul). |
A/B Sonnet 4.6 vs Haiku 4.5 (sandbox dry-run, PR #24)
Hallazgo: la brecha de calidad era de instrucción, no de capacidad — el prompt condicionaba las entities de servicio a __all__; Haiku lo seguía literal, Sonnet lo infería. Con el criterio explícito en el SYSTEM_PROMPT, Haiku 4.5 (generación anterior) iguala a Sonnet 4.6 en cobertura y profundidad.
Coste real medido (mismo PR #24, tokens de los logs)
| Configuración | $ real | Calidad | Ahorro vs Sonnet |
|---|---|---|---|
| Sonnet 4.6 (prompt original) | $0,460 | 3 págs (baseline) | — |
| Haiku 4.5 (prompt original) | $0,073 | 2 págs, peor (omite servicios) | — |
| Haiku 4.5 (prompt reforzado) | $0,263 | 5 págs ✅ | 51% |
| Haiku 4.5 (prompt prod, integrado) | $0,226 | 3 págs ✅ profundidad | 51% |
| Haiku 4.5 + prompt + pre-carga | $0,184 | 3 págs ✅ | 60% |
Clave: el ahorro NO es el ~85% del precio nominal, sino ~60%, porque Haiku gasta ~2× tokens (más iteraciones + más verboso) para igualar la calidad. Cada optimización de proceso (mover trabajo del LLM al código) recupera parte de esa brecha: la pre-carga de contexto bajó el input de Haiku 72K→59K (−18%) y subió el ahorro de 51% a 60%, manteniendo las páginas.
Bugs / mejoras detectadas
bib_search_nodesname→query(fallaba siempre, degradaba anti-duplicados también en Sonnet). Arreglado (PR #41/#85).- Loop ante
stop_reason=max_tokens: aborta a media página. Pendiente (task #70). - Lint determinista de slugs canónicos: cierra la inconsistencia residual mejor que el prompt. Pendiente (task #70).
Decisión y próximos pasos
Ejecutado en s84 (25-05-2026). A/B sobre PR #28 (refactor transversal, distinto al #24): Sonnet baseline $0,42 · Haiku + lint + pre-carga + techo 8k $0,083 (−80%) igualando cobertura y profundidad · Sonnet + pre-carga $0,29 (−31%, confirma el bonus #4). Único modo de fallo de Haiku (slugs con tildes que el MCP rechaza) cerrado con lint determinista de formato kebab-ascii. Adoptado
BIB_INGEST_DEEP_MODEL=claude-haiku-4-5+ pre-carga ON +DEEP_MAX_TOKENS=8000en ambos repos. Las 4 optimizaciones de la task #70 (lint, manejomax_tokens, afinado pre-carga, medición pre-carga en Sonnet) implementadas. Rollback: 1 env var.
Fase de pruebas/optimización consolidada en s83. La decisión de sustituir Sonnet por Haiku se aborda en la próxima sesión (task #70):
- Implementar lint de slugs + manejo de
max_tokens+ afinar pre-carga (todas mejoras netas). - Prueba conjunta (las 4 optimizaciones a la vez) Haiku vs Sonnet sobre el PR #28 (transversal, distinto al #24 para no sobre-ajustar).
- Si Haiku iguala calidad en #28 → cambiar
BIB_INGEST_DEEP_MODELa haiku + activar pre-carga + recalcularDEEP_MAX_TOKENS, en ambos repos (Regla 24).
Andamiaje de A/B reutilizable ya en producción (opt-in): BIB_INGEST_DRY_RUN, FORCE_DEEP, PROMPT_EXTRA_FILE, PRELOAD_CONTEXT, DEEP_MAX_TOKENS.
Consecuencias
- Ahorro de P1+P5 ya en producción (verificar factura del próximo mes).
- Si se adopta Haiku: ~60% menos en el componente deep, sin pérdida de calidad.
- Frugalrelay y similares: descartados en [[workspace—guias—idea-market]].
Véase también
- [[feature—biblioteca—sync-cascade-ediciones-puntuales]]
- [[entity—workspace—service—anthropic-lib]]