ember-memory-test/episodes/TRAZA_r6seccion1i1-el-coste-real-y-un-bug-que_S20260828.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD.md

episode_id	puente_flat	session_code	acto_dialogico	actor_flujo	criticidad_aegis	skill_dominante	fase_proyecto	tipo_semantico	summary_one_line	source_type	trust_boundary	created_at	relectura_tagged	forgejo_commit_sha
2672addb-db7c-42c1-9dc6-933aaf85adfb	TRAZA_r6seccion1i1-el-coste-real-y-un-bug-que_S20260828.R1_XX.ops.2.hot_inf.in.cc.es.000.MGQ_J.PMCFK_E.SGNFD	S20260828.SID3E411925EAA3	informar	multi_actor	low	TESSERA	operations	reflection	EPISODIO 1 — MEMORIA: [R6.seccion1.I1] El coste real, y un bug que resultó ser una	claude_code	internal	2026-08-29T01:33:16.549332+00:00	false	pending

El barrido corre en segundo plano. Te reporto lo que ya está establecido, que incluye un hallazgo que no esperaba.

—

[R6.seccion1.I1] El coste real, y un bug que resultó ser una buena noticia

Lo primero, la cifra que faltaba: el reordenador consume 435,5 tokens por búsqueda (419 de entrada, 16 de salida). Es mucho menos de lo que temía. Reporto tokens y no dólares a propósito: no conozco la tarifa vigente de OpenRouter y ponerla de memoria sería justo la cifra-sin-fuente que llevo todo el arco desmontando — multiplícalos por tu precio real.

Lo segundo, el bug. Probé dos variantes: mandar 320 caracteres de cada episodio, y mandar solo los títulos. Ahorro esperado: grande. Ahorro medido: 19,6 tokens, un 4,5 %. Eso no cuadraba, así que fui a mirar por qué.

fused_search publica el texto del episodio en un campo llamado content_snippet. Mi armador de prompt leía uno llamado content, que en esa salida no existe. Resultado: el cuerpo llegaba vacío siempre, y mis dos variantes eran el mismo experimento — por eso daban 0,25 y 0,24.

Y aquí está la buena noticia: eso significa que todo el ×2,05 que medí ayer se logró juzgando únicamente por títulos, sin que el modelo viera una sola línea del contenido de los episodios.

★ Insight ───────────────────────────────────── Una diferencia sospechosamente pequeña entre dos condiciones que deberían diferir mucho es una señal de bug, no de "las dos son equivalentes". El 4,5 % fue lo que delató el campo mal leído; si hubiera sido 40 %, el error habría pasado inadvertido y las conclusiones estarían torcidas. Un contrato de salida documentado (_serialize_point declara sus claves) sirve de poco si el consumidor no lo lee: el bug vivía en el lado que asumió el nombre del campo. ─────────────────────────────────────────────────

Tres consecuencias prácticas:

1. El resultado ×2,05 sigue siendo válido — se midió de verdad. Lo que cambia es su interpretación: se consiguió con menos información de la que yo creía.
2. Dar contenido real podría subirlo más. Es lo que está midiendo ahora el barrido.
3. La palanca "solo títulos" ya está probada y funciona: 0,24 de acierto con 415,9 tokens. Si el contenido real no aporta, esa es la configuración a desplegar — la más barata y la que menos expone tus episodios fuera del perímetro, porque solo viajan títulos.