Bad default: engine falls back to 128K token budget for model
Nadie ha tomado este issue todavía.
- Lenguaje dominante
- Shell
- Estrellas
- 11.2k
- Forks
- 1.9k
- Merge medio
- 14 h 16 min
- PR fusionados (30 d)
- 6
Descripción
Summary
When a routed model has no capability limits installed (or reports a zero context window), the agent engine silently falls back to a hardcoded 128,000-token prompt budget and drives context compaction against it. For large-context models (e.g. 1M-token Anthropic models) whose ids don't match a host-provided capabilities entry, this makes compaction fire ~8x too early (at ~102K tokens instead of ~800K+), causing avoidable summarization churn, latency, token cost, and quality loss.
We hit this integrating the SDK/engine into a host app. We can work around it host-side by always installing capabilities, but the engine's default is not sane and the fallback operator makes it worse.
Where it lives
In the bundled engine (@github/copilot, observed in 1.0.63 and 1.0.73; app.js, minified). The relevant compiled forms:
// module init
sen = .8, aen = .95, Nk = 128e3; // Nk == 128000
class LM { static DEFAULT_TOKEN_LIMIT = Nk; /* ... */ }
// CompactionProcessor.preRequest
s = r.capabilities?.limits?.max_prompt_tokens
|| r.capabilities?.limits?.max_context_window_tokens
|| Nk; // <-- falsy fallback to 128000
u = promptTokens + toolTokens;
d = u / s; // utilization
// compaction triggers when d >= 0.8 (background) / 0.95 (buffer exhaustion)
The same ... || Nk fallback is repeated in the session.usage_info emit, contextInfo, and getTokenLimits paths.
Two distinct problems
-
Falsy fallback (
||) instead of nullish (??).
A model that reportsmax_context_window_tokens: 0(a legitimately "unknown" signal) collapses to128000rather than being treated as unknown. This is compounded upstream: the@github/copilot-sdkclient'smodels.listhandler backfills missing limits with{ max_context_window_tokens: 0 }, so an un-capped model arrives at the engine with0and|| Nkturns it into 128K.0should not be coerced to the default via a truthiness check. -
No model-aware default.
Every un-registered model — including known large-window models — gets the same 128K budget. There is no per-family/default table and no way to distinguish "small model, 128K is right" from "1M-window model, 128K is catastrophically low."
Impact
- Large-context models compact at ~0.8 * 128000 ≈ 102K tokens regardless of their true window.
- Symptoms: premature/repeated context compaction, extra summarization round-trips, higher token spend and latency, degraded answer quality on long tasks.
- Silent: nothing in the default event payload surfaces the effective window that was used, so the "capped at 128K" cause has to be inferred from the model id. (We had to add host-side telemetry — reconstructing
max_prompt_tokens ?? max_context_window_tokens ?? 128000— to see it.)
Steps to reproduce
- Create a session with a large-context model whose id is not matched by any host-installed capabilities entry (so no
limitsreach the engine, or they arrive asmax_context_window_tokens: 0). - Send a turn whose prompt+tool tokens exceed ~102K but are well under the model's real window (e.g. 300K on a 1M-window model).
- Observe
session.compaction_startfiring even though the real window is nowhere near exhausted.
Expected
0/ missing limits should be treated as "unknown," not coerced to 128K (use??, or validate> 0).- Provide a sane, model-aware default (or at minimum a host-configurable default budget) so large-window models are not capped at 128K.
- Surface the effective token limit the engine used in the compaction /
usage_infotelemetry so the applied budget is observable without host-side reconstruction.
Suggested fixes
- Change the fallback chain from
a || b || Nkto nullish/> 0validation so a real0isn't silently replaced. - Add a model-aware default table, or accept an explicit host-supplied default token budget on session config.
- Emit the resolved effective prompt-token limit alongside compaction and
session.usage_infoevents.
Environment
- Engine:
@github/copilot1.0.63(also reproduced against1.0.73via@github/copilot-next). - SDK:
@github/copilot-sdk1.0.0(zero-window backfill also present in1.0.7).
Related
The SDK-side zero-window backfill (@github/copilot-sdk models.list handler) contributes to problem (1). Happy to cross-file there if the SDK is the preferred owner for that half.
Guía de contribución
Primeros pasos
- Lee el issue completo y luego la guía de contribución del proyecto.
- Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
- Haz un fork del repositorio y trabaja en una rama.
- Abre un pull request que haga referencia al número del issue.
Línea de trabajo
Empieza con la app.js incluida y sigue CompactionProcessor.preRequest, el fallback repetido en session.usage_info, contextInfo y getTokenLimits, además del handler de models.list del SDK. Verifica el comportamiento con un límite cero o ausente mediante los pasos de reproducción y, después, define cómo se debe resolver y exponer el límite efectivo de tokens del prompt en compaction y en la telemetría de uso.
Escrito por el modelo de indexación a partir del texto del issue.
Evaluación
- Stack tecnológico
- javascript
- Área
- cli, observability
- Tipo de issue
- Error
- Dificultad
- 5/5
- Tiempo estimado
- Más de una semana
- Estado de actividad
- Tranquilo
- Claridad
- Bastante claro
- Aptitud para principiantes
- 35/100