#model input setting

1 messages · Page 1 of 1 (latest)

teal ruin
#

"models": [
{
"id": "qwen3.5:397b-cloud",
"name": "qwen3.5:397b-cloud",
"api": "ollama",
"input": [
"text",
"image"
]
}
]
can i remove "input": [
"text",
"image"
] , what will it happen, and whats reasoning default

mossy saddleBOT
sick daggerBOT
#

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

mossy saddleBOT
teal ruin
#

🔍 Let Me Check What's Actually Wrong

terminated

terminated

terminated

terminated

/status

🦞 OpenClaw 2026.4.21 (f788c88)
🧠 Model: nvidia/z-ai/glm4.7 · 🔑 api-key (models.json)
🔄 Fallbacks: google/gemini-3.1-flash-lite-preview, google/gemini-3-flash-preview,
nvidia/moonshotai/kimi-k2-thinking, ollama/minimax-m2.7:cloud, google/gemini-2.5-flash,
google/gemini-2.5-flash-lite, ollama/kimi-k2-thinking:cloud, nvidia/z-ai/glm4.7, google/gemma-4-31b-it,
openrouter/google/gemma-4-31b-it:free, llamacpp/gemma-4-26B-A4B-it-UD-Q5_K_S
🧮 Tokens: 1.3m in / 33k out · 💵 Cost: $0.0000
🗄️ Cache: 10% hit · 140k cached, 0 new
📚 Context: 140k/200k (70%) · 🧹 Compactions: 5
🧵 Session: agent:main:main • updated just now
⚙️ Runtime: direct · Think: adaptive
🪢 Queue: collect (depth 3)
connected | idle

vestal harnessBOT
#

yep.

If you remove:

"input": ["text", "image"]

OpenClaw treats it as:

"input": ["text"]

So what happens:

  • text chats still work
#
  • image input is no longer sent to that model
  • if you attach/send images, OpenClaw filters those image parts out instead of passing them through

So, remove it only if you want that model to be text-only.

Also, for custom provider model entries, if reasoning is omitted, the default is:

"reasoning": false

Small gotcha, there are two different things people mean by “reasoning”:

  • model capability flag: "reasoning": false by default if omitted
  • /reasoning visibility in chat: default fallback is off unless you set reasoningDefault

Docs:

teal ruin
#

streaming watchdog: no stream updates for 30s; resetting status. The backend may have dropped this
run silently — send a new message to resync.
connected | idle

vestal harnessBOT
#

that message is just a stream timeout/watchdog notice, not a model config error.

It means:

  • OpenClaw was waiting for stream chunks
  • nothing arrived for 30s
  • it reset the UI/status to idle
  • the backend run may have stalled or dropped silently

So usually the next step is just:

  • send the message again, or
  • run /status to confirm things are healthy

If it happens a lot, then I’d check:

# 
openclaw logs --follow
openclaw status

and make sure you’re on the latest version, because this is more of a streaming/backend issue than an "input" or "reasoning" config issue.

teal ruin
#

21:09:23+08:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_failover_decision","tags":["error_handling","failover","assistant","fallback_model"],"runId":"1d1589e8-ffd3-47bc-b991-33abd3ef5199","stage":"assistant","decision":"fallback_model","failoverReason":"timeout","profileFailureReason":null,"provider":"llamacpp","model":"gemma-4-26B-A4B-it-UD-Q5_K_S","sourceProvider":"llamacpp","sourceModel":"gemma-4-26B-A4B-it-UD-Q5_K_S","fallbackConfigured":true,"timedOut":false,"aborted":false,"status":408,"rawErrorPreview":"Request timed out.","rawErrorHash":"sha256:98123ccc6904","providerRuntimeFailureKind":"timeout"} embedded run failover decision
21:09:23+08:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=nested durationMs=151808 error="FailoverError: LLM request timed out."
21:09:23+08:00 error diagnostic {"subsystem":"diagnostic"} lane task error: lane=session:agent:main:cron:8055b036-75f6-45d5-bb28-f0f284fa774e durationMs=151809 error="FailoverError: LLM request timed out."
21:09:23+08:00 warn model-fallback/decision {"subsystem":"model-fallback/decision"} {"event":"model_fallback_decision","tags":["error_handling","model_fallback","candidate_failed"],"runId":"1d1589e8-ffd3-47bc-b991-33abd3ef5199","decision":"candidate_failed","requestedProvider":"llamacpp","requestedModel":"gemma-4-26B-A4B-it-UD-Q5_K_S","candidateProvider":"llamacpp","candidateModel":"gemma-4-26B-A4B-it-UD-Q5_K_S","attempt":1,"total":11,"reason":"timeout","status":408,"errorPreview":"LLM request timed out.","errorHash":"sha256:321034bb3121","nextCandidateProvider":"google","nextCandidateModel":"gemini-3.1-flash-lite-preview","isPrimary":true,"requestedModelMatched":true,"fallbackConfigured":true} model fallback decision

vestal harnessBOT
#

this log is basically saying:

  • your primary model timed out
  • OpenClaw treated that as a failover error
  • it then moved to the next fallback model
  • so this is not an "input" / image-capability problem

In your log:

  • failed model: llamacpp/gemma-4-26B-A4B-it-UD-Q5_K_S
  • reason: timeout / 408
  • next fallback: google/gemini-3.1-flash-lite-preview

So OpenClaw is doing the expected thing here.

What it usually means in practice:

#
  • the local model/server is too slow for the request
  • or the context/request is too large
  • or the llama.cpp server stalled and stopped streaming tokens

If you want to reduce this, the main knob is:

agents: {
  defaults: {
    llm: {
      idleTimeoutSeconds: 300
    }
  }
}

Or use a faster/smaller local model.

#

Also, from your earlier /status, you had a pretty big context loaded. A local 26B model with large context can absolutely hit this kind of timeout.

Docs:

If you want, paste your agents.defaults block and I can suggest a sane timeout + fallback setup.

teal ruin
#

reasoning vs thinking?

vestal harnessBOT
#

in OpenClaw, they’re related but not the same thing:

  • thinking = how much internal thought budget the model gets

    • controlled by /think
    • examples: off, low, medium, high, adaptive
    • this affects how the model runs

  • reasoning = whether that thought/reasoning is shown back to you

    • controlled by /reasoning
    • values: off, on, stream
    • this affects what you see

So:

  • /think high = “use more thinking”
  • /reasoning on = “show the reasoning message”
  • you can have more thinking with reasoning hidden
#
  • you can also have reasoning visibility off even if the model is thinking a lot

And one more layer:

  • model config "reasoning": true/false = whether OpenClaw treats that model as reasoning-capable at all

So the short version is:

thinking = compute budget
reasoning = visibility/output

Docs: https://docs.openclaw.ai/tools/thinking

teal ruin
#

do fallback go back to primary model?

vestal harnessBOT
#

usually, yes on the next run, but not mid-run.

How it works:

  • for one request/run, OpenClaw tries:

    1. primary
    2. fallback 1
    3. fallback 2
    4. etc.

  • it does not jump back to primary halfway through that same failed run

  • on the next new message/run, it normally starts from the selected primary again

Exceptions:

  • if the primary/profile is in cooldown or temporarily disabled, it may keep using another candidate
#
  • if you manually changed the model with /model, that changes the selected model for the session

So the short version is:

  • same run: no, it keeps moving forward through fallbacks
  • next run/message: yes, usually it tries primary again

Docs: https://docs.openclaw.ai/concepts/model-failover

teal ruin
#

🦞 OpenClaw 2026.4.21 (f788c88)
🧠 Model: nvidia/minimaxai/minimax-m2.7 · 🔑 api-key (models.json)
🔄 Fallbacks: google/gemini-3.1-flash-lite-preview, google/gemini-3-flash-preview,
nvidia/moonshotai/kimi-k2-thinking, ollama/minimax-m2.7:cloud, google/gemini-2.5-flash,
google/gemini-2.5-flash-lite, ollama/kimi-k2-thinking:cloud, nvidia/z-ai/glm4.7, google/gemma-4-31b-it,
openrouter/google/gemma-4-31b-it:free
🧮 Tokens: 229k in / 860 out · 💵 Cost: $0.0000
🗄️ Cache: 1% hit · 1.3k cached, 0 new
📚 Context: 44k/200k (22%) · 🧹 Compactions: 6
🧵 Session: agent:main:main • updated just now
📌 Tasks: 1 recent failure · cron · Workspace Knowledge Scanner · Channel is required when multiple
channels are configured: discord, telegram Set delivery.channel explicitly or use a m…
⚙️ Runtime: direct · Think: adaptive
🪢 Queue: collect (depth 2)
connected | idle

it just stuck there, i send msg and no response

vestal harnessBOT
#

two separate things are showing up there:

  1. the recent task failure

    • Channel is required when multiple channels are configured: discord, telegram
    • that is a cron delivery config issue for Workspace Knowledge Scanner
    • it means that cron needs an explicit delivery.channel (for example discord)
    • that part is annoying, but it should not be the normal reason your chat replies stop

  2. the bot being connected but not replying

    • connected | idle means Discord is connected
    • if you send a message and nothing starts, the gateway/session is probably wedged or silently failing before reply

I’d try this exact order:

openclaw status --all
# 
openclaw logs --follow

Then send one tiny test message like hi.

If still nothing, restart the gateway:

openclaw gateway restart

Then test again.

Also, fix that cron separately by setting its delivery channel explicitly, since you have both Discord and Telegram configured.

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

#

If you want, paste the log lines that appear right after you send hi, that’ll usually show the real blocker fast.

teal ruin
#

Diagnosis (read-only)

Gateway connection details:
Gateway target: ws://127.0.0.1:18789
Source: local loopback
Config: /home/rr420/.openclaw/openclaw.json
Bind: loopback

✓ Config: /home/rr420/.openclaw/openclaw.json
✓ Secret diagnostics (0)
✓ Restart sentinel: none
! Port 18789
Port 18789 is already in use.

  • pid 433 rr420: openclaw-gateway (127.0.0.1:18789)
  • Gateway already running locally. Stop it (openclaw gateway stop) or use a different port.
    ! Tailscale: serve · unknown · msi-1.tail9f107f.ts.net
    https: https://msi-1.tail9f107f.ts.net
    ✓ Skills: 21 eligible · 0 missing · /home/rr420/my_projects/openclaw
    ✓ Plugin compatibility (none)
    ✓ Channel issues (none)

Pasteable debug report. Auth tokens redacted.
Troubleshooting: https://docs.openclaw.ai/troubleshooting

◇

vestal harnessBOT
#

this report is actually pretty clean.

The important bit is:

  • openclaw-gateway is already running
  • port 18789 is in use by the existing gateway
  • so don’t run openclaw gateway start again
  • if you want to bounce it, use openclaw gateway restart

So this status does not explain the “I send a message and get no reply” problem yet.

Next useful step:

openclaw logs --follow
#

Then send one simple message like hi and watch what log lines appear.

If you want to refresh the gateway first, do:

openclaw gateway restart
openclaw logs --follow

Then test again.

Also, that Channel is required when multiple channels are configured issue is still a separate cron config problem, not the port problem.

If you paste the log lines from logs --follow right after sending hi, we can probably pinpoint it fast.

teal ruin
#

21:25:01+08:00 info agents/tool-images {"subsystem":"agents/tool-images"} {"label":"read:/tmp/dashboard_screenshot.png","fileName":"dashboard_screenshot.png","sourceMimeType":"image/png","sourceWidth":1280,"sourceHeight":577,"sourceBytes":3420,"maxBytes":5242880,"maxDimensionPx":1200,"triggerOverBytes":false,"triggerOverDimensions":true,"outputMimeType":"image/jpeg","outputBytes":2236,"outputQuality":85,"outputMaxSide":1200,"byteReductionPct":34.6} Image resized to fit limits: dashboard_screenshot.png 1280x577px 3.3KB -> 2.2KB (-34.6%)
21:25:50+08:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 131ms conn=5aaadcde…0b29 id=06126d15…3298
21:25:50+08:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ chat.history 223ms conn=5aaadcde…0b29 id=c379e138…6e47
21:25:50+08:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 115ms conn=5aaadcde…0b29 id=f72c4ec1…0791
21:29:50+08:00 info agents/tool-images {"subsystem":"agents/tool-images"} {"label":"read:/tmp/dashboard_screenshot2.png","fileName":"dashboard_screenshot2.png","sourceMimeType":"image/png","sourceWidth":1280,"sourceHeight":577,"sourceBytes":124780,"maxBytes":5242880,"maxDimensionPx":1200,"triggerOverBytes":false,"triggerOverDimensions":true,"outputMimeType":"image/jpeg","outputBytes":59652,"outputQuality":85,"outputMaxSide":1200,"byteReductionPct":52.2} Image resized to fit limits: dashboard_screenshot2.png 1280x577px 121.9KB -> 58.3KB (-52.2%)
21:31:02+08:00 info cron {"module":"cron","storePath":"/home/rr420/.openclaw/cron/jobs.json"} {"pruned":1,"retentionMs":86400000} cron-reaper: pruned 1 expired cron run session(s)

vestal harnessBOT
#

those log lines are not the stuck reply.

They only show:

  • image resize housekeeping
  • dashboard/websocket reads (sessions.list, chat.history)
  • cron cleanup

What’s missing is any Discord inbound activity for your test message.

So right now the useful conclusion is:

  • OpenClaw did not visibly start processing that Discord message
  • or the pasted log window missed the exact moment

On the next test, watch for lines like:

#
  • MESSAGE_CREATE
  • DiscordMessageListener
  • discord inbound worker
  • a new runId

If you see none of those after sending a message, then this is likely a Discord-side routing/filter issue, for example:

  • thread-specific behavior
  • requireMention
  • guild/channel allowlist rules
  • thread binding/session weirdness

If you do see those lines, then it’s a handler/runtime problem instead.

Good next check:

  1. run openclaw logs --follow
  2. send hi in this same thread
#
  1. if nothing Discord-related appears, try one test in a DM or normal channel

If DM works but this thread does not, I’d start looking at Discord thread config / filters.

Docs: https://docs.openclaw.ai/channels/discord

teal ruin
#

i use tui, say hi , no repsonse , no new log

vestal harnessBOT
#

ah, that narrows it down a lot.

If you type hi in TUI and there is no new gateway log at all, then the message is probably not leaving the TUI client. That means this is likely not a model/fallback issue.

Quick split test:

  1. In TUI, run:
    /status
  2. Watch the footer/status line

What should happen:

  • it should briefly change from idle to sending or running
  • gateway logs should show a new request

If /status also does nothing, then it’s a TUI input/submit issue.

#

Things to check:

  • press Enter, not Alt+Enter
  • restart the TUI
  • try launching it in a plain terminal, not inside tmux/screen if you are using one
  • if you expect replies to also go to chat surfaces, turn on:
    /deliver on
    or start with:
    openclaw tui --deliver

From the docs, the official TUI triage is:

  • /status in TUI
  • openclaw logs --follow
#
  • openclaw status
  • openclaw models status

Docs: https://docs.openclaw.ai/web/tui

If /status in TUI also produces zero log activity, I’m leaning TUI-side bug/input handling, not gateway/model.

teal ruin
#

/status

🦞 OpenClaw 2026.4.21 (f788c88)
🧠 Model: nvidia/minimaxai/minimax-m2.7 · 🔑 api-key (models.json)
🔄 Fallbacks: google/gemini-3.1-flash-lite-preview, google/gemini-3-flash-preview,
nvidia/moonshotai/kimi-k2-thinking, ollama/minimax-m2.7:cloud, google/gemini-2.5-flash,
google/gemini-2.5-flash-lite, ollama/kimi-k2-thinking:cloud, nvidia/z-ai/glm4.7, google/gemma-4-31b-it,
openrouter/google/gemma-4-31b-it:free
🧮 Tokens: 229k in / 860 out · 💵 Cost: $0.0000
🗄️ Cache: 1% hit · 1.3k cached, 0 new
📚 Context: 50k/200k (25%) · 🧹 Compactions: 6
🧵 Session: agent:main:main • updated just now
⚙️ Runtime: direct · Think: adaptive
🪢 Queue: collect (depth 3)
connected | idle
agent main (Yumika) | session main (openclaw-tui) | nvidia/minimaxai/minimax-m2.7 | think adaptive |
tokens 35k/200k (17%)

21:35:41+08:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"58557be0-a76e-462f-9324-344e7e4d02f8","isError":true,"error":"terminated","failoverReason":null,"model":"z-ai/glm4.7","provider":"nvidia","rawErrorPreview":"terminated","rawErrorHash":"sha256:e8c95a2a7271","providerRuntimeFailureKind":"unknown"} embedded run agent end
21:35:48+08:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 131ms conn=5aaadcde…0b29 id=9a72bcb0…bec3
21:36:03+08:00 info cron {"module":"cron","storePath":"/home/rr420/.openclaw/cron/jobs.json"} {"pruned":1,"retentionMs":86400000} cron-reaper: pruned 1 expired cron run session(s)

#

21:37:47+08:00 info gateway/ws {"subsystem":"gateway/ws"} ⇄ res ✓ sessions.list 73ms conn=5aaadcde…0b29 id=536f57be…c0f2
21:39:31+08:00 info agents/tool-images {"subsystem":"agents/tool-images"} {"label":"read:/tmp/dashboard_live.png","fileName":"dashboard_live.png","sourceMimeType":"image/png","sourceWidth":1280,"sourceHeight":577,"sourceBytes":124572,"maxBytes":5242880,"maxDimensionPx":1200,"triggerOverBytes":false,"triggerOverDimensions":true,"outputMimeType":"image/jpeg","outputBytes":59638,"outputQuality":85,"outputMaxSide":1200,"byteReductionPct":52.1} Image resized to fit limits: dashboard_live.png 1280x577px 121.7KB -> 58.2KB (-52.1%)
21:39:54+08:00 warn agent/embedded {"subsystem":"agent/embedded"} {"event":"embedded_run_agent_end","tags":["error_handling","lifecycle","agent_end","assistant_error"],"runId":"3cc2b444-9a2d-4d1c-82ee-4f5c720c3fc2","isError":true,"error":"terminated","failoverReason":null,"model":"minimaxai/minimax-m2.7","provider":"nvidia","rawErrorPreview":"terminated","rawErrorHash":"sha256:e8c95a2a7271","providerRuntimeFailureKind":"unknown"} embedded run agent end

vestal harnessBOT
#

okay, this is the first actually useful log 👍

It shows:

  • the TUI did send a run
  • that run started on nvidia/minimaxai/minimax-m2.7
  • then it ended with:
error: "terminated"
failoverReason: null
providerRuntimeFailureKind: "unknown"

So the problem is not “TUI never sends”.
The problem is the run starts, then gets killed early.

#

That usually points to one of these:

  • manual abort / cancel
  • session reset / reconnect
  • gateway restart
  • provider stream died unexpectedly
  • model/runtime bug on that provider

Also important: because failoverReason is null, OpenClaw did not classify this as a normal timeout/fallback case.

What I’d do next:

  1. Try one message on a different configured model

    • if that works, this is probably Minimax-specific

  2. Restart the gateway once