← Back to PRs

#18721: fix: prefer configured contextTokens over model catalog in status display

by MisterGuy420 open 2026-02-17 00:49 View on GitHub →
stale size: XS trusted-contributor
Fixes #18696 When `contextTokens` is set in agent config (e.g., 1M for Claude Max), the status display now correctly shows the configured value instead of the model's built-in contextWindow (200K). The bug was in `commands-status.ts` where the explicitly passed `contextTokens` parameter (derived from model catalog) was overwriting the agent defaults. <!-- greptile_comment --> <h3>Greptile Summary</h3> Fixes a bug where the `/status` display showed the model catalog's built-in `contextWindow` (e.g., 200K) instead of the user-configured `contextTokens` (e.g., 1M for Claude Max). The one-line fix in `buildStatusReply` ensures `agentDefaults.contextTokens` takes precedence over the `contextTokens` parameter (derived from model catalog lookup) when assembling the agent config object passed to `buildStatusMessage`. - The `??` (nullish coalescing) correctly falls back to the param-provided `contextTokens` when `agentDefaults.contextTokens` is not configured - The fix aligns with how `buildStatusMessage` itself resolves context tokens (`entry?.contextTokens ?? args.agent?.contextTokens ?? lookupContextTokens(model)`) — the agent config value now correctly survives into the `args.agent.contextTokens` slot <h3>Confidence Score: 5/5</h3> - This PR is safe to merge — it is a minimal, correct one-line fix with no risk of regressions. - The change is a single line that uses nullish coalescing to prefer the configured contextTokens over the model-catalog-derived value. The logic is consistent with how contextTokens is resolved elsewhere in the codebase (e.g., resolveContextTokens, buildStatusMessage). The fallback behavior is preserved when no agent default is configured. - No files require special attention. <sub>Last reviewed commit: 57759ce</sub> <!-- greptile_other_comments_section --> <!-- /greptile_comment -->

Most Similar PRs