General

TriForce Update: Fallback-Kette bereinigt, lokale Ollama-Modelle entfernt

Brumo the stuffed bear sitting in a data center with headphones, holding a leaf, next to a mug that says Efficiency beats enthusiasm - AILinux mascot
Brumo — das inoffizielle AILinux-Maskottchen, bewacht das Datacenter.

Kurzes technisches Update aus dem heutigen Bug-Hunt.

Die Fallback-Kette in TriForce wurde weiter bereinigt und an die reale Verfügbarkeit angepasst. Wichtigster Punkt: lokale Ollama-Modelle sind nicht mehr Teil der automatischen Nova-Fallback-Kette. Auf dem aktuellen System ist das sinnvoller, weil die CPU nicht als verlässliche Fallback-Basis für lokale Modelle taugt.

Stattdessen gilt jetzt:

  • Ollama-Cloud zuerst
  • OpenRouter-Free nur als letzter Notnagel

Zusätzlich wurde die Reihenfolge innerhalb der Ollama-Cloud-Fallbacks sinnvoll priorisiert. Breite Allrounder kommen zuerst, spezialisiertere Modelle später.

Aktive Cloud-Reihenfolge:

  1. ollama/gpt-oss:120b-cloud
  2. ollama/deepseek-v3.2:cloud
  3. ollama/kimi-k2-thinking:cloud
  4. ollama/glm-5:cloud
  5. ollama/qwen3-coder:480b-cloud

Erst danach folgt als letzter Fallback:

  • openrouter/openai/gpt-oss-120b:free
  • openrouter/mistralai/mistral-small-3.1-24b-instruct:free
  • openrouter/stepfun/step-3.5-flash:free

Nebenbei wurde auch die Content-Schiene stabilisiert: automatische Content-Jobs hängen nicht mehr hart an gemini-mcp, damit API-Limits dort nicht direkt die WordPress- oder Forum-Posts blockieren.

Das Ziel bleibt gleich: weniger fragile Sonderfälle, mehr belastbare Fallbacks, sauberere Prioritäten und eine stabilere Produktionsbasis für TriForce und AILinux.

Weitere technische Updates folgen im Forum und hier auf der Seite.

AI Assistant
Context loaded: TriForce Update: Fallback-Kette bereinigt, lokale Ollama-Mod