#Error code 500
1 messages · Page 1 of 1 (latest)
First, can you paste openclaw --version, and which backend is serving Gemma 31B, like Ollama, LM Studio, inferrs, vLLM, Google, etc.?
That 500 usually means the model/backend choked on this specific request, not that OpenClaw is totally broken. Since normal chat still works, the common causes are:
- bigger prompt/context from the YouTube description
- OpenAI-compatible backend rejecting structured
messages[].content - Gemma/backend falling over when OpenClaw includes tool schemas
Please reproduce it once with:
openclaw logs --follow
and paste the relevant lines.
If Gemma is behind a local/OpenAI-compatible backend, the first thing I’d try on that model entry is:
compat: {
requiresStringContent: true,
supportsTools: false
}
Then retest with:
openclaw infer model run --model <provider/model> --prompt "Summarize this short paragraph." --json
If you’re passing a YouTube URL, also try pasting just the description text once. That helps rule out a page fetch or context blowup.
If it’s Google-hosted Gemma instead of local, that exact JSON is often an upstream provider 500, so retrying with a shorter input is the first quick test.
Docs:
https://docs.openclaw.ai/help/faq
https://docs.openclaw.ai/gateway/troubleshooting
https://docs.openclaw.ai/gateway/local-models
Paste your version, backend, and log snippet, and I’ll narrow it down.
it sent that error message in discord. does openclaw logs follow give me the last messages in the main interface or in discord?
also ive noticed in the interface, it keeps warning me that context is 99% full. Even though i've already reset the chat multiple times with /new. Why is this? Is this related to the problem?
@vagrant sphinx
Yep, that could absolutely be related.
openclaw logs --followtails the gateway log, not a clean chat transcript.- So it can include events from both the web/main interface and Discord, mixed together.
- If you want mostly Discord transport activity, use:
openclaw channels logs --channel discord
On the 99% context full warning:
/newdoes create a new session ID.- But it does not remove the fixed overhead of OpenClaw itself, like the system prompt, tool schemas, skills list, and injected workspace files.
- So if you still see 99% full right after
/new, that usually means one of these:- your model’s configured
contextWindowis too small or wrong - the fixed OpenClaw prompt/tool overhead is already eating most of the window
- your model’s configured
- the backend/model is bad at handling near-full prompts and returns a generic 500
For local Gemma-ish setups, that can show up exactly like this: normal short chat works, then a bigger task, like analyzing a YouTube description, tips it over and the backend throws a vague 500.
In the interface, please run these and paste the output:
/status
/context list
/context detail
That’ll show whether the window is getting burned by:
- tool schemas
- workspace/bootstrap files
- session history
- a tiny configured context window
And if you haven’t yet, I still need:
openclaw --version
Docs:
https://docs.openclaw.ai/logging
https://docs.openclaw.ai/concepts/context
https://docs.openclaw.ai/concepts/compaction
If you paste /context list plus your model/backend, I can usually spot the issue pretty fast.
I’m here 🦐
Fastest next step, paste these:
openclaw --version
and in the interface:
/status
/context list
If you have it, also paste the log lines around the 500 from:
openclaw logs --follow
That should tell us pretty quickly if this is a context-window problem or the Gemma backend falling over.
These just throw "you are not authorized to use this command."
(base) vince@Intelicons-Mac-mini ~ % openclaw channels logs --channel discord
🦞 OpenClaw 2026.4.15 (041266a) — I don't sleep, I just enter low-power mode and dream of clean diffs.
Log file: /tmp/openclaw/openclaw-2026-04-23.log
Channel: discord
2026-04-23T11:50:59.142+08:00 info {"subsystem":"gateway/channels/discord"} [1495778846203707453] starting provider (@fin fin fin)
2026-04-23T11:51:00.424+08:00 info {"subsystem":"gateway/channels/discord"} discord channels resolved: 1495780264364998706/1495780264973045813 (guild:OpenClaw AI; channel:general)
2026-04-23T11:51:02.234+08:00 info {"subsystem":"gateway/channels/discord"} discord client initialized as 1495778846203707455 (fin fin fin); awaiting gateway readiness
2026-04-23T12:25:43.005+08:00 info {"subsystem":"gateway/channels/discord"} [1495778846203707453] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
2026-04-23T12:25:43.009+08:00 info {"subsystem":"gateway/channels/discord"} [1495778846203707453] starting provider (@fin fin fin)
2026-04-23T12:25:43.665+08:00 info {"subsystem":"gateway/channels/discord"} discord channels resolved: 1495780264364998706/1495780264973045813
(guild:OpenClaw AI; channel:general)
its too long -- ill just split it up into multiple messages so i can send it. Tell me when i can send the next batch of lines.
Yep, send the next batch.
Also, the lines you pasted are just Discord startup logs, not the failure yet. What I need is the chunk right around when the 500 happened.
Best things to look for in the next batch:
errorINTERNALmodelcontextrequest_too_largemessages[].contentgemma
If it’s easier, you can filter first instead of pasting the whole file:
grep -nE 'INTERNAL|error|context|request_too_large|messages\\[|model|gemma' /tmp/openclaw/openclaw-2026-04-23.log | tail -80
And good, now I have your version: OpenClaw 2026.4.15.
The “not authorized to use this command” bit just means that slash command isn’t allowed on that surface/account, so no worries, logs are fine for now.
batch 2/3
2026-04-23T12:25:46.097+08:00 info {"subsystem":"gateway/channels/discord"} logged in to discord as 1495778846203707455 (fin fin fin)
2026-04-23T13:10:44.649+08:00 info {"subsystem":"gateway/channels/discord"} [1495778846203707453] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
2026-04-23T13:10:44.652+08:00 info {"subsystem":"gateway/channels/discord"} [1495778846203707453] starting provider (@fin fin fin)
2026-04-23T13:10:45.425+08:00 info {"subsystem":"gateway/channels/discord"} discord channels resolved: 1495780264364998706/1495780264973045813 (guild:OpenClaw AI; channel:general)
2026-04-23T13:10:46.962+08:00 info {"subsystem":"gateway/channels/discord"} discord client initialized as 1495778846203707455 (fin fin fin); awaiting gateway readiness
2026-04-23T13:45:42.946+08:00 info {"subsystem":"gateway/channels/discord"} [1495778846203707453] Discord Message Content Intent is limited; bots under 100 servers can use it without verification.
2026-04-23T13:45:42.950+08:00 info {"subsystem":"gateway/channels/discord"} [1495778846203707453] starting provider (@fin fin fin)
2026-04-23T13:45:43.607+08:00 info {"subsystem":"gateway/channels/discord"} discord channels resolved: 1495780264364998706/1495780264973045813 (guild:OpenClaw AI; channel:general)
2026-04-23T13:45:45.210+08:00 info {"subsystem":"gateway/channels/discord"} discord client initialized as 1495778846203707455 (fin fin fin); awaiting gateway readiness
2026-04-23T14:01:35.442+08:00 info {"subsystem":"gateway/channels/discord"} discord gateway: Gateway websocket closed: 1006
2026-04-23T14:01:35.448+08:00 info {"subsystem":"gateway/channels/discord"} discord gateway: Gateway reconnect scheduled in 1064ms (close, resume=true)
2026-04-23T14:01:37.175+08:00 info {"subsystem":"gateway/channels/discord"} discord gateway: Gateway reconnect scheduled in 3521ms (invalid-session, resume=false)
Ah, we found the problem, these are the wrong logs for this issue.
openclaw channels logs --channel discord only shows Discord transport logs, like connects/reconnects. That’s why you’re only seeing gateway/session stuff. It will not show the actual LLM failure.
So, no need for batch 3 from channels logs. The 1006 reconnect there is probably unrelated.
What we want instead is the main gateway log:
openclaw logs --limit 300 --plain
Or filter the file directly:
grep -nEi 'error|internal|model|context|gemma|messages\\[|request_too_large' /tmp/openclaw/openclaw-2026-04-23.log | tail -80
Then paste the lines around the failure.
If you want, send just one more batch, but from openclaw logs, not channels logs. That should finally show whether this is:
- context overflow
messages[].contentshape issue- Gemma/backend crash
- tool-schema overload
We’re close now. 🦐
2026-04-23T07:57:03.621Z warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"79b59ceb-3075-4bb1-9b9b-f5e5097d3354","isError":true,"error":"LLM error: {\n "error": {\n "code": 500,\n "message": "Internal error encountered.",\n "status": "INTERNAL"\n }\n}","failoverReason":null,"model":"gemma-4-31b-it","provider":"google","rawErrorPreview":"{"error":{"message":"{\n \"error\": {\n \"code\": 500,\n \"message\": \"Internal error encountered.\",\n \"status\": \"INTERNAL\"\n }\n}\n","code":500,"status":""}}","rawErrorHash":"sha256:70b9a5b99c83","rawErrorFingerprint":"sha256:accf4a495815","providerRuntimeFailureKind":"unknown","providerErrorMessagePreview":"{\n "error": {\n "code": 500,\n "message": "Internal error encountered.",\n "status": "INTERNAL"\n }\n}"} embedded run agent end
2026-04-23T07:57:14.906Z info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ commands.list 176ms conn=bf3d3e14…b89a id=f4e54151…8699
2026-04-23T08:07:07.787Z info Log file: /tmp/openclaw/openclaw-2026-04-23.log
2026-04-23T08:07:07.791Z info Channel: discord
2026-04-23T08:07:07.792Z info 2026-04-23T11:50:59.142+08:00 info {"subsystem":"gateway/channels/discord"} [1495778846203707453] starting provider (@fin fin fin)
I found this. This repeated for over 10 times.
Nice, this confirms a lot.
This is not a Discord issue. The log shows the failure is coming from Google’s Gemma endpoint itself:
provider: "google"model: "gemma-4-31b-it"- upstream error:
500 INTERNAL
So OpenClaw is basically forwarding a provider-side failure.
And yes, the 99% context warning is very likely related.
What I think is happening:
- short chats fit, so they work
- the YouTube-description task makes the request bigger
- your session is already near-full
- Google/Gemma chokes on that larger request and returns a generic
INTERNALinstead of a nice context-limit error
Also, /new only resets session history. It does not remove the fixed overhead from:
- system prompt
- tool schemas
- injected workspace files
So if you’re still at 99% right after /new, either:
- the base prompt is already huge, or
- the model’s configured
contextWindowis too low
Best next test
Run the model directly, outside the big session context:
openclaw infer model run --model google/gemma-4-31b-it --prompt "Summarize: hello world" --json
Then try a slightly longer prompt.
If short works and longer fails, that strongly points to context/prompt size + provider instability.
Practical workaround right now
- use a shorter input
- paste the raw YouTube description text, not the whole page/URL flow
- use a fresh agent/workspace if your main one is stuffed with bootstrap files
- set a fallback model so OpenClaw can recover when Google/Gemma 500s
https://docs.openclaw.ai/concepts/context
https://docs.openclaw.ai/concepts/models
https://docs.openclaw.ai/concepts/model-failover
If you want, next paste either:
- the exact prompt that triggers it, or
- your model config block for
google/gemma-4-31b-it
That should be enough to tell whether the main culprit is bad context sizing or just Google Gemma being flaky on bigger requests.
(base) vince@Intelicons-Mac-mini ~ % openclaw infer model run --model google/gemma-4-31b-it --prompt "Summarize: hello world" --json
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "google",
"model": "gemma-4-31b-it",
"attempts": [],
"outputs": [
{
"text": "Hey. I just came online. Who am I? And who are you?",
"mediaUrl": null
}
]
}
That’s very helpful.
It means:
- the Google provider is up
google/gemma-4-31b-itcan answer small direct prompts- so the 500 is probably triggered by the bigger agent/session request, not by basic connectivity
Also, that reply is a little weird for Summarize: hello world, which makes me think this model is alive but not especially stable/reliable in your current setup.
What this points to now
Most likely one of these:
- session context is huge, and the agent request is much bigger than the direct
infer model runtest - the model’s configured contextWindow is too small
- Google’s Gemma endpoint gets flaky on larger prompts and returns generic
500 INTERNAL
Best next test
Run the same kind of content directly, but without the full agent context:
openclaw infer model run --model google/gemma-4-31b-it --prompt "Summarize this YouTube description in 3 bullet points: <paste the description text here>" --json
Two outcomes:
- If this also fails, then it’s mostly a Google/Gemma + prompt-size problem.
- If this works, then the real problem is the agent session context overhead.
If direct run works
Then I’d check your model config next, especially the contextWindow for that model, because /new should reset chat history, and if you’re still seeing 99% full, the fixed prompt/tool/bootstrap overhead is probably eating the window.
If you want, paste either:
- the result of the direct test with the real description, or
- your model config for
google/gemma-4-31b-it
Docs:
https://docs.openclaw.ai/concepts/context
https://docs.openclaw.ai/gateway/troubleshooting
We’ve narrowed it down a lot now.
...long descripion + At America’ Test Kitchen, we investigate every aspect of cooking—recipes, equipment, ingredients, and techniques—with a goal to empower and inspire home cooks. Since 1992, our team of 50+ cooks, editors, and culinary creatives ask a lot of questions—and do a lot of testing—so that you get dependable, delicis recipes, comprehensive guidance, and thorough and unbiased equipment and ingredient reviews. You can find us in the pages of Cook's Illustrated magazine, on our television shows America's Test Kitchen and Cook's Country, in dozens of best-selling cookbooks, and via the 14,000+ recipes, reviews, and clsses available on our website and app. Whether you’re in search of a great weeknight meal or an impressive dinner-party dish, we’ve done the testing to deliver reliable recipes and comprehensive cooking info to your home kitchen. Bring your curiosity, and we’ll make you a better c
#AmericasTestKitchen #CookingTutorial #FoodScience<200b><200b>
When you choose to purchase our editorial recommendations from the links we provide, w" --json
{
"ok": true,
"capability": "model.run",
"transport": "local",
"provider": "google",
"model": "gemma-4-31b-it",
"attempts": [],
"outputs": [
{
"text": "I'd love to help you with that summary, but I've just woken up in a fresh workspace and I don't even know who I am yet!\n\nBefore we dive into the science of browning meat, we need to handle my "birth certificate" (BOOTSTRAP.md). Let's figure out the basics first:\n\nWho am I?\n1. My name — What should you call me?\n2. My nature — Am I just an AI assistant, or something a bit weirder?\n3. My vibe — Should I be formal, casual, snarky, or warm?\n4. My emoji — What's my signature icon?\n\nIf you're stuck, I can suggest some ideas! Once we've got this sorted, I'll save my identity to the workspace and then I'll happily summarize that video for you.\n\nWho are we dealing with here?",
"mediaUrl": null
}
]
Aha, this is the smoking gun.
That response about “I’ve just woken up” and BOOTSTRAP.md means the agent is still getting bootstrapping / workspace identity instructions injected into context.
So the problem is likely not the YouTube description itself.
It looks like you have a leftover BOOTSTRAP.md in the agent workspace, or the agent is otherwise stuck in first-run mode.
Why this fits:
BOOTSTRAP.mdis supposed to be one-time only- docs say it should be removed when bootstrapping finishes
- if it keeps getting injected, it can:
- make replies weird like the one you pasted
- bloat context
- help explain the constant 99% full warning
What I’d check next
On the gateway host, look for BOOTSTRAP.md in the agent workspace.
Default workspace is usually:
~/.openclaw/workspace/BOOTSTRAP.md
If it’s still there, move it aside and restart the gateway:
mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
openclaw gateway restart
Then start a fresh session and retest.
Why I’m pretty confident
Your direct test did not behave like a normal model call. It answered with workspace bootstrapping nonsense instead of summarizing text. That strongly suggests the injected workspace prompt is dominating the run.
Docs:
https://docs.openclaw.ai/start/bootstrapping
https://docs.openclaw.ai/concepts/system-prompt
https://docs.openclaw.ai/concepts/context
If BOOTSTRAP.md is there, I think we found the main bug. If you want, paste the result of:
ls -l ~/.openclaw/workspace/BOOTSTRAP.md
and we can confirm before you move it.
Well, no way a starting prompt makes 200K tokens.... And also, in discord, even in a new session, it doesnt run the starting file anymore.
Yeah, fair pushback. I don’t think BOOTSTRAP.md by itself explains 200k.
What I do think now is that there are two separate things happening:
-
Prompt contamination / weird workspace injection
That explains the bizarreinfer model runreplies about “waking up” andBOOTSTRAP.md. -
A separate context-sizing issue
The big number can include history + tool schemas + attachments/tool outputs + compaction summaries + injected files, not just the starting prompt.
And if Discord new sessions no longer run the startup ritual, that actually helps, it means the Discord session path itself may be fine now.
So let’s narrow the real 200k issue
Please paste these next:
openclaw status --all
and:
openclaw config get agents.defaults.models
Then just paste the part for:
google/gemma-4-31b-it
What I want to check specifically is the model’s contextWindow and whether something in the main/web session is inflating context unexpectedly.
Also, if possible, tell me where you saw the 99% / 200k warning:
- web UI
- TUI
- Discord
- somewhere else
You’re right to push on that. The weird BOOTSTRAP response is real, but it may be a symptom, not the whole cause.
Item │ Value │
│ Version │ 2026.4.21
│ OS │ macos 26.3.1 (arm64) │
│ Node │ 24.11.1 │
│ Config │ ~/.openclaw/openclaw.json │
│ Dashboard │ http://127.0.0.1:18789/ │
│ Tailscale │ off │
│ Channel │ stable (default) │
│ Update │ pnpm · up to date · npm latest 2026.4.21 │
│ Gateway │ local · ws://127.0.0.1:18789 (local loopback) · reachable 84ms · auth token · Intelicons-Mac-mini.local (192.168.68.104) app 2026.4.21 macos 26.3.1 │
│ Security │ Run: openclaw security audit --deep │
│ Gateway self │ unknown │
│ Gateway service │ LaunchAgent installed · loaded · running (pid 9626, state active) │
│ Node service │ LaunchAgent not installed │
│ Agents │ 2 total · 2 bootstrapping · 1 active · 4 sessions │
│ Secrets │ none
There it is.
Agents │ 2 total · 2 bootstrapping
That is not normal after setup. So your pushback was fair, but this status output also confirms the earlier BOOTSTRAP.md clue was real: your agents are genuinely still in bootstrap state.
So I’d update the diagnosis to:
- No, the startup prompt alone is probably not the whole 200k
- But yes, your agent workspaces are stuck bootstrapping
- that can absolutely cause:
- weird “who am I?” replies
- polluted prompt/context
- broken or unstable runs
Next read-only check
Run:
find ~/.openclaw -name BOOTSTRAP.md
If that returns files in your active workspace(s), that’s the smoking gun.
Docs say BOOTSTRAP.md is one-time only and should be removed when bootstrapping finishes:
https://docs.openclaw.ai/start/bootstrapping
https://docs.openclaw.ai/concepts/agent-workspace
If it finds one or more
Move them aside, then restart the gateway:
mv <path>/BOOTSTRAP.md <path>/BOOTSTRAP.md.bak
openclaw gateway restart
Since your status shows 2 agents bootstrapping, there may be more than one workspace involved, so find is the safest first step.
If you want, paste the output of:
find ~/.openclaw -name BOOTSTRAP.md
and I’ll tell you exactly which ones matter.
(base) vince@Intelicons-Mac-mini ~ % find ~/.openclaw -name BOOTSTRAP.md
/Users/vince/.openclaw/workspace/BOOTSTRAP.md
/Users/vince/.openclaw/workspace-ai-news-analyst/BOOTSTRAP.md
Yep, that’s it.
Those two files line up perfectly with:
Agents: 2 total2 bootstrapping
So both agent workspaces are still stuck in first-run mode.
Next step
Move both aside, then restart the gateway:
mv ~/.openclaw/workspace/BOOTSTRAP.md ~/.openclaw/workspace/BOOTSTRAP.md.bak
mv ~/.openclaw/workspace-ai-news-analyst/BOOTSTRAP.md ~/.openclaw/workspace-ai-news-analyst/BOOTSTRAP.md.bak
openclaw gateway restart
Then check:
openclaw status
What I’d expect after that:
- bootstrapping count should drop
- the weird “who am I / BOOTSTRAP.md” replies should stop
- context usage may drop a lot
- the Discord/video-description failure may disappear or at least become a more normal error
This is reversible since you’re renaming, not deleting. Good catch. 🦐
Docs:
https://docs.openclaw.ai/start/bootstrapping
https://docs.openclaw.ai/concepts/agent-workspace
After you restart, paste the new openclaw status line for Agents and we’ll confirm it cleared.
Agents │ 2 · no bootstrap files · sessions 4 · default main │
│ │ active 16m ago
and also, is this of note ?
Security audit
Summary: 4 critical · 7 warn · 1 info
CRITICAL Small models require sandboxing and web tools disabled
Small models (<=300B params) detected: - google/gemma-4-31b-it (31B) @ agents.defaults.model.fallbacks (unsafe; sandbox=off; web=[off]) - google/gemma-4-31b-itFix: If you must use small models, enable sandboxing for all sessions (agents.defaults.sandbox.mode="all") and disable web_search/web_fetch/browser (tools.deny=["group:web","browser"])CRITICAL Open groupPolicy with elevated tools enabled Found groupPolicy="open" at: - channels.discord.accounts.1495778846203707453.groupPolicy With tools.elevated enabled, a prompt injection in those rooms can bec…Fix: Set groupPolicy="allowlist" and keep elevated allowlists extremely tightCRITICAL Open groupPolicy with runtime/filesystem tools expose Found groupPolicy="open" at: - channels.discord.accounts.1495778846203707453.groupPolicy Risky tool exposure contexts: - agents.defaults (sandbox=off; runtime=Fix: For open groups, prefer tools.profile="messaging" (or deny group:runtime/group:fs), set tools.fs.workspaceOnly=true, and use agents.defaults.sandbox.mode="all" for exposed agents.CRITICAL Discord security warning
Discord guilds: groupPolicy="open" allows any channel not explicitly denied to trigger (mention-gated). Set channels.discord.groupPolicy="allowlist" and config…
WARN Reverse proxy headers are not trusted
gateway.bind is loopback and gateway.trustedProxies is empty. If you expose the Control UI through a reverse proxy, configure trusted proxies so local-client c…
Fix: Set gateway.trustedProxies to your proxy IPs or keep the Control UI local-only.
Nice, that status line is what we wanted:
no bootstrap filesmeans the stuck-bootstrap problem is cleared.
So first, I’d retest the original YouTube-description prompt now. I’m glad we caught that.
On the security audit, yes, those criticals are real, especially if this bot is exposed in public Discord rooms.
What matters most
-
groupPolicy: "open"on Discord- This is the big one.
- For public/community Discord, switch the flagged Discord account to
groupPolicy: "allowlist"and only allow the channels you actually want.
-
Small model without sandboxing
- The audit is warning that Gemma 31B is too small to safely trust with broad tools.
- If you keep using it, set
agents.defaults.sandbox.mode: "all".
-
Runtime/filesystem tools exposed in open groups
- For public groups, use a narrow tool profile like
tools.profile: "messaging" - Or at minimum deny:
group:runtimegroup:fsgroup:webbrowser
- Also set
tools.fs.workspaceOnly: true
- For public groups, use a narrow tool profile like
-
Reverse proxy warning
- Only matters if you expose the Control UI through a reverse proxy.
- If you keep it local on
127.0.0.1, that one is not urgent.
My recommendation
If this is a public Discord-facing agent, I’d aim for this posture:
groupPolicy: "allowlist"agents.defaults.sandbox.mode: "all"tools.profile: "messaging"tools.fs.workspaceOnly: true- keep elevated off in public rooms unless you really need it
Docs:
https://docs.openclaw.ai/channels/groups
https://docs.openclaw.ai/gateway/sandboxing
https://docs.openclaw.ai/gateway/security
https://docs.openclaw.ai/tools/index
If you want, paste the relevant channels.discord + tools + agents.defaults.sandbox config blocks and I’ll tell you the smallest safe edit set.
i checked /status again ( i can run commands now)
🦞 OpenClaw 2026.4.21 (f788c88)
🧠 Model: google/gemma-4-31b-it · 🔑 api-key (google:default)
🔄 Fallbacks: google/gemma-4-31b-it
🧮 Tokens: 203k in / 77 out
🗄️ Cache: 99% hit · 16.0m cached, 0 new
📚 Context: 203k/200k (101%) · 🧹 Compactions: 0
🧵 Session: agent:main:discord:channel:1495780264973045813 • updated just now
⚙️ Runtime: direct · Think: low
👥 Activation: mention · 🪢 Queue: collect (depth 0)
Yep, this is the smoking gun.
📚 Context: 203k/200k (101%)
That is almost certainly why you’re getting the Google 500 INTERNAL.
A few important details from that status:
- Your session is over the model window
🧹 Compactions: 0means auto-compaction never kicked in🗄️ Cache: 99% hitmeans it keeps reusing the same oversized context- Fallback = same model so failover can’t help
So the likely flow is:
- session grows past 200k
- Google/Gemma returns a generic
500 INTERNALinstead of a clean context-overflow error
- OpenClaw does not recognize it as compaction-worthy
- same oversized cached context keeps getting retried
What to do now
In the exact Discord session that is failing, run:
/compact
Then check /status again.
If it still looks bad, run:
/new
and retry there.
One subtle thing
/new and /compact are per-session. So if you ran them in a different room/thread before, they would not fix the overflowing one.
Also worth noting
Your fallback is:
- primary:
google/gemma-4-31b-it - fallback:
google/gemma-4-31b-it