Skip to content

fix: restaurar max_tokens=512 y dejar de matar generaciones lentas - #127

Merged
sergi-torres merged 1 commit into
mainfrom
fix/restore-512-cap
Jul 28, 2026
Merged

fix: restaurar max_tokens=512 y dejar de matar generaciones lentas#127
sergi-torres merged 1 commit into
mainfrom
fix/restore-512-cap

Conversation

@sergi-torres

Copy link
Copy Markdown
Owner

Este commit se subió a fix/106-max-tokens después de que se mergeara el PR #123, así que no llegó a main. Hoy main tiene 320 y timeout de 8 s, que es justo lo contrario de la decisión tomada.

Decisión (owner, 2026-07-28)

La demo es un vídeo editado, no una ejecución en vivo cronometrada, así que la prosa completa vale más que un peor caso corto.

Qué cambia

  • max_tokens vuelve a 512. Medido en las diez generaciones registradas de bob/sessions/Sprint_1/baseline_eval.md: la salida más larga fueron 415 tokens y las diez cerraron frase. Bajar a 320 recortaba prosa real, no holgura.
  • HARD_TIMEOUT_SECONDS: 8 s → 15 s. El 8 era el número del SLA usado como umbral de muerte: no existía ninguna banda en la que una generación llegue tarde pero funcione. Una llamada condicionada de 8,4 s se reintentaba y acababa fallando en vez de devolverse, y eso salía como 503 intermitente.
  • Aborto del cliente en frontend/src/lib/api.ts: 10 s → 20 s, para que el navegador no cancele peticiones que el backend estaba a punto de contestar.

El SLA de docs/MVP.md no cambia: se sigue midiendo, pero sobre resultados en vez de imponerlo descartándolos.

Por qué importa ahora

Verificado ayer contra la app arrancada de verdad: POST /api/generate tardó 9,8 s y devolvió 200 con las dos columnas, RAG y Passport firmado. Con la configuración que hay hoy en main, esa misma petición habría muerto en el timeout de 8 s y el navegador la habría abortado a los 10.

Verificación

pytest backend/tests/test_generation_params.py -q  -> 3 passed
npx vitest run (frontend)                          -> 107 passed

🤖 Generated with Claude Code

Reverts the cap to 512 and moves the fix to where the defect actually was.

The cap was never wasting anything: across the ten recorded generations in
bob/sessions/Sprint_1/baseline_eval.md the longest output was 415 tokens and
all ten ended on a complete sentence. Lowering it to 320 would have cut real
prose to buy latency headroom.

The real problem is that HARD_TIMEOUT_SECONDS was the MVP's *SLA* number
(<8s P95) used as a *kill* threshold, so no band existed in which a
generation is late but working: a conditioned call measured at 8.4s worst
case got retried and ultimately failed rather than returned, surfacing as an
intermittent 503. The timeout goes to 15s (~1.8x that worst case). The SLA
is unchanged and still tracked — now measured on results rather than
enforced by discarding them.

The client abort in frontend/src/lib/api.ts goes 10s -> 20s for the same
reason: at 10s the browser would cancel requests the backend was about to
answer, showing a timeout for a generation that had in fact succeeded.

Decision by the repo owner (2026-07-28): the demo is an edited video, not a
live timed run, so complete prose is worth more than a shorter worst case.

Verified: pytest backend/tests/test_generation_params.py -q -> 3 passed;
npx vitest run (frontend) -> 107 passed.

Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
@vercel

vercel Bot commented Jul 28, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

Project Deployment Actions Updated (UTC)
author-ai Ready Ready Preview, Comment Jul 28, 2026 10:05pm

@sergi-torres
sergi-torres merged commit 9068d9f into main Jul 28, 2026
8 checks passed
@sergi-torres
sergi-torres deleted the fix/restore-512-cap branch July 28, 2026 22:06
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant