#Error code 500

1 messages · Page 1 of 1 (latest)

lavish stirrup
#

LLM error: {
"error": {
"code": 500,
"message": "Internal error encountered.",
"status": "INTERNAL"
}
}

I was asking openclaw (running Gemma 31B) to analyze the description of a youtube video and it returned this. The model chats normally in the interface.

pallid basaltBOT
#

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

polar steppeBOT
vagrant sphinxBOT
#

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:

  1. bigger prompt/context from the YouTube description
  2. OpenAI-compatible backend rejecting structured messages[].content
  3. 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.

lavish stirrup
#

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

vagrant sphinxBOT
#

Yep, that could absolutely be related.

  • openclaw logs --follow tails 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:

  • /new does 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:
    1. your model’s configured contextWindow is too small or wrong
    2. the fixed OpenClaw prompt/tool overhead is already eating most of the window
#
  1. 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
#

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.

lavish stirrup
#

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.

vagrant sphinxBOT
#

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:

  • error
  • INTERNAL
  • model
  • context
  • request_too_large
  • messages[].content
  • gemma

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.

lavish stirrup
#

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)

vagrant sphinxBOT
#

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[].content shape issue
  • Gemma/backend crash
  • tool-schema overload

We’re close now. 🦐

lavish stirrup
#

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.

vagrant sphinxBOT
#

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 INTERNAL instead 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:

  1. the base prompt is already huge, or
  2. the model’s configured contextWindow is 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

Docs:
https://docs.openclaw.ai/gateway/troubleshooting

lavish stirrup
#

(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
}
]
}

vagrant sphinxBOT
#

That’s very helpful.

It means:

  • the Google provider is up
  • google/gemma-4-31b-it can 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:

  1. session context is huge, and the agent request is much bigger than the direct infer model run test
  2. the model’s configured contextWindow is too small
  3. 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.

lavish stirrup
#

...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
}
]

vagrant sphinxBOT
#

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.md is 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.

lavish stirrup
#

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.

vagrant sphinxBOT
#

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:

  1. Prompt contamination / weird workspace injection
    That explains the bizarre infer model run replies about “waking up” and BOOTSTRAP.md.

  2. 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.

lavish stirrup
#

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

vagrant sphinxBOT
#

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

#
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.

lavish stirrup
#

(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

vagrant sphinxBOT
#

Yep, that’s it.

Those two files line up perfectly with:

  • Agents: 2 total
  • 2 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
lavish stirrup
#

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.

vagrant sphinxBOT
#

Nice, that status line is what we wanted:

  • no bootstrap files means 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

  1. 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.
  2. 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".
#
  1. Runtime/filesystem tools exposed in open groups

    • For public groups, use a narrow tool profile like tools.profile: "messaging"
    • Or at minimum deny:
      • group:runtime
      • group:fs
      • group:web
      • browser
    • Also set tools.fs.workspaceOnly: true
  2. 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:

lavish stirrup
#

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)

vagrant sphinxBOT
#

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: 0 means auto-compaction never kicked in
  • 🗄️ Cache: 99% hit means it keeps reusing the same oversized context
  • Fallback = same model so failover can’t help

So the likely flow is:

  1. session grows past 200k
  2. Google/Gemma returns a generic 500 INTERNAL instead of a clean context-overflow error
#
  1. OpenClaw does not recognize it as compaction-worthy
  2. 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