My 262k-token model kept faceplanting at 33k and the fix was nowhere near OpenClaw

Most context window debugging comes down to one annoying fact:

the model card is not the runtime limit.

If OpenClaw says 262144 but ollama ps shows about 33k, the active cap is usually Ollama runtime allocation, Docker env handling, or another serving-layer setting.

Not Qwen. Not Llama. Not OpenClaw.

I ran into this pattern while digging through an r/openclaw thread where someone described it perfectly:

Openclaw seems to recognize that the model supports 262144 tokens, but I always have issues with getting responses after 33k tokens are used.

That sentence is the whole bug report.

The model supports 262k.
The stack serves ~33k.
Those are different numbers.

If you miss that distinction, you can waste hours blaming the wrong layer.

The model card is the alibi, not the culprit

This is the first thing I wish more people said more clearly:

advertised max context is not effective runtime context.

A Qwen model can be listed as 262144 tokens.
OpenClaw can request 262144.
Your actual session can still die in the low 30k range because Ollama only allocated around 32k based on available VRAM or startup config.

That matches both the Reddit thread and Ollama’s docs.

One reply in that same thread pointed to the real clue:

When I run ollama ps on terminal while I have an Openclaw session open, it says the model only has 33k no matter how much context the model is capable of.

That’s the signal.

Not the model page.
Not the OpenClaw UI.
Not your assumption.

ollama ps.

If ollama ps says 33k, that’s the ceiling your session is actually living under.

Why 33k keeps showing up

Because Ollama has multiple defaults, and they do not all tell the same story.

Ollama’s docs have long mentioned a 4096 token default unless you override it.

But Ollama’s newer context-length guidance also describes practical allocation behavior based on available VRAM:

• under 24 GiB VRAM: around 4k
• 24–48 GiB VRAM: around 32k
• 48+ GiB VRAM: up to 256k

So when people keep seeing roughly 33k, that often isn’t an OpenClaw bug at all.

It’s Ollama doing a VRAM-based allocation.

That’s why this bug feels weird. You configure one number. The runtime quietly picks another.

Why it passes quick tests and then dies in agent runs

Because one-shot prompts are liars.

A tiny direct prompt tells you almost nothing about whether an agent workflow will survive.

OpenClaw sessions stack a lot more than the last message:

• system prompts
• memory
• prior turns
• tool traces
• agent instructions
• verbose tool output
• retries and intermediate reasoning scaffolding

That means a setup that looks fine in a quick test can still fall over once the agent starts doing actual work.

This hits harder in:

• OpenClaw
• n8n
• Make
• Zapier
• custom OpenAI-compatible agent frameworks

Hidden context caps don’t just break one chat. They break:

• tool loops
• memory handoffs
• long traces
• coding runs
• multi-step automations

Ollama’s own guidance recommends larger context for agents, web search, and coding workloads. That tracks with reality.

A backend that silently under-allocates context is a great way to create failures that only appear after 20 minutes of successful-looking execution.

The Docker trap: did Ollama actually get the env var?

This is where people lose the most time.

They do this:

export OLLAMA_CONTEXT_LENGTH=262144

Then they restart OpenClaw.
Then they feel optimistic.
Then ollama ps still shows about 33k.

Why?

Because if Ollama is running in Docker, the variable has to exist inside the container running Ollama.

Not in your terminal.
Not in your shell profile.
Not in the OpenClaw container.

If Ollama can’t see it, it doesn’t matter.

Check logs:

docker logs <ollama-container>

Check the running container env:

docker exec -it <ollama-container> env | grep OLLAMA

That usually tells the story fast.

What each layer actually controls

Layer	What it actually controls	How to verify
OpenClaw config	What OpenClaw requests or advertises for agent context	Check OpenClaw config and request behavior
Ollama server setting	What Ollama is willing to allocate at runtime	Check ollama ps and Ollama logs
Per-request num_ctx override	What a single API call asks for	Inspect the exact API payload

And this is where env handling usually breaks:

Ollama setup	How env vars are applied	Common failure mode
Host install	Exported in shell or service environment	Variable set in one shell, Ollama started elsewhere
systemd service	Must be defined in service unit or override	User exports var, systemd keeps old environment
Docker container	Must be passed into container process	Variable set on host, never injected into container

The fastest way to find the real bottleneck

My rule here: don’t tweak three layers at once.

Treat it like a production incident.

1) Set the OpenClaw value explicitly

openclaw config set agents.defaults.contextWindow 262144

Good. Now ignore OpenClaw for a minute.

2) Check what Ollama actually loaded

ollama ps

If it says around 33k, that’s your real cap.

Not your desired cap.
Not the model card.
The actual cap.

3) Force the Ollama server context directly

For a direct server run:

OLLAMA_CONTEXT_LENGTH=64000 ollama serve

If you want 262144, set that instead:

OLLAMA_CONTEXT_LENGTH=262144 ollama serve

But only do that if your hardware can support it without turning performance into sludge.

4) Test a direct API call with num_ctx

This is the cleanest way to separate request-level behavior from server-level behavior.

curl http://localhost:11434/api/generate -d '{
  "model": "llama3.2",
  "prompt": "Why is the sky blue?",
  "options": {
    "num_ctx": 64000
  }
}'

Now you can answer three different questions:

1. What does OpenClaw want?
2. What does Ollama allow globally?
3. What did this specific request ask for?

If direct Ollama calls work at larger num_ctx values but OpenClaw sessions still fail, you’ve isolated the issue.

If direct Ollama calls still cap out, the serving layer is still the bottleneck.

5) If Docker is involved, inspect the container config

For Docker Compose, make the env var explicit in the Ollama service:

services:
  ollama:
    image: ollama/ollama
    ports:
      - "11434:11434"
    environment:
      - OLLAMA_CONTEXT_LENGTH=64000

Then restart it cleanly:

docker compose down
docker compose up -d

Then verify again:

docker exec -it <ollama-container> env | grep OLLAMA
ollama ps

A practical debugging checklist

If I had to condense this into a fast checklist, it would be this:

# 1) What does OpenClaw think the context should be?
openclaw config get agents.defaults.contextWindow

# 2) What did Ollama actually allocate?
ollama ps

# 3) Is the env var present in the running Ollama process?
docker exec -it <ollama-container> env | grep OLLAMA

# 4) What do the logs say?
docker logs <ollama-container>

# 5) Can a direct request override context?
curl http://localhost:11434/api/generate -d '{
  "model": "qwen2.5",
  "prompt": "test",
  "options": {"num_ctx": 64000}
}'

That sequence is way more useful than staring at a model card and hoping.

What if it’s not Ollama?

Sometimes it isn’t.

Bigger prompts can also fail because of:

• another OpenAI-compatible backend
• bad quantization choices
• memory pressure
• GPU offloading
• model/server compatibility issues
• a serving stack that accepts the request and then collapses under load

Also, “supports 256k” does not mean “your machine can serve 256k well.”

That’s the part people skip.

A giant context window on paper is not the same thing as a stable long-running agent in production.

I would rather have a reliable 64k setup that completes tool loops than a “256k” setup that stalls the moment the trace gets interesting.

Why this matters for real automation workloads

This isn’t just a local debugging annoyance.

If you’re running agents in n8n, Make, Zapier, OpenClaw, or a custom OpenAI-compatible stack, hidden serving-layer limits are poison.

They create the worst kind of failure:

• random
• delayed
• expensive to diagnose
• hard to reproduce from small tests

That’s also why teams eventually get tired of babysitting local serving quirks.

Debugging Ollama VRAM allocation, Docker env propagation, and per-model context weirdness is fun exactly once.

After that, predictable capacity starts looking a lot more attractive.

That’s the appeal of a drop-in OpenAI-compatible service like Standard Compute: predictable monthly pricing, no per-token billing, and no token anxiety when your agents run all day. If your automations live inside OpenClaw, n8n, Make, Zapier, or custom workflows, cost predictability matters almost as much as context reliability.

The question I ask first now

When someone says, “OpenClaw is limiting my context,” I don’t start with OpenClaw.

I ask:

what does ollama ps say while the session is live?

That one question cuts through a lot of confusion.

Because in this class of bug, every layer can be telling a different truth:

• the model card says 262144
• the OpenClaw config says 262144
• the runtime allocation says 33k
• the agent behavior says “I’m dying for reasons I refuse to explain”

All four can be true at once.

That’s why context window debugging feels slippery.

You are not debugging one number.
You are debugging which layer gets to make the number real.

Takeaway

If your “262k-token” model behaves like a 33k model, it usually is a 33k model at runtime.

Trust the loaded runtime over the marketing number.
Trust ollama ps over assumptions.
Treat Docker env vars like evidence that has to be proven inside the running process.

For hobby local setups, Ollama is fine.

For production agents that need to run all day without context babysitting, I would not trust a stack where the serving layer can silently undercut the model card and leave me debugging token limits at 2 a.m.