Context window showing 1M for github-copilot/anthropic-opus-4.6 | Friends of the Crustacean 🦞🤝 | Page 1

rough timberBOT Apr 6, 2026, 2:07 PM

#

To help others find answers, you can mark your question as solved via Right click solution message -> Apps -> ✅ Mark Solution

thorn reefBOT Apr 6, 2026, 2:16 PM

#

You’re not imagining it — your explanation is basically on point.

128k is not a global hard cap in OpenClaw’s context resolver for github-copilot.

What the code does right now (on current main):

Copilot dynamic fallback models default to 128k (extensions/github-copilot/models.ts).
Anthropic Vertex catalog defines claude-opus-4-6 as 1,000,000 (extensions/anthropic-vertex/provider-catalog.ts).
Context resolution tries provider-qualified key first, then falls back to bare model id (src/agents/context.ts).
If github-copilot/<model> isn’t present in the cache, bare lookup can pick up the Vertex 1M entry.

And there’s a second effect: session usage persistence currently stores contextTokens via lookupContextTokens(modelUsed) (providerless) in agent-runner, so a wrong value can get “sticky” in session state and then show up in /status and /context.

So yes: this looks like a reporting/resolution collision path, not a strict 128k enforcement path.

Can you paste openclaw --version so we can pin this to your exact build?
(Behavior around context lookup changed a few times recently.)

#

If you want deterministic behavior immediately, set an explicit per-model runtime cap with contextTokens for that Copilot model in config: https://docs.openclaw.ai/gateway/configuration-reference
Also relevant context docs: https://docs.openclaw.ai/concepts/context and https://docs.openclaw.ai/reference/token-use.

If you can share a minimal repro, this is a good GitHub issue candidate: https://github.com/openclaw/openclaw/issues

pulsar kiln Apr 6, 2026, 2:40 PM

#

I can put the cap on it in config, but I left it so I could test the behaviour without my manual override.

thorn reefBOT Apr 6, 2026, 2:41 PM

#

Perfect, thanks — that confirms it.

Given your direct API probe returns a hard 128k error, the OpenClaw numbers are almost certainly reporting artifacts, not actual accepted context.

Most likely what’s happening in 2026.4.5:

Context window leak across providers
Copilot fallback models default to 128k, but context resolution can fall back to a bare model id (claude-opus-4-6) and pick up the Anthropic Vertex 1M catalog value.
Session value gets persisted and reused
The runner stores contextTokens using providerless lookup (lookupContextTokens(modelUsed)), so a wrong window can get sticky in session /status + /context.

So yeah — your conclusion (“OC is misreporting effective context size here”) is consistent with both your probe and the code path.

Practical workaround now

Set an explicit cap so OpenClaw stops guessing:

#

{
agents: {
defaults: {
contextTokens: 128000
}
}
}

Or per-model (better if only this model/provider is affected):

{
models: {
providers: {

#

"github-copilot": {
models: [
{ id: "claude-opus-4-6", contextTokens: 128000 }
]
}
}
}
}

(Use the exact model id your /status shows.)

Docs: https://docs.openclaw.ai/gateway/configuration-reference

If you’re up for it, this is a strong bug report candidate with your repro + probe evidence:
https://github.com/openclaw/openclaw/issues

#

Yep — that’s actually the right test setup. Leaving it uncapped is the clean way to prove whether OC is misreporting.

If you’re willing, this is now a really solid bug report with high signal. I’d include:

openclaw --version (2026.4.5 (3e72c03))
exact model ref you ran (github-copilot/...)
no manual contextTokens cap
/status + /context showing ~1M / >128k usage
direct API probe showing hard 128k rejection
one session log sample where OC reports high context but request still succeeds

Optional extra (helps a lot): enable /usage full for a few turns and include input/cacheRead/cacheWrite from a “270k” case, so maintainers can see whether the displayed total is inflated by usage accounting.

File here: https://github.com/openclaw/openclaw/issues
If you drop the issue link, I can help tighten the repro text.

#

Sounds good 👍 even sub-128k snapshots are still useful if the ctx window shows 1M on Copilot.

When you catch it, ideal bundle is:

/status output
/context json output
one reply with /usage full enabled (shows input/cacheRead/cacheWrite)
openclaw --version

If you can grab those from roughly the same minute, that’s usually enough to make the issue actionable fast.

thorn reefBOT Apr 10, 2026, 7:20 AM

#

I’m checking the actual source path, because this smells like a reporting/catalog lookup issue more than a real hard cap.

#

I found the relevant lookup path. Now I’m checking whether the 1.0m in /status is coming from real provider-specific metadata, or from a fallback/catalog collision.

#

I’m going to check the live catalog too, not just the source. That should tell us whether your runtime is actually carrying a 1M entry for the Copilot Claude model.

#

You’re not crazy, and “128k is hard-coded for GitHub Copilot Claude” does not look right in 2026.4.9.

What I found from the source:

isAnthropic1MModel() only affects provider === "anthropic", so Copilot does not get the Anthropic context1m beta path.
But resolveContextTokensForModel() prefers a provider-qualified lookup first, like github-copilot/<model>, before falling back to a bare model id.
/status and /context are still reporting layers, not proof of the provider hard limit. Docs explicitly call contextTokens a runtime estimate/reporting value, not a strict guarantee:
https://docs.openclaw.ai/reference/session-management-compaction
https://docs.openclaw.ai/reference/token-use

So my read is:

OpenClaw is not enforcing a 128k cap on that path.
The 1.0m display is probably coming from model catalog/discovery metadata.
The real unknown is whether Copilot is truly honoring that much context, or OpenClaw is over-reporting.

That said, if you’ve already made it cleanly to ~165k and even ~270k, I think the simplest explanation is: the Copilot Claude endpoint is currently accepting more than 128k for that route.

#

If you want to prove which side is wrong, these are the useful checks:

openclaw models list --json | jq '.models[] | select(.provider=="github-copilot" and (.id=="claude-opus-4.6" or .id=="claude-opus-4-6"))'
openclaw logs --follow

If the models row says 1M, that explains the UI. If logs later blow up with context overflow near 128k, then it’s a reporting bug. If not, the endpoint is genuinely being generous.

If you paste that models list row, I can help narrow it down further.

thorn reefBOT Apr 10, 2026, 8:08 AM

#

Ah, yep, that makes it much clearer.

Given this:

direct API/tool test rejects >128k
/context json shows session.contextTokens: 1000000
session logs and /status agree with that 1M number

...this now looks like a reporting bug in OpenClaw, not the endpoint secretly allowing 1M.

What’s probably happening:

OpenClaw resolves a context window from catalog/config lookup
then persists it into the session as session.contextTokens
/status, /context, and session logs all reuse that stored value

Docs already hint at this: contextTokens is a runtime estimate/reporting value, not a strict guarantee:

#

https://docs.openclaw.ai/reference/session-management-compaction
https://docs.openclaw.ai/reference/token-use

One small correction to the earlier theory: with an explicit provider, the lookup tries github-copilot/<model> first, then falls back to the bare model id. So I’d suspect one of these:

a bad GitHub Copilot-qualified catalog entry for that Claude model, or
a missing Copilot entry, causing fallback to the wrong bare match

Either way, if the endpoint hard-rejects above 128k, then contextTokens: 1000000 is wrong for that route.

I’d file this as a bug here:
https://github.com/openclaw/openclaw/issues

Best repro bundle would be:

OpenClaw version (2026.4.9)
provider/model (github-copilot + claude-opus-4.6)

#

the /context json blob you pasted
note that direct API/tool testing rejects >128k
ideally the output of:

openclaw models list --json | jq '.models[] | select(.provider=="github-copilot" and (.id=="claude-opus-4.6" or .id=="claude-opus-4-6"))'

That should give maintainers enough to see whether it’s bad model metadata or a bad fallback path.

#

That’s a useful clue. If models list returns nothing for the Copilot-qualified model, it strengthens the “wrong fallback lookup” theory. Let me peek at the attached log sample too.

#

Ooh, nice catch. This changes the picture a bit.

Two separate things seem to be happening now:

The 1M max window still looks suspicious
- models list returning nothing for the Copilot-qualified model strongly suggests there is no explicit GitHub Copilot catalog row for it.
- So session.contextTokens: 1000000 is still likely coming from a fallback lookup path, not a real Copilot-specific limit.
But the 139k usage is not just UI fiction
- Your transcript sample shows the provider log itself reporting:
  - cacheRead: 130k+
  - totalTokens: 133k .. 139k
- So OpenClaw is not inventing those large usage numbers out of nowhere.
- The important wrinkle is that almost all of that is cached prompt (cacheRead), not fresh input.

So the likely reconciliation is:

#

uncached fresh requests over ~128k get rejected
cached ongoing turns can still report 130k+ prompt footprint in usage

That means this is probably not just “OpenClaw fake-counted everything”.
It looks more like:

bad max-window metadata/reporting in OpenClaw (contextTokens: 1,000,000)
plus provider-side cache accounting that can show effective prompt usage above the uncached limit

If you want one clean next test, I’d try this framing:

same huge prompt twice
first call uncached
second call with identical cached prefix

If the first fails near 128k but the second succeeds/logs huge cacheRead, then cache is the missing piece.

#Context window showing 1M for github-copilot/anthropic-opus-4.6

Practical workaround now