fix: self-hosted model discovery ignores top-level context_size/context_length field#109368
fix: self-hosted model discovery ignores top-level context_size/context_length field#109368Mohl wants to merge 2 commits into
Conversation
f421609 to
5fcff30
Compare
|
Codex review: needs maintainer review before merge. Reviewed July 21, 2026, 3:10 AM ET / 07:10 UTC. Summary PR surface: Source +18, Tests +79. Total +97 across 2 files. Reproducibility: yes. from source and supplied live evidence: a Review metrics: none identified. Stored data model Root-cause cluster Members:
Proposal only: this assessment does not dispatch repair, suppress jobs, mutate sibling items, close, or merge anything. Merge readiness Overall follows the weaker of proof and patch quality, so missing proof can cap an otherwise strong patch. Rank-up moves:
Risk before merge
Maintainer options:
Next step before merge
Security Review detailsBest possible solution: Rebase or merge current Do we have a high-confidence way to reproduce the issue? Yes from source and supplied live evidence: a Is this the best way to solve the issue? Yes. Reading common provider-advertised fields at the existing discovery boundary, after the established llama.cpp field and before the default, is narrower and less error-prone than provider-specific special cases. AGENTS.md: found and applied where relevant. Codex review notes: model internal, reasoning high; reviewed against f4b37db18df4. Label changesLabel justifications:
Evidence reviewedPR surface: Source +18, Tests +79. Total +97 across 2 files. View PR surface stats
What I checked:
Likely related people:
What the crustacean ranks mean
Shiny media proof means a screenshot, video, or linked artifact directly shows the changed behavior. Runtime, network, CSP, and security claims still need visible diagnostics. How this review workflow works
|
…ze on self-hosted model discovery discoverOpenAICompatibleLocalModels only read contextWindow from model.meta.n_ctx_train (llama.cpp-specific), falling back to the hardcoded 128k default for any provider that advertises context length as a top-level field instead. Cortecs.ai's /v1/models response for glm-5.2 reports context_size: 1048576 (the model's real 1M-token window), but that field was ignored, so the catalog under-reported it as 128k/131k. This caused unnecessarily aggressive/premature compaction on sessions that had far more real headroom than the catalog believed. Fixes openclaw#109367 Co-Authored-By: Claude Opus 4.7 <[email protected]>
5fcff30 to
06b4d56
Compare
Closes #109367
What Problem This Solves
Resolves a problem where users configuring a self-hosted/custom OpenAI-compatible provider (e.g. Cortecs.ai) would see their model's context window massively under-reported by OpenClaw's catalog.
discoverOpenAICompatibleLocalModelsonly read a llama.cpp-specific nested field (meta.n_ctx_train) for context length, so any provider advertising context length as a top-level field on the/v1/modelsrow (a common convention outside the llama.cpp ecosystem) fell through to a hardcoded 128k default. Concretely: Cortecs'glm-5.2advertisescontext_size: 1048576(1M tokens, matching Z.ai's published spec), but OpenClaw's catalog reported it as ~131k. This caused premature/unnecessary auto-compaction and, in one observed case, a session-ending compaction timeout on a session that would have fit comfortably in the model's real context window.Why This Change Was Made
Added lookups for the common top-level field-name variants (
context_length,context_window,context_size) on the discovered model row, checked after the existingmeta.n_ctx_trainllama.cpp lookup (unchanged priority for that ecosystem) and before the hardcodedSELF_HOSTED_DEFAULT_CONTEXT_WINDOWfallback. This is additive only — no existing behavior for llama.cpp or providers without any of these fields changes.User Impact
Users configuring self-hosted/custom OpenAI-compatible providers that advertise context length as a top-level
/v1/modelsfield (Cortecs and similar cloud-aggregator-style APIs) now get the correct context window in OpenClaw's catalog, instead of a silently-wrong 128k default. This avoids unnecessary/premature auto-compaction and the associated risk of compaction timeouts on large-context models.Evidence
src/plugins/provider-self-hosted-setup.test.ts:reads provider-advertised context_size when meta.n_ctx_train is absent— reproduces the Cortecs/glm-5.2 case (context_size: 1048576→contextWindow: 1048576).prefers context_length over context_window and context_size when multiple are present— pins the read priority when a row advertises more than one variant.npx tsc --noEmitandnpx oxlintclean on both changed files.Real-behavior proof (post-rebase, requested by review)
Rebased onto current
upstream/main(HEAD now06b4d56d5), reinstalled dependencies, and reran the focused test command:Then called the patched
discoverOpenAICompatibleLocalModelsdirectly against the live Cortecs API (https://api.cortecs.ai/v1) with a real (redacted) Cortecs API key, no mocking:{ "id": "glm-5.2", "contextWindow": 1048576, "maxTokens": 8192 } total models discovered: 74Before this fix,
glm-5.2would have fallen through to the hardcodedSELF_HOSTED_DEFAULT_CONTEXT_WINDOW(128k/131k) since its context length is only advertised as a top-levelcontext_sizefield, notmeta.n_ctx_train. With the fix, the catalog now correctly resolves the real 1,048,576-token (1M) window advertised by the provider.AI-assisted PR — implemented by an OpenClaw agent session while investigating a real compaction-timeout incident against Cortecs' GLM-5.2. Session context: the agent observed
openclaw capability model inspect --model cortecs/glm-5.2reportingcontextWindow: 131000while Cortecs' own/v1/modelsAPI reportscontext_size: 1048576for the same model, traced the discrepancy to this code path, and verified the fix with the tests above.