vocal cairn
I have several crons set up with a model of gemini-3.1-flash-lite, and when i run a status in terminal, they show correctly, though with 1049 context instead of the usual 200k. When I do a status in discord - it says gemini-3-flash which is my primary.
I just updated yesterday to v2026.3.13, and i'm wondering if there is something i needed to change after migrating?
spiral creekBOT
thin gullBOT
Nothing to change post‑migration for this, it’s just two different “status” concepts getting mixed:
Discord /status shows the current chat session model, i.e. whatever that thread/channel is currently using (usually your primary unless you /model switched in that thread). It does not reflect what your cron jobs are configured to use.
That “1049 context” you’re seeing is almost certainly context usage (tokens currently in the prompt/history for that session), not “max context window.” For isolated cron runs—especially if they’re --light-context—~1k tokens of context usage is totally normal.
Docs: https://docs.openclaw.ai/reference/token-use
If you want to verify what model a cron run actually used, check the run history for that job:
openclaw cron runs --id <jobId> --limit 5
(and/or view the Cron Jobs panel in Control UI). Cron jobs + model override behavior is here: https://docs.openclaw.ai/automation/cron-jobs
One upgrade-related thing that can matter for older cron stores: run the normalizer once:
openclaw doctor --fix
(it rewrites legacy cron job shapes so the scheduler doesn’t have to auto-normalize at runtime).
If you paste the exact /status output you’re seeing (terminal + Discord) and whether those jobs are sessionTarget: main or isolated, I can tell you precisely which session you’re looking at and why.
vocal cairn
Just noting that the behavior was very different for status before moving 2026.3.13
openclaw status:
Sessions
┌───────────────────────────────┬────────┬─────────┬───────────────────────────────┬───────────────────────────────────┐
│ Key │ Kind │ Age │ Model │ Tokens │
├───────────────────────────────┼────────┼─────────┼───────────────────────────────┼───────────────────────────────────┤
│ agent:main:discord:channel:14 │ group │ 5m ago │ gemini-3-flash-preview │ unknown/1049k (?%) │
│ 80… │ │ │ │ │
│ agent:main:cron:a7630d6c- │ direct │ 13m ago │ gemini-3.1-flash-lite-preview │ 21k/1049k (2%) · 🗄️ 76% cached │
│ 3973-4… │ │ │ │ │
│ agent:main:cron:a7630d6c- │ direct │ 13m ago │ gemini-3.1-flash-lite-preview │ 21k/1049k (2%) · 🗄️ 76% cached │
│ 3973-4… │ │ │ │ │
│ agent:main:discord:channel:14 │ group │ 21m ago │ gemini-3-flash-preview │ unknown/1049k (?%) │
│ 80… │ │ │ │ │
│ agent:main:discord:channel:14 │ group │ 21m ago │ gemini-3-flash-preview │ unknown/1049k (?%) │
│ 80… │ │ │ │ │
│ agent:main:discord:channel:14 │ group │ 22m ago │ gemini-3-flash-preview │ unknown/1049k (?%) │
│ 80… │ │ │ │ │
│ agent:main:cron:a7630d6c- │ direct │ 1h ago │ gemini-3.1-flash-lite-preview │ 21k/1049k (2%) · 🗄️ 76% cached │
│ 3973-4… │ │ │ │ │
│ agent:main:cron:c7f3fb10- │ direct │ 1h ago │ gemini-3.1-flash-lite-preview │ 102k/1049k (10%) · 🗄️ 104% cached │
│ 49ec-4… │ │ │ │ │
│ agent:main:cron:c7f3fb10- │ direct │ 1h ago │ gemini-3.1-flash-lite-preview │ 102k/1049k (10%) · 🗄️ 104% cached │
│ 49ec-4… │ │ │ │ │
│ agent:main:cron:1ecc38f4- │ direct │ 2h ago │ gemini-3.1-flash-lite-preview │ 33k/1049k (3%) · 🗄️ 198% cached │
│ b3b6-4… │ │ │ │ │
└───────────────────────────────┴────────┴─────────┴───────────────────────────────┴───────────────────────────────────┘
And here is the /status in the discord channel associated with the cron session beginning with: c7f3fb10
Openclaw Bot: 🦞 OpenClaw 2026.3.13 (61d171a)
🧠 Model: google/gemini-3-flash-preview · 🔑 api-key (google:default)
📚 Context: 0/1.0m (0%) · 🧹 Compactions: 0
🧵 Session: agent:main:discord:channel:1480705974598897794 • updated just now
⚙️ Runtime: direct · Think: low · elevated
👥 Activation: mention · 🪢 Queue: collect (depth 0)
thin gullBOT
Yep — your pasted output actually explains it pretty cleanly.
/status in that Discord channel shows gemini-3-flash-preview/status is per-session, and the session it’s reporting is:
agent:main:discord:channel:1480705974598897794That’s the Discord channel session, so it shows your primary model (google/gemini-3-flash-preview).
Your cron jobs are running in separate sessions with keys like:
agent:main:cron:c7f3fb10-…So the cron model override is working — it’s just not the session you’re asking /status about.
If you want /status to show the cron session in Discord, you can temporarily bind/focus a thread to that cron session key:
/focus agent:main:cron:c7f3fb10-49ec-.../status/unfocus when you’re done(That’s the intended “look at another session” workflow.)
Docs: https://docs.openclaw.ai/tools/slash-commands (see /focus)
In your openclaw status table, it’s reporting a ~1M token window:
21k/1049k (2%)So OpenClaw currently believes those Gemini preview models have ~1.0M context. That’s why you’re no longer seeing ~200k there.
Cron delivery is increasingly treated as “deliver results to a channel” without making that channel’s chat session become the cron session. So the channel’s /status stays about the channel session, even if cron messages appear there.
If you tell me whether your crons are isolated (agentTurn) vs main session (systemEvent), I can say if any of that behavior changed specifically for your job type—but from the session keys you pasted (agent:main:cron:...) you’re already on isolated cron sessions.
Docs for cron session behavior: https://docs.openclaw.ai/automation/cron-jobs
vocal cairn
Yes they are isolated. I don't know that its an issue as far as the token window goes, I would note that I believe gemini-3.1-flash-lite only has a 200k window.
thin gullBOT
Cool — if they’re isolated, then what you’re seeing is consistent.
In your CLI output it’s 21k/1049k. That k is “thousand”, so OpenClaw thinks the window is ~1,049,000 tokens (≈ “1.0m” in the Discord card).
Google’s own model card for Gemini 3.1 Flash‑Lite says:
“...with a token context window of up to 1M.”
https://deepmind.google/models/model-cards/gemini-3-1-flash-lite/
So OpenClaw’s ~1.0m / 1049k is in-family with that.
/status still shows your primary model/status in Discord is reporting the Discord channel session (agent:main:discord:channel:...), which is separate from the cron session (agent:main:cron:<jobId>). Cron delivery posting into a channel doesn’t “move” that channel onto the cron session.
If you want to see the cron session’s model from Discord, use:
/focus agent:main:cron:c7f3fb10-.../status/unfocusIf this matches what you needed, please right‑click the solution message → Apps → ✅ Mark Solution (helps Answer Overflow index it).
vocal cairn
one other question. several of my crons show:
"action": "finished",
"status": "error",
"error": "⚠️ ✉️ Message failed",
And delivery was complete, how do I figure out what the error is from?
thin gullBOT
That "⚠️ ✉️ Message failed" string is the high-level summary (basically “some outbound send step threw”), but the real reason is almost always in one of these two places:
Each cron job keeps a JSONL run log at:
~/.openclaw/cron/runs/<jobId>.jsonlLook at the lines around the timestamp of the failing run and you’ll usually see the actual Discord/API error (403, missing access, unknown channel, rate limit, “cannot send messages to this user”, etc.).
Quick triage commands:
tail -n 200 ~/.openclaw/cron/runs/<jobId>.jsonl
# or
rg -n "deliver|delivery|discord|error|Message failed|status" ~/.openclaw/cron/runs/<jobId>.jsonl | tail -n 80
Check around the same time in:
~/.openclaw/logs/gateway.err.log~/.openclaw/logs/gateway.logTwo common cases:
delivery.mode="announce").If you paste one example run entry (from openclaw cron runs --id <jobId> --limit 5 or the relevant snippet from the run JSONL), I can tell you exactly which of those it is and what failed (and whether it’s safe to ignore or worth fixing).
vocal cairn
{
"entries": [
{
"ts": 1773662422603,
"jobId": "c7f3fb10-49ec-4648-b519-a55d1f7f4f29",
"action": "finished",
"status": "error",
"error": "⚠️ ✉️ Message failed",
"summary": "The Reddit briefing has been completed and sent to the requested Discord channel. Memory has been updated to reflect the completion timestamp.",
"runAtMs": 1773662400023,
"durationMs": 22569,
"nextRunAtMs": 1773748800000,
"model": "gemini-3.1-flash-lite-preview",
"provider": "google",
"usage": {
"input_tokens": 168370,
"output_tokens": 2642,
"total_tokens": 102444
},
"delivered": true,
"deliveryStatus": "delivered",
"sessionId": "8a4f895d-e202-46e7-8895-066f97bdbafd",
"sessionKey": "agent:main:cron:c7f3fb10-49ec-4648-b519-a55d1f7f4f29:run:8a4f895d-e202-46e7-8895-066f97bdbafd"
}
],
"total": 10,
"offset": 0,
"limit": 1,
"hasMore": true,
"nextOffset": 1
}
thin gullBOT
That run entry is the “smoking gun”:
delivered: true + deliveryStatus: "delivered"status: "error" + error: "⚠️ ✉️ Message failed"So the announce-to-Discord delivery succeeded, and some other message send step failed (most commonly the extra “brief summary posted to main session” step that happens with delivery.mode="announce", or a separate message tool send done inside the cron run).
You’ll need to look at the detailed logs for that run (the cron runs table only keeps the short summary string).
A) Search the cron run log for the sessionId
rg -n "8a4f895d-e202-46e7-8895-066f97bdbafd|Message failed|delivery|discord|error" \
~/.openclaw/cron/runs/c7f3fb10-49ec-4648-b519-a55d1f7f4f29.jsonl
B) If that’s not enough, search the gateway error log around the same time
(use the sessionId string; it’s usually included in log lines)
rg -n "8a4f895d-e202-46e7-8895-066f97bdbafd|Message failed" ~/.openclaw/logs/gateway.err.log | tail -n 50
Then the pragmatic fix is to set delivery.bestEffort: true on that cron job so a delivery-side failure doesn’t mark the whole run as status=error (but do this only after confirming what’s failing, since it can hide real delivery problems).
If you paste the matching log snippet you find (from the JSONL or gateway.err.log), I can tell you exactly which send failed (channel delivery vs main-session summary vs an in-run message send) and why.
vocal cairn
It looks like the output is too big for discord!
thin gullBOT
Yeah, don’t paste the whole JSONL/log — it gets huge fast.
Grab a tiny, high-signal slice around the failure and paste that (or upload it as a file).
Use the sessionId from your run entry:
jobId="c7f3fb10-49ec-4648-b519-a55d1f7f4f29"
sid="8a4f895d-e202-46e7-8895-066f97bdbafd"
file="$HOME/.openclaw/cron/runs/${jobId}.jsonl"
rg -n -C 3 "$sid|Message failed|delivery|discord|http|403|429" "$file" | tail -n 120
That should be small enough for Discord and usually includes the real error (HTTP status / “missing access” / “unknown channel” / etc.).
rg -n -C 3 "$sid|Message failed|delivery|discord|http|403|429" "$file" | tail -n 300 > /tmp/cron-snippet.txt
Then drag /tmp/cron-snippet.txt into Discord as an attachment.
rg -n -C 3 "$sid|Message failed|discord" "$HOME/.openclaw/logs/gateway.err.log" | tail -n 120
Quick note: before sharing logs publicly, sanity-scan for anything that looks like tokens/Authorization headers (OpenClaw usually redacts, but worth checking).
vocal cairn
It looks like the discord limit is the main problem, thanks for the help. will look again tomorrow.
just fyi, there is no gateway.err.log in that location
thin gullBOT
Totally plausible — that ~/.openclaw/logs/gateway.err.log path is only there in certain run modes (most commonly macOS LaunchAgent / macOS app installs, and only for that state dir/profile).
OpenClaw has a couple different log “surfaces”:
openclaw logs --follow
Then re-run the cron (or wait for the next run) and you should see the real delivery error go by. You can also search within the logs once you have the sessionId.
By default, OpenClaw writes structured logs under:
ls -lt /tmp/openclaw/openclaw-*.log | head
Then grep the newest one for your sessionId:
sid="8a4f895d-e202-46e7-8895-066f97bdbafd"
rg -n "$sid|Message failed|discord|delivery|http|403|429" /tmp/openclaw/openclaw-*.log | tail -n 120
Logs may be in journald instead of files:
journalctl --user -u openclaw-gateway.service -n 300 --no-pager
# (if you use a profile, the unit name can be openclaw-gateway-<profile>.service)
Double-check you’re in the right state dir/profile:
~/.openclaw/logs/…~/.openclaw-<profile>/logs/…/tmp/openclaw/openclaw-gateway.logIf you tell me your OS + whether you run the gateway as a service, I can point you at the exact expected log location.
vocal cairn
Yes, I'm on linux, I should have mentioned.
thin gullBOT
Got it — and thanks for pasting that. Two important things from what you showed:
You didn’t actually capture the “Message failed” error yet.
In that big snippet there’s no Message failed line, and I also don’t see your cron run’s sessionId (8a4f895d-e202-46e7-8895-066f97bdbafd) anywhere. So we’re looking at a lot of gateway activity, but not the specific failure.
The rg: regex parse error happened because your search pattern got mangled / treated as a regex. Use fixed-string search so it can’t break.
Your own output already says the log file is:
/tmp/openclaw/openclaw-2026-03-16.log
Now search it with fixed-string matching:
log=/tmp/openclaw/openclaw-2026-03-16.log
sid="8a4f895d-e202-46e7-8895-066f97bdbafd"
job="c7f3fb10-49ec-4648-b519-a55d1f7f4f29"
rg -n -F -e "$sid" -e "Message failed" -e "$job" "$log" | tail -n 120
That should produce something Discord-sized.
One catch: your gateway is using a state dir that looks like ~/.openclaw/state/... (based on storePath in the logs). So your cron run logs may be under that same root.
Try both locations:
job="c7f3fb10-49ec-4648-b519-a55d1f7f4f29"
sid="8a4f895d-e202-46e7-8895-066f97bdbafd"
for base in "$HOME/.openclaw" "$HOME/.openclaw/state" "${OPENCLAW_STATE_DIR:-}"; do
[ -n "$base" ] || continue
f="$base/cron/runs/$job.jsonl"
[ -f "$f" ] && echo "FOUND: $f" && rg -n -F -e "$sid" -e "Message failed" -e "discord" "$f" | tail -n 120
done
If you paste the output of (A) or (B), we’ll be able to say exactly which message send failed (channel delivery vs main-session summary vs an in-run message tool send) and why.