openclaw - ✅(Solved) Fix [Bug]: agents.defaults.models.*.params.num_ctx ignored for Ollama — model discovery always overrides with GGUF context_length [2 pull requests, 1 participants]

armi0024 · 2026-03-13T02:27:05Z

[openclaw] OpenClaw ignores user-configured num ctx in openclaw.json when calling Ollama; on every startup it queries /api/show, reads the GGUF metadata field… OpenClaw ignores user-configured num_ctx in openclaw.json when calling Ollama; on every startup it queries /api/show, reads the GGUF metadata field qwen2.context_length: 32768, and passes that value as num_ctx in every /api/chat request, making params.num_ctx: 8192 in openclaw.json have no effect. # PR #44678: ollama: honor explicit params.num_ctx overrides - Repository: openclaw/openclaw - Author: Alex-Alaniz - State: open | merged: False - Link: https://github.com/openclaw/openclaw/pull/44678 ## Description (problem / solution / changelog) ## Summary - Problem: native Ollama runs always send `options.num_ctx` from `model.contextWindow`, so `agents.defaults.models["ollama/ "].params.num_ctx` never takes effect. - Why it matters: users explicitly configuring a smaller Ollama context still get the discovered GGUF context length, which can inflate KV cache usage and latency. - What changed: native Ollama requests now honor payload mutations, and the extra-param wrapper injects configured `num_ctx` for native `ollama` models. - What did NOT change (scope boundary): this PR does not change model discovery, stored model metadata, or the OpenAI-compatible Ollama adapter path. ## Change Type (select all) - [x] Bug fix - [ ] Feature - [ ] Refactor - [ ] Docs - [ ] Security hardening - [ ] Chore/infra ## Scope (select all touched areas) - [ ] Gateway / orchestration - [ ] Skills / tool execution - [ ] Auth / tokens - [ ] Memory / storage - [x] Integrations - [ ] API / contracts - [ ] UI / DX - [ ] CI/CD / infra ## Linked Issue/PR - Closes #44550 - Related #44550 ## User-visible / Behavior Changes Native Ollama runs now prefer `agents.defaults.models["ollama/ "].params.num_ctx` over the discovered `contextWindow` when building `/api/chat` requests. ## Security Impact (required) - New permissions/capabilities? (`Yes/No`) No - Secrets/tokens handling changed? (`Yes/No`) No - New/changed network calls? (`Yes/No`) No - Command/tool execution surface changed? (`Yes/No`) No - Data access scope changed? (`Yes/No`) No - If any `Yes`, explain risk + mitigation: ## Repro + Verification ### Environment - OS: macOS / local dev checkout - Runtime/container: Node 22 + Bun/Vitest - Model/provider: native Ollama stream path - Integration/channel (if any): None - Relevant config (redacted): `agents.defaults.models["ollama/qwen2.5:14b-8k"].params.num_ctx = 8192` ### Steps 1. Configure a native Ollama model in `agents.defaults.models` with `params.num_ctx`. 2. Run the model through the native `ollama` stream path. 3. Inspect the generated `/api/chat` request payload. ### Expected - `options.num_ctx` uses the explicit configured override. ### Actual - The issue report shows Ollama continuing to receive the discovered context length instead of the configured override. ## Evidence - [ ] Failing test/log before + passing after - [x] Trace/log snippets - [ ] Screenshot/recording - [ ] Perf numbers (if relevant) ## Human Verification (required) What you personally verified (not just CI), and how: - Verified scenarios: - `bunx vitest run src/agents/ollama-stream.test.ts src/agents/pi-embedded-runner-extraparams.test.ts` - `pnpm exec oxfmt --check src/agents/ollama-stream.ts src/agents/ollama-stream.test.ts src/agents/pi-embedded-runner/extra-params.ts src/agents/pi-embedded-runner-extraparams.test.ts` - `pnpm exec oxlint src/agents/ollama-stream.ts src/agents/ollama-stream.test.ts src/agents/pi-embedded-runner/extra-params.ts src/agents/pi-embedded-runner-extraparams.test.ts` - Edge cases checked: - Payload hooks can override the default native `num_ctx`. - Existing payload options are preserved when `num_ctx` is injected. - What you did **not** verify: - I did not run a live Ollama daemon or full integration channel flow. ## Review Conversations - [x] I replied to or resolved every bot review conversation I addressed in this PR. - [x] I left unresolved only the conversations that still need reviewer or maintainer judgment. If a bot review conversation is addressed by this PR, resolve that conversation yourself. Do not leave bot review conversation cleanup for maintainers. ## Compatibility / Migration - Backward compatible? (`Yes/No`) Yes - Config/env changes? (`Yes/No`) No - Migration needed? (`Yes/No`) No - If yes, exact upgrade steps: ## Failure Recovery (if this breaks) - How to disable/revert this change quickly: revert this commit or remove `params.num_ctx` from the model entry. - Files/config to restore: `src/agents/ollama-stream.ts`, `src/agents/pi-embedded-runner/extra-params.ts` - Known bad symptoms reviewers should watch for: native Ollama requests ignoring explicit `num_ctx` and falling back to discovered context length again. ## Risks and Mitigations - Risk: native Ollama payload hooks now run before the request is serialized. - Mitigation: the new regression t

openclaw2026-03-13 02:27:05

ON THIS PAGE

Recommended Tools

×6

Utilities matched from this issue’s tags and category — try them while you read without losing context.

GitHub issue graph ai analysis

Paste a GitHub issue URL. We fetch that issue, discover linked issues from bodies/comments/timeline, collect linked pull requests, and produce a structured English report.

The report is written in English Markdown for sharing and archival.

GitHub issue URL

Helpful · Quick feedback

GitHub stats

openclaw/openclaw#44550•Fetched 2026-04-08 00:45:21

View on GitHub

Comments

Participants

Timeline

Reactions

Author

armi0024

Participants

armi0024

Timeline (top)

referenced ×9cross-referenced ×2labeled ×2

OpenClaw ignores user-configured num_ctx in openclaw.json when calling Ollama; on every startup it queries /api/show, reads the GGUF metadata field qwen2.context_length: 32768, and passes that value as num_ctx in every /api/chat request, making params.num_ctx: 8192 in openclaw.json have no effect.

Root Cause

RAW_BUFFERClick to expand / collapse

Bug type

Behavior bug (incorrect output/state without crash)

Summary

Steps to reproduce

Create a custom Ollama model with PARAMETER num_ctx 8192 in its modelfile.
Set params.num_ctx: 8192 in openclaw.json under the model's config block (e.g. "ollama/qwen2.5:14b-8k": { "params": { "num_ctx": 8192 } }).
Restart OpenClaw and send a message via Telegram channel.
Run ollama ps — context shows 32768, not 8192.

Expected behavior

params.num_ctx in openclaw.json should override the discovered contextWindow from /api/show when making Ollama API calls. User config should take priority over model metadata discovery. Running ollama ps should show CONTEXT: 8192.

Actual behavior

models.json is regenerated on every startup, overwriting manual edits.
ollama ps always shows CONTEXT: 32768.
Ollama log confirms n_ctx = 32768.
Adding "contextWindow": 8192 to the openclaw.json model block returns: Unrecognized key: "contextWindow".
The 14B model allocates a 32K context KV cache (~6GB VRAM), causing 8+ minute response times where an 8K context would respond in seconds.

OpenClaw version

2026.3.8 (3caab92)

Operating system

macOS, Mac mini M4, 24GB unified memory

Install method

No response

Model

ollama/qwen2.5:14b-8k

Provider / routing chain

openclaw -> ollama

Config file / key location

~/.openclaw/openclaw.json ; agents.defaults.models["ollama/qwen2.5:14b-8k"].params.num_ctx

Additional provider/model setup details

Config block in openclaw.json: "ollama/qwen2.5:14b-8k": { "params": { "num_ctx": 8192 } }

Ollama modelfile confirms 8K default: PARAMETER num_ctx 8192

On startup, OpenClaw queries /api/show, reads qwen2.context_length: 32768 from GGUF metadata, writes contextWindow: 32768 into agents/main/agent/models.json, and passes num_ctx: 32768 in all /api/chat requests.

Logs, screenshots, and evidence

Impact and severity

Affected: Ollama users on macOS with large models Severity: High (blocks practical use — 8+ minute response times vs seconds) Frequency: 100% repro Consequence: 14B model allocates 32K KV cache (~6GB VRAM) instead of 8K; system becomes unusable

Additional information

Workaround: Using anthropic/claude-haiku-4-5 as primary model, with Ollama as fallback.

The bug is that models.json is regenerated on every startup, so manual edits to contextWindow are lost. The params.num_ctx value from openclaw.json is never applied to override the discovered GGUF context_length.

extent analysis

Fix Plan

To fix the issue, we need to modify the OpenClaw code to prioritize the params.num_ctx value from openclaw.json over the discovered context_length from the GGUF metadata.

Modify the models.json generation code to check for a num_ctx value in the openclaw.json config block and use it if present.
Update the /api/chat request code to use the num_ctx value from the config block instead of the discovered context_length.

Example code changes:

# In models.json generation code
if 'params' in model_config and 'num_ctx' in model_config['params']:
    context_window = model_config['params']['num_ctx']
else:
    context_window = gguf_metadata['qwen2.context_length']

# In /api/chat request code
if 'params' in model_config and 'num_ctx' in model_config['params']:
    num_ctx = model_config['params']['num_ctx']
else:
    num_ctx = context_window

Verification

To verify the fix, restart OpenClaw and send a message via Telegram channel. Then, run ollama ps to check if the context shows the correct value (8192). Also, check the Ollama log to confirm that n_ctx is set to 8192.

Extra Tips

Make sure to update the openclaw.json file with the correct num_ctx value for the model.
If using a large model, consider reducing the num_ctx value to prevent high memory usage.
Test the fix with different models and num_ctx values to ensure it works as expected.

Vote matrix · Quick signals

Works

Did the solution work? Tap to confirm.

Easy Fix

Was it a quick fix?

Time Saver

Did it save you time?

Blocking

Was it severely blocking?

Common Issue

Are others likely hitting this too?

Flaky / Intermittent

Is it intermittent?

Verified / Reproducible

Can you reproduce it reliably?

FAQ

Expected behavior

#api #ssr #installation #tensor shape #autograd error #SSR setup #ISR setup #authentication setup #request error

Still need to ship something?

×6

Another batch ranked right after the header list — different links, same matching logic.

openclaw - ✅(Solved) Fix [Bug]: agents.defaults.models.*.params.num_ctx ignored for Ollama — model discovery always overrides with GGUF context_length [2 pull requests, 1 participants]

Recommended Tools

GitHub issue graph ai analysis

Root Cause

Fix Action

Fix / Workaround

PR fix notes

PR #44678: ollama: honor explicit params.num_ctx overrides

Description (problem / solution / changelog)

Summary

Change Type (select all)

Scope (select all touched areas)

Linked Issue/PR

User-visible / Behavior Changes

Security Impact (required)

Repro + Verification

Environment

Steps

Expected

Actual

Evidence

Human Verification (required)

Review Conversations

Compatibility / Migration

Failure Recovery (if this breaks)

Risks and Mitigations

Changed files

PR #47160: fix: prioritize user-configured num_ctx over model-discovery contextWindow for Ollama (closes #44550)

Description (problem / solution / changelog)

Summary

Change Type

Scope

Linked Issue/PR

User-visible / Behavior Changes

Security Impact

Repro + Verification

Steps

Expected

Actual (before fix)

Evidence

Human Verification

Review Conversations

Compatibility / Migration

Failure Recovery

Risks and Mitigations

Changed files

Bug type

Summary

Steps to reproduce

Expected behavior

Actual behavior

OpenClaw version

Operating system

Install method

Model

Provider / routing chain

Config file / key location

Additional provider/model setup details

Logs, screenshots, and evidence

Impact and severity

Additional information

extent analysis

Fix Plan

Verification

Extra Tips

FAQ

Expected behavior

Still need to ship something?

RELATED_DISCOVERY

TRENDING