Zum Inhalt

OpenCode als AI Operations Console

Stand: 2026-06-02

Kurzfazit

OpenCode ist bei Lanstyle nicht primaer ein Coding-Werkzeug. Es ist die interaktive AI Operations Console fuer Infrastruktur, Troubleshooting, Change Reviews, Runbooks, Microsoft 365, Netzwerk, Proxmox, NetBox und dokumentationsnahe Betriebsarbeit.

Die beste Zielarchitektur bleibt ein Hybrid-Modell: OpenCode bleibt fuer schnelle Arbeit direkt an LiteLLM und Remote MCP angebunden. Hermes liefert kuratierten Kontext, Memory, Retrieval und Policy-Hinweise. Der Live-Fokus hat sich aber verschoben: Nicht mehr "Tool aktivieren", sondern "Tool sichtbar, scoped und alltagstauglich machen".

OpenCode Reality Check

Usage Profile

Profil Aktuelle Reife Zielbild
Coding nutzbar, aber nicht Hauptzweck Repo- und Skriptarbeit bleibt moeglich, darf Operations-UX nicht dominieren
Operations stark wachsend Tagesbetrieb mit Status, Health, Drift, Backup, Locks und Next Action
Infrastructure stark Proxmox, NetBox, NPM, VLAN, Services und APIs ueber read-only/preflight/scoped Actions
Knowledge vorbereitet Hermes/Obsidian/Qdrant liefern Kontext vor groesseren Anfragen
Approvals produktiv vorbereitet Approval Preview und Changeplan als klare Operator-Entscheidung
Reviews gut vorbereitet Change Review, AI Review, Policy/Risk und Rollback Readiness als Standard
Incidents vorbereitet Timeline, Health, Drift, Locks, Safe Mode und Runbooks in einem Incident Mode
Automation vorbereitet Golden Paths, Scheduled Workflows und Self-Service Templates ohne Auto-Remediation

Noch coding-lastige Stellen

  • Einige Dokumente sprechen noch von Coding-Agent, obwohl OpenCode operativ breiter genutzt wird.
  • Modellnamen wie qwen3-coder-next tauchen technisch weiter auf, obwohl Benutzer Lanstyle-Aliase sehen sollen.
  • Das Admin-Profil erlaubt lokale bash/edit; das ist fuer Administratoren akzeptiert, darf aber nicht als normales Operator-Profil missverstanden werden.
  • Alte Roadmap-Abschnitte beschreiben OpenCode noch zu stark als Agenten-Frontend fuer Code- und Shell-nahe Aufgaben.
  • Tool-Antworten koennen noch zu roh oder zu lang werden, wenn Debug-/JSON-Felder nicht konsequent hinter Operator Summaries verschwinden.

Fehlende Operations-Bausteine

  • Hermes-/MCP-Kontextsuche ist grundsaetzlich nutzbar, aber noch nicht als verlaesslicher OpenCode-Standardmodus validiert.
  • Es gibt noch keinen expliziten OpenCode-Moduswahlschalter fuer Fast Ops, Change Review oder Incident Mode.
  • OpenWebUI-Modelllisten sind noch nicht fuer normale User live gegen Admin-/Operator-Sicht verifiziert.
  • Reindex, Memory Consolidation und Retrieval Validation sind noch zu stark von Secret-Verfuegbarkeit ausserhalb stabiler Server-Jobs abhaengig.
  • Intune, M365, Aruba, UniFi und Firewall-Arbeit sind noch nicht als eigene Mode-/Retrieval-/Risk-Profile beschrieben.

UX-Probleme

  • Wenn OpenCode eine API-Rohantwort zeigt, wirkt die Plattform technischer als noetig.
  • Bei langen Infrastrukturprompts entsteht Token-Druck durch viel Kontext, Tool Output und historische Doku.
  • Operatoren brauchen haeufig zuerst Gesamtstatus, Blocker, Next Action, Risk und Out of Scope, nicht interne IDs.
  • Unsicherheit muss sichtbar bleiben: bestaetigte Fakten, Interpretation und Annahmen duerfen nicht vermischt werden.

Hermes als zentrale Ops-Kontextschicht

flowchart TD
  User["User"] --> OpenCode["OpenCode"]
  OpenCode --> HermesSearch["Hermes Context Search"]
  HermesSearch --> Obsidian["Obsidian Knowledge"]
  HermesSearch --> Qdrant["Qdrant Retrieval"]
  HermesSearch --> Policy["Policy / Risk Context"]
  OpenCode --> LiteLLM["LiteLLM"]
  LiteLLM --> Models["Lanstyle Modelle"]
  OpenCode --> MCP["Remote MCP / Controlled Execution"]

Variantenbewertung

Variante Nutzen Risiken Bewertung
OpenCode -> Hermes -> LiteLLM zentraler Kontext, einheitliche Memory-/Policy-Schicht mehr Latenz, mehr Token, Gateway wird kritischer Pfad nicht als Default
OpenCode -> LiteLLM direkt plus Hermes Tool schnell, stabil, Kontext nur bei Bedarf Modell/User muss Kontextabruf ausloesen bester kurzfristiger Pfad
Hybrid Routing Fast Ops bleibt schnell, Change/Incident bekommt Kontext braucht klare Modusregeln und Tokenbudget Zielarchitektur

Aktueller Live-Fokus

OpenCode darf bei Operations-Fragen nicht nur "irgendeinen Treffer" nutzen. Der naechste Reifegrad entsteht durch:

  • Kundenscope vor Retrieval-Antwort erzwingen
  • unklare Kundenfragen blockieren oder nachfragen
  • MCP-Toolausgaben kompakt halten
  • Rohdaten nur fuer Debug/Engineering zeigen
  • Quellen mit source_tool, observed_at, confirmed, interpreted, uncertain kennzeichnen
  • lanstyle/ai als Router erklaeren, nicht als einzelnes Rohmodell behandeln

Pflichttests:

Test Erwartung
OpenCode MCP Tool Listing lanstyle_mcphub sichtbar und Tools aufrufbar
NetBox read-only Tool liefert kompakte Operator Summary
TecMed Proxmox Frage keine Lanstyle-Daten verwenden
UDM ohne Kunde Scope-Rueckfrage
Kunde ohne Obsidian-Daten keine Erfindung, klarer Hinweis
Weather/Live-Daten nur antworten, wenn Tool/Quelle vorhanden ist

Ops-Modi v1

Modus Zweck Modell Kontext Retrieval Governance
Fast Ops schnelle Fragen, Status, read-only Checks lanstyle/fast minimal keines oder nur gezieltes Tool read-only, kurze Antwort
Infrastructure Review Architektur, Netzwerk, Firewall, Intune, M365 lanstyle/architect oder lanstyle/agent-stable Projekt + Policy Obsidian, Qdrant, Runbooks keine Writes, Review-only
Change Review Changeplan, Risiko, Rollback, Blast Radius lanstyle/architect Controlled Execution, Locks, State/Drift Obsidian, Qdrant, Change History approval-preview, execute blockiert
Incident Mode Analyse, Timeline, Ursache, Safe Mode lanstyle/agent-stable mit Eskalation zu architect Health, Drift, Logsummaries, Scheduled Workflows Runbooks, Known Issues no auto-remediation
Documentation Mode Obsidian, MkDocs, Runbooks, Lessons Learned lanstyle/agent-stable oder lanstyle/fast Doku-Kontext Obsidian + MkDocs/Qdrant keine Secrets, historische Marker
Automation Design Workflows, MCP, Governance, Golden Paths lanstyle/architect Policy, Tool Catalog, Runbooks Obsidian, Qdrant, MCP Registry plan/preflight only

Hermes Memory Reifegrad

Ziel-Faehigkeit Aktueller Stand Gap
Session Memory Nous Hermes Core vorbereitet produktive Session-Zusammenfassung und OpenCode-Anbindung fehlen
Long-Term Memory Obsidian/Qdrant strategisch vorgesehen Konsolidierungsjob und Review-Queue fehlen
Team Memory konzeptionell beschrieben Rollen, Ownership und Teamprofile fehlen produktiv
Infrastructure Memory MkDocs/Obsidian/Qdrant als Quellen Live-Drift und Change History muessen staerker verknuepft werden
Decision Memory Changeplan-/Audit-Artefakte vorhanden Entscheidungssuche und Wichtigkeitsbewertung fehlen
Semantic Retrieval Qdrant vorbereitet Reindex und Retrieval Validation brauchen serverseitige Secrets/Timer
Importance Scoring noch nicht aktiv Scoring-Regeln und Review-Prozess fehlen
Expiration/Retention Governance beschrieben technische Loesch-/Archivregeln fehlen

Reifegrad: vorbereitet, aber noch nicht vollstaendig agentisch. Hermes ist als Central Brain architektonisch richtig platziert, braucht aber serverseitige Memory-Jobs, Retrieval-Validierung und klare Review-Regeln, bevor OpenCode standardmaessig darauf vertraut.

Obsidian Governance v1

Obsidian sollte die zentrale kuratierte Knowledge Source fuer menschlich gepflegtes Wissen werden. Qdrant ist der semantische Index, Hermes Native Memory ist der persoenliche/agentische Kontext, MkDocs bleibt die publizierte Betriebsdokumentation, Vaultwarden bleibt ausschliesslich Secret Source of Truth.

Inhalt Obsidian Qdrant Hermes Memory MkDocs Vaultwarden
Architekturentscheidungen ja Index Zusammenfassung ja nein
Runbooks ja Index referenziert ja nein
Change-Historie ja Index wichtige Lessons ja nein
Session-Zusammenfassungen optional Review Index nach Freigabe ja nein nein
Infrastruktur-Fakten ja, kuratiert Index referenziert ja nein
Benutzer-/Teamprofile begrenzt nein oder streng ja nein nein
Secrets, Tokens, Keys nein nein nein nein ja

Frontmatter-Standard

---
title: "<Titel>"
owner: "<team-or-person>"
source: "confirmed|interpreted|imported"
status: "active|draft|historical|rollback-only|audit-context"
systems: []
tags: []
last_verified_at: "YYYY-MM-DD"
review_after: "YYYY-MM-DD"
confidence: "high|medium|low"
secret_free: true
---

Regeln:

  • Keine Secretwerte in Obsidian.
  • Jede Betriebsnotiz bekommt source, status, last_verified_at und confidence.
  • Historische Inhalte werden markiert, nicht geloescht.
  • Qdrant indiziert nur freigegebene oder klar als historisch markierte Inhalte.
  • Hermes darf Obsidian-Kontext nutzen, aber daraus keine Infrastrukturwrites ableiten.
  • Reindex laeuft serverseitig, nicht vom Entwickler-Laptop.

OpenWebUI Modelllistenanalyse

Confirmed:

  • Die aktuelle Dokumentation nennt als Ziel fuer normale Benutzer nur lanstyle/fast, lanstyle/agent-stable und lanstyle/architect.
  • Gleichzeitig dokumentiert die bekannte OpenWebUI-Sicht noch rohe Modelle wie qwen* sowie experimentelle Lanstyle-Aliase.
  • Es wurde in dieser Phase keine Live-Aenderung an OpenWebUI, LiteLLM Keys oder Userrollen vorgenommen.

Interpreted:

  • Wahrscheinlich sehen normale Benutzer rohe Modelle, weil OpenWebUI entweder mit einem zu breiten LiteLLM-Key arbeitet, alte Modelldaten cached oder Admin-/Normaluser-Sichten noch nicht getrennt validiert sind.
  • Eine direkte Provider-Verbindung oder ein zu breiter Virtual Key waere die naheliegendste Ursache.

Uncertain:

  • Ob ein konkreter normaler Benutzer aktuell exakt dieselbe Modellliste sieht wie ein Admin, muss mit einem Testuser live verifiziert werden.
  • Ob OpenWebUI Cache oder Key-Scope die Hauptursache ist, ist ohne Session-/Key-Vergleich noch nicht abschliessend bestaetigt.

Token Pressure Report

qwen3-coder-next erreicht bei OpenCode-lastigen Sessions regelmaessig finish=length, wenn grosse Toolantworten, lange Runbooks, historische Doku und ausfuehrliche Operator-Artefakte in denselben Kontext geraten.

Ursachen:

  • OpenCode-Kontext enthaelt viel Projekt- und Sitzungsverlauf.
  • MCP Tools liefern teilweise strukturierte JSON-Antworten mit Rohdaten.
  • Changeplan-, Timeline- und Risk-Objekte sind fuer Maschinen gut, fuer Modellkontext aber schwer.
  • Retrieval kann zu viele oder zu grosse Chunks liefern.
  • Lange deutsche Infrastrukturprompts enthalten viele harte Constraints.
  • max_output_tokens schuetzt nicht vor zu grossem Eingabekontext.
  • Historische Doku ohne klare Marker kann als aktive Wahrheit mitgeladen werden.

Gegenmassnahmen:

  • Standardantworten zuerst als Operator Summary, Rohdaten nur auf Nachfrage.
  • MCP Responses mit summary, confirmed, interpreted, uncertain, next_action und kompakten references.
  • Retrieval Top-K klein halten und Chunks deduplizieren.
  • Historische Inhalte mit HISTORICAL, ROLLBACK ONLY und AUDIT CONTEXT markieren.
  • Fast Ops ohne Retrieval starten.
  • Change Review und Incident Mode bewusst in Phasen teilen.
  • Fuer lange Architektur- und Reviewarbeit lanstyle/architect verwenden.

Secret Automation Blueprint

Reindex, Memory Jobs, Retrieval Tests und Validierungen scheitern wiederkehrend, wenn sie aus lokalen Entwickler-Sessions gestartet werden. Das ist nicht der richtige Betriebsort fuer produktive Secrets.

Entwickler-Laptop:

  • nur eigene OpenCode User Tokens
  • keine produktiven Runtime-Secrets
  • keine Qdrant Reindex Jobs
  • keine dauerhaften Admin-/Master Keys

Server:

  • Vaultwarden bleibt Source of Truth
  • root-only Runtime Env-Dateien
  • systemd Services/Timer fuer Reindex, Retrieval Validation und Memory Jobs
  • Logs zeigen nur SET/MISSING, Fingerprints und Status
  • keine Secretwerte in Tooltraces

Empfohlene Automatisierungen:

Job Ort Zweck
lanstyle-obsidian-reindex Agent Runtime Obsidian/MkDocs nach Qdrant indizieren
lanstyle-hermes-retrieval-validation Hermes oder Agent Runtime Retrieval-Qualitaet pruefen
lanstyle-memory-consolidation-preview Hermes Memory-Vorschlaege erzeugen, nicht automatisch speichern
lanstyle-secret-readiness-check Agent Runtime Secret-Status ohne Werte pruefen
lanstyle-openwebui-model-visibility-check kontrollierter E2E Runner User/Admin-Modelllisten vergleichen

Dokumentationskonsolidierung

Aktive Zielseiten:

Historisch zu behandeln:

  • Aeltere Agent-Roadmaps, die OpenCode primaer als Coding-Agent beschreiben.
  • VLAN70-/Legacy-/Canary-Berichte, die bewusst als Audit-Kontext erhalten bleiben.
  • Alte Modellrouting-Abschnitte mit nicht mehr produktiven Raw-Model-Empfehlungen.

Marker:

  • HISTORICAL: nicht mehr aktive Zielarchitektur.
  • ROLLBACK ONLY: nur fuer Rueckfallpfade, nicht als Standard.
  • AUDIT CONTEXT: Beleg fuer fruehere Entscheidung oder Migration.

Empfehlungen

  1. OpenCode kurzfristig als Hybrid-Konsole betreiben: LiteLLM direkt, Hermes als explizites Kontexttool.
  2. Ops-Modi in Operator-Doku und Promptvorlagen sichtbar machen.
  3. OpenWebUI Modelllisten mit Testuser gegen Admin verifizieren, danach normale User auf Lanstyle-Aliase begrenzen.
  4. Reindex und Retrieval Validation serverseitig automatisieren.
  5. Historische Doku markieren, nicht loeschen.
  6. Token-Druck durch kompakte Toolantworten und begrenztes Retrieval reduzieren.
  7. Hermes Memory erst nach Review-/Retention-Regeln produktiv fuer OpenCode als Default-Kontext nutzen.