3.3 KiB
Session: 2026-03-03 22:38:47 UTC
- Session Key: agent:main:main
- Session ID: f4588213-7254-4bc1-a237-987798220199
- Source: gateway:sessions.reset
Conversation Summary
user: Sender (untrusted metadata):
{
"label": "openclaw-tui (gateway-client)",
"id": "gateway-client",
"name": "openclaw-tui",
"username": "openclaw-tui"
}
[Tue 2026-03-03 22:27 UTC] Test openai/gpt-5.2 with litellm API, curl it. Use the already configured litellm API key
assistant: reply_to_current Done — tested successfully with your configured LITELLM_API_KEY.
Used:
BASE_URL="http://192.168.153.113:18804/v1"
curl -sS "$BASE_URL/chat/completions" \
-H "Content-Type: application/json" \
-H "Authorization: Bearer $LITELLM_API_KEY" \
-d '{"model":"openai/gpt-5.2","messages":[{"role":"user","content":"Reply with exactly: litellm-ok"}],"temperature":0}'
Result came back:
litellm-ok (model resolved to gpt-5.2-2025-12-11).
user: Sender (untrusted metadata):
{
"label": "openclaw-tui (gateway-client)",
"id": "gateway-client",
"name": "openclaw-tui",
"username": "openclaw-tui"
}
[Tue 2026-03-03 22:29 UTC] Great. Now let's see why using /model litellm/gpt-5.2 doesn't work
assistant: reply_to_current Nice catch — I just tested it from inside this same session, and litellm/gpt-5.2 does resolve now.
I verified by setting the session model via session_status override, and it accepted:
Model: litellm/gpt-5.2- auth profile:
litellm:default
So if /model litellm/gpt-5.2 fails for you, likely causes are:
-
Stale picker/allowlist state in the current TUI session
(model was added after the session started). -
Profile/config mismatch
(e.g., TUI connected to a different profile/config than the one we edited). -
Old slash-command cache in that client session.
Quick checks in your TUI:
/model list(see iflitellm/gpt-5.2appears)/model status(shows current model + provider info)
If it still fails, restart the client/gateway session and retry:
openclaw gateway restart
If you paste the exact /model error text, I can pinpoint it immediately.
user: Sender (untrusted metadata):
{
"label": "openclaw-tui (gateway-client)",
"id": "gateway-client",
"name": "openclaw-tui",
"username": "openclaw-tui"
}
[Tue 2026-03-03 22:37 UTC] test user: Sender (untrusted metadata):
{
"label": "openclaw-tui (gateway-client)",
"id": "gateway-client",
"name": "openclaw-tui",
"username": "openclaw-tui"
}
[Tue 2026-03-03 22:37 UTC] model set to litellm/gpt-5.2
test
run error: LLM request timed out. assistant: reply_to_current Yep — that error makes sense given current session size.
I just re-tested the LiteLLM endpoint directly with openai/gpt-5.2; it responds fast (~1.4s for a tiny prompt), so the model/provider itself is healthy.
Most likely cause: your session context is huge, and gpt-5.2 timed out on a full-context turn.
Try this sequence in TUI:
/reset/model litellm/gpt-5.2- Send a tiny prompt:
ping
If that works, timeout was context-related (not model routing).
If it still times out after reset, send me the exact /model status output and I’ll pinpoint whether it’s a gateway timeout vs LiteLLM upstream timeout.