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

111 lines
3.3 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 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):
```json
{
"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:
```bash
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):
```json
{
"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):
```json
{
"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):
```json
{
"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.