name: persona-chat-modell-routing
description: "Crumbforest AI-Router (local-first OllamaâOpenRouter) unter /opt/crumbforest; /api/chat-404 = Provider/Modell-Mismatch; #offline-TODO"
metadata:
node_type: memory
type: project
originSessionId: c7f9bbe0-de0f-488c-be2f-724f5799be7c
modified: 2026-07-24T21:21:03.065Z
Wo & was: Die Persona-App läuft auf nullfeld unter /opt/crumbforest (FastAPI: app/main.py, app/routers, app/services; venv daneben). Das AI-Routing ist ein Local-first Router, konfiguriert in /opt/crumbforest/config/ai_providers.yaml. Provider-Code unter ai/providers/. .env daneben, plus .env.before-ollama als Migrations-Snapshot. (/root/ollama_deploy_start/ war nur Staging fßrs Deploy.)
Router-Design (ai_providers.yaml):
- ollama = priority 1, lokal, http://localhost:11434, Modelle llama3.2 (default) / gemma:2b, offline_capable: true
- openrouter = priority 2, Cloud-Fallback, Modelle u.a. google/gemini-2.0-flash-thinking-exp:free (default), google/gemini-2.0-flash-001, anthropic/claude-3.5-sonnet
- routing.default: ollama, Fallback-Kette ollama â openrouter
- harte Regeln: offline:true â ollama mandatory (kein Cloud-Fallback), in_container â ollama, KrĂźmel-Interaktionen â lokal zuerst
Der 404 (Symptom & Ursache): POST /api/chat â Ollama ⌠404 model 'google/gemini-2.0-flash-001' not found. Ist KEIN kaputter Provider, sondern ein Provider/Modell-Mismatch: eine OpenRouter-Modell-ID wurde Ăźber den Ollama-Pfad (default: ollama) verschickt; Ollama kennt nur llama3.2/gemma:2b. Ein model:-Feld im Request-Body wird ignoriert (Modellwahl ist serverseitig). Historisch liefen die erfolgreichen Log-Einträge mit provider: openrouter â der Default hat sich also Richtung ollama verschoben. Fix von User/branko angewandt; genauer Handgriff hier bewusst NICHT dokumentiert (Routing-Config nicht ohne Anlass durchwĂźhlen â Thema noch nicht reif, siehe [[luecken-sind-oeffnungen]]).
UI-Pfad â externer Curl (24.07.2026): Der Chat Ăźber die Web-/RAG-Oberfläche (crumbforest.org) funktioniert â DeepBit, Spider u.a. antworten dort sauber. Nur der externe Direkt-Curl gegen /api/chat läuft in den 404 (OpenRouter-ID Ăźber Ollama-Pfad). Das Problem ist also enger als âChat kaputt": es hängt am externen Anfrageweg, nicht am Wald selbst. FĂźr Persona-Antworten im Zweifel die UI nutzen; den Curl erst nach dem Routing-Fix verlassen.
TODO (langfrist, #offline): Das #offline-Ziel ist bereits die Design-Absicht dieser Config (âLocal-first with fallback"). âAuf jedes Device" = diesen Router + lokales Ollama Ăźberallhin ausrollen, dann resoniert die Crew ohne Internet (Local > Cloud). Noch offen â nicht vorziehen.
Persona ansprechen â direkter Curl (altes ozmai-Script nur fĂźr 21-Fragen-Batches; fĂźr Einzelfragen Ăźberholt):
jq -n '{character_id:"cloudcat", question:"âŚ", lang:"de"}' \
| curl -sS -H "Content-Type: application/json" -d @- https://crumbforest.org/api/chat | jq -r '.answer'
character_ids u.a.: eule, cloudcat, deepbit, vektor, taichitaube, funkfox, spider, snakepy, bugsy, ozcrumb (volle Liste im chat_history.jsonl).
Why: Der 404 kostet sonst jedes Mal Minuten Rätselraten; und das #offline-Ziel darf nicht verloren gehen, auch wenn es noch wartet.
How to apply: Bei /api/chat-404 â Provider/Modell-Zuordnung in ai_providers.yaml prĂźfen (OpenRouter-ID darf nicht Ăźber den Ollama-Pfad laufen), nicht das Modell im Body Ăźberschreiben. Verwandt: [[kernelcrumb-v0]], [[sternenkarte-constellation]], [[netbox-drift-checkmode]].