chore(memory): reclassify topical notes into subfolders

2026-03-11 18:56:55 +00:00
parent 575e4a8ba6
commit fba23985c6
22 changed files with 8 additions and 1 deletions
--- a/memory/incidents/2026-03-03-litellm-model.md
+++ b/memory/incidents/2026-03-03-litellm-model.md
@@ -0,0 +1,110 @@
+# 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 I’ll pinpoint whether it’s a gateway timeout vs LiteLLM upstream timeout.