Files
swarm-zap/memory/incidents/2026-03-03-litellm-model.md

3.3 KiB
Raw Blame History

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:

  1. Stale picker/allowlist state in the current TUI session
    (model was added after the session started).

  2. Profile/config mismatch
    (e.g., TUI connected to a different profile/config than the one we edited).

  3. Old slash-command cache in that client session.

Quick checks in your TUI:

  • /model list (see if litellm/gpt-5.2 appears)
  • /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:

  1. /reset
  2. /model litellm/gpt-5.2
  3. 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 Ill pinpoint whether its a gateway timeout vs LiteLLM upstream timeout.