LLMGui Control Center

Das LLMGui Control Center ist eine GTK3-Desktop-Applikation (llmgui-control.py) für Linux, die eine grafische Oberfläche für alle wesentlichen LLMGui-Funktionen bereitstellt. Es ist das primäre Interface für Modellverwaltung, Live-Chat, Benchmark-Läufe und Ergebnisauswertung.

Navigation

• LLMGui Übersicht
• VS Code Extension
• MCP Server & Client
• Security Commands
• Recent Changes

Starten

# Direkt
python3 llmgui-control.py

# Mit Abhängigkeiten
sudo apt install python3-gi gir1.2-gtk-3.0 gir1.2-webkit2-4.1
python3 llmgui-control.py

Voraussetzung: Laufender LLMGui-Server und Ollama-Instanz.

Interface-Übersicht

Das Control Center ist in mehrere Tabs unterteilt:

Tab: Modelle

Zeigt alle via Ollama verfügbaren Modelle mit detaillierten Metadaten:

Benchmark-Hints (Spalte "Benchmark"):

Tooltip zeigt Datum des letzten Runs. Hints werden aus allen benchmark_results_*.json und planning_results_*.json in benchmark/ gelesen.

Aktionen:
- Modell aktivieren / als Standard setzen
- Modell aus Ollama entfernen
- GPU-VRAM-Status via SSH-Abfrage (nvidia-smi) für Remote-Server wie dana

Tab: Chat

Vollwertiger Chat-Client direkt im Control Center:

• Streaming-Ausgabe mit Token-by-Token-Darstellung
• Slash Commands nutzbar
• Workspace-Pfad konfigurierbar
• Modell-Wechsel ohne Server-Neustart

Tab: Security

Der Security-Tab verwandelt LLMGui in ein vollwertiges Security Operations Center (SOC). Er besteht aus zwei Sub-Tabs: Findings und Trend & Vergleich.

Sub-Tab: Findings

Scan-Toolbar (oben, zwischen Stats-Cards und Findings-Tabelle):

Die Stats-Cards oben zeigen in Echtzeit: Total Findings · Critical · High · Offene / Behobene.

Die Findings-Tabelle (sortierbar nach allen Spalten) zeigt:

Aktionen auf ausgewähltem Finding:
- Fix with AI — /sec-fix <id>: LLM generiert und wendet Patch an
- Verify Fix — /sec-verify <id>: Re-Exploit in Docker-Sandbox (nur wenn Status = fixed)

Live-Scan-Ergebnisse (noch nicht in DB) haben DB_ID = -1 → Fix-Button aktiv, Verify deaktiviert.

Health Grade (A–F): Basiert auf Anzahl offener Critical/High-Findings und FIM-Events. Wird vom LLM als CISO-Bewertung berechnet.

AI-FIM Judge: Intelligente Analyse von Dateisystem-Änderungen via /sec-monitor. Die KI unterscheidet zwischen Entwickler-Edits und potenziell schädlichem Tampering.

Sub-Tab: Trend & Vergleich

Visualisiert die Sicherheitslage über die Zeit via GET /api/security/trend:

Der Trend-Tab wird nach jedem Live-Scan automatisch aktualisiert.

Tab: Tools & Konfiguration

Übersicht aller installierten Security- und Analyse-Tools:

Aktions-Buttons:
- PYZ-Tools (bandit/safety/pip-audit/flake8/ruff/mypy/radon/pylint/vulture): Build .pyz → führt ./build_sec_tools.sh TOOLNAME aus
- System-Tools (semgrep/npm/shiv/ollama/git): Installieren → jeweiligen install-Command
- Status aktualisieren — aktualisiert alle Einträge
- Alle Sec-Tools bauen — baut alle .pyz-Bundles auf einmal
- System-Install (pip) — installiert alle Sec-Tools via pip

Tab: Planning Benchmark

Der umfangreichste Teil des Control Centers — ein vollautomatischer Benchmark-Runner, der Modelle an einer realen, ausführbaren Coding-Aufgabe misst.

Planning Benchmark — Detail

Aufgabe

Jedes Modell bekommt denselben Prompt und soll ein lauffähiges Python-Skript generieren, das:

1. Eine HTML-Indexseite scrapt und den Link zu vex.tar.zst findet
2. Das Archiv herunterlädt
3. Den SHA256-Hash gegen eine .sha256-Datei verifiziert
4. Das Zstandard-komprimierte Tar-Archiv entpackt (mode="r|")
5. Die größte Datei (Bytes) und Datei mit meisten Zeilen ermittelt und ausgibt
6. Eine requirements.txt schreibt
7. venv-Setup-Befehle ausgibt

Das Skript wird tatsächlich ausgeführt — mit bis zu 5 Korrekturversuchen bei Fehlern. Die Ausgabe wird automatisch gegen eine Referenzlösung (Ground Truth) verglichen.

Ablauf

1. setup_exec_env()         — exec_venv mit Paketen vorbereiten
2. start_fixture_server()   — lokaler HTTP-Server für Testdaten
3. establish_ground_truth() — Referenzlösung ausführen
4. Pro Modell (max 5 Versuche):
   a. LLM generiert test2.py
   b. Skript ausführen
   c. Bei Fehler: Fehlermeldung → LLM → Korrektur → Retry
   d. Bei Erfolg: Unit-Tests + Correctness-Verifikation
5. Ergebnisse speichern (JSON)

Scoring: Ergebnis-first

Das Scoring gewichtet das korrekte Endergebnis am stärksten. Ein schöner Plan oder eleganter Code nützt nichts, wenn falsche Werte im Output stehen.

6-dim (Correctness + Unit-Tests verfügbar — voller Run):

5-dim Fallback (nur Unit-Tests, kein Correctness):

4-dim Fallback (Skript lief nie — reine Heuristik):

Wichtig: Modelle, die nie erfolgreich durchliefen, werden nur heuristisch (4-dim) bewertet. Dieser Score ist nicht direkt vergleichbar mit 6-dim-Scores von Modellen, die tatsächlich die Aufgabe gelöst haben.

Correctness-Checks

5 binäre Checks (0 oder 1), Summe / 5 × 10 = Correctness-Score:

LLM-as-Judge (optional)

Zusätzlich kann ein Judge-Modell (z.B. qwen2.5-coder:14b) den generierten Code qualitativ bewerten. Der Judge bewertet 4 Dimensionen (je 1–10):

• Correctness (laut Judge-Einschätzung)
• Completeness (alle Aufgaben abgedeckt?)
• Code Quality (Struktur, Lesbarkeit)
• Robustness (Fehlerbehandlung)

Der judge_total ist der Durchschnitt der 4 Werte. Der Judge-Score fließt nicht in den total_score ein — er dient als unabhängige Qualitätsperspektive.

Ergebnisdarstellung

Nach einem Benchmark-Run werden die Ergebnisse automatisch gespeichert (benchmark/planning_results_YYYYMMDD_HHMMSS.json) und im Control Center visualisiert:

• Rangliste (sortiert nach total_score)
• Radar-Chart (interaktiv, Legend-Klick um Modelle ein-/auszublenden)
• Score-Verlaufsgraph (Entwicklung über mehrere Runs)
• Detaillierte Checks (TreeView mit Tooltips für jeden einzelnen Check)
• Alle Modelle – letzter Stand: Kombinierte Ansicht aus allen JSON-Ergebnisdateien (letzter Run pro Modell)

Ergebnis-JSON-Format

{
  "model": "phi4:14b",
  "planning_score": 10.0,
  "adherence_score": 8.75,
  "implementation_score": 10.0,
  "quality_score": 10.0,
  "unit_test_score": 0.0,
  "total_score": 7.08,
  "scoring_mode": "6-dim",
  "execution_passed": true,
  "execution_attempts": 1,
  "correctness_score": 8.0,
  "correctness_checks": {
    "sha256_in_output": false,
    "biggest_file_correct": true,
    "biggest_bytes_correct": true,
    "most_lines_file_correct": true,
    "most_lines_count_correct": true
  },
  "judge_total": 7.5,
  "judge_reasoning": "...",
  "response_time_s": 291.5,
  "tokens_per_second": 5.57,
  "timestamp": "2026-03-01T09:23:32"
}

VRAM-Monitoring

Das Control Center kann den GPU-VRAM eines Remote-Ollama-Servers (z.B. dana) via SSH/nvidia-smi abfragen:

• Automatische Erkennung geladener Modelle
• VRAM-Gesamtkapazität und -Auslastung
• Anzeige in der Modell-Liste und im VS Code Status Bar

Technische Details