⬡

CB Hub Admin

Bitte mit Admin-Secret anmelden

–
Calls gesamt
–
Input Tokens
–
Output Tokens
–
Kosten (USD)
–
Avg Dauer (ms)
🔑 Provider API Keys 0
Provider Label API Key Status Erstellt Aktionen
🔑

Lade…
📊 Usage nach Provider
Provider Calls Input Tokens Output Tokens

Keine Daten
💰 Modell-Preise ($/1M Tokens)
Provider Model Input Output Status

Lade…
🔍 Model Discovery –
🔍

Klicke "Discover" um verfügbare Modelle bei allen Providern abzufragen

🗓 Letzte Calls
User Provider Model In/Out Kosten Dauer Status Zeitpunkt

Keine Calls
🏥 Model Health 0
Modell Provider Status Failures Nächster Re-Check Letzter Fehler Aktionen
✅

Alle Modelle gesund
–
Gesamtguthaben (USD)
–
Wallets
–
Total Verbraucht (USD)
💰 Alle Wallets
User Status Guthaben Aufgeladen Verbraucht LLM Calls Aktionen

Lade...

Clide & CB Hub — Technische Dokumentation

Stand: 26. März 2026 — Diese Seite dokumentiert alle Systeme:
Strang 5 (Install & Setup), Strang 6 (Updates & Migrationen) und Strang 6b (Marketplace).

📦 1. Install Script install.sh
Strang 5

Zweck: Ein neuer User kopiert eine einzige Zeile ins Terminal. Das Script erledigt alles — still, ohne Fragen.

curl -fsSL https://api.cblight.de/install.sh | bash

Was das Script tut:

  1. Prüft Voraussetzungen: macOS, Node.js ≥20 (installiert via nvm falls nötig)
  2. Erstellt Installationsverzeichnis ~/cb_light
  3. Lädt den neuesten Tarball vom Hub (GET /api/releases/latest/download)
  4. Entpackt, führt npm install und npx tsc aus
  5. Schreibt eine leere config.yaml (Setup-Marker)
  6. Startet CB Light und öffnet den Browser: http://localhost:3577/setup

Wo liegt das Script? cb_hub/public/install.sh — wird vom Hub unter /install.sh ausgeliefert.

🧙 2. Setup Wizard setup.html
Strang 5

Zweck: Browser-basierter Setup nach der Installation. Null Terminal-Eingaben nötig.

Flow:

1. Invite-Code → 2. Name & Email → 3. Agent-Setup → 4. Fertig! 🎉

Hub-API Calls:

  • GET /api/invite/:code — Validiert den Invite-Code
  • POST /api/accept — Erstellt Account, bekommt Secret zurück

Was passiert auf CB Light:

  • config.yaml wird geschrieben (hub.url, hub.secret, owner.*)
  • Erstes Agent-Profil wird in profiles/ angelegt
  • Redirect zum echten Clide UI

Dateien: cb_light/src/gateway/setup.html, Routes in web.ts: /setup, /api/setup/check, /api/setup/complete

🚀 3. Release-System GitHub Actions → Hub
Strang 5

Zweck: Bei jedem Git-Tag wird automatisch ein Tarball gebaut und zum Hub hochgeladen.

Flow:

git tag v0.29.0 && git push --tags
└→ GitHub Actions: release.yml
└→ Tarball bauen (ohne .git, profiles, node_modules)
└→ POST /api/releases/upload → Hub speichert

Hub-Endpoints:

  • POST /api/releases/upload — CI/CD lädt Tarball hoch (Basic Auth)
  • GET /api/releases/latest — Aktuelle Version + SHA256
  • GET /api/releases/latest/download — Tarball-Download (für Install & Updates)

Dateien: cb_light/.github/workflows/release.yml, cb_hub/src/routes/api.ts

🔄 4. Update-System update.ts
Strang 6

Zweck: End-User können Updates über die UI installieren, ohne Git oder Terminal.

Update-Flow (Tarball-basiert):

1. Version-Check: GET /api/releases/latest
2. Backup → BackupService.backup("pre-update")
3. Code-Snapshot → backups/pre-update-code/
4. Download Tarball (Bearer secret)
5. SHA256 verifizieren ✓
6. Entpacken → Dateien kopieren (PROTECTED dirs)
7. npm install (falls package.json geändert)
8. npx tsc (TypeScript rebuild)
9. Migrationen ausführen
10. ✅ "Bitte Clide neustarten"

PROTECTED Directories (werden nie überschrieben):

profiles/ data/ logs/ sessions/ backups/ config.yaml node_modules/ .env

UI: Update-Banner erscheint automatisch alle 5 Minuten oben im UI wenn ein Update verfügbar ist. Update-Panel unter Admin → Software Update.

Dual-Mode: Hub-Tarball für End-User, Git-Checkout für Developer.

API: GET /api/update/status, POST /api/update/check, POST /api/update/apply, POST /api/update/rollback

⏪ 5. Rollback-Mechanismus
Strang 6

Automatisch: Wenn npm install oder npx tsc fehlschlagen, wird der Code-Snapshot automatisch wiederhergestellt.

Manuell: Rollback-Button im Update-Panel oder POST /api/update/rollback.

Wie es funktioniert:

  • Vor jedem Update: alle Code-Dateien werden nach backups/pre-update-code/ kopiert
  • Bei Fehler: Snapshot zurückkopieren + npx tsc rebuild
  • User-Daten (PROTECTED dirs) werden nie berührt
🔀 6. Daten-Migrationen migrations.ts
Strang 6

Zweck: Bei Breaking Changes an config.yaml oder Datenstrukturen werden automatisch Migrationen ausgeführt.

Mechanismus (A+B Ansatz):

  • A — Nummerierte Scripts: Jede Migration hat eine Version (001, 002, ...) und eine up() Funktion
  • B — Version-Tracking: _data_version Feld in config.yaml merkt sich die aktuelle Version

Wann laufen Migrationen?

  • Nach jedem Update (automatisch)
  • Beim Server-Start (falls extern aktualisiert)
  • Vor jeder Migration: Auto-Backup von config.yaml nach backups/migrations/

UI: Migration-Status im Update-Panel: aktuelle Daten-Version + ausstehende Migrationen.

API: GET /api/update/migrations

🏪 7. Marketplace marketplace.ts
Strang 6b

Zweck: Zentraler Katalog für Extensions, Skills und Tools. Admins publizieren Packages auf dem Hub, CB Light Instanzen können diese durchsuchen und installieren.

Datenmodell (PostgreSQL):

  • marketplace_packages — Metadaten (slug, type, name, icon, author, tags, featured, published)
  • marketplace_versions — Versionen (version, changelog, min_core, size_bytes, sha256, downloads)
  • marketplace_downloads — Download-Log (wer, wann, welche Version)

Dateispeicher:

/data/packages/{type}/{slug}/{version}.tar.gz

Publish-Flow (Desktop App Publisher):

Desktop App verpackt src/ + ui/ + manifest.json in .tar.gz
└→ POST /api/marketplace/publish (multipart/form-data: manifest, message, artifact)
└→ Hub parse JSON aus manifest Field, speichert Metadaten in DB + Tarball auf Filesystem

Install-Flow (CB Light Instanz):

1. GET /api/marketplace — Liste anzeigen (durch Hub-Proxy)
2. POST /api/marketplace/install — User klickt "Installieren"
3. Download Tarball vom Hub → entpacken nach extensions/{slug}/
4. ✅ Server-Neustart für Aktivierung

Admin-Kuratierung (Hub Dashboard → Marketplace Tab):

  • ⭐ Featured an/aus — hervorgehobene Packages
  • 👁️/🚫 Öffentlich/Versteckt — Package für CB Light Instanzen sichtbar/unsichtbar
  • ✏️ Edit — Beschreibung, Tags, Icon, Homepage bearbeiten
  • 🗑️ Delete — Version + Datei vom Server entfernen

Dateien: cb_hub/src/routes/marketplace.ts, cb_hub/db/migrate_004_marketplace.sql, cb_light/src/gateway/web.ts (Proxy + Install), cb_light/src/gateway/ui/panels/all-panels.html (UI)

🔌 API-Übersicht — alle neuen Endpoints
Methode Endpoint Projekt Beschreibung
GET /install.sh Hub Install-Script ausliefern
GET /api/releases/latest Hub Aktuelle Version + SHA256
GET /api/releases/latest/download Hub Tarball herunterladen
POST /api/releases/upload Hub Tarball hochladen (CI/CD)
GET /api/invite/:code Hub Invite-Code validieren
POST /api/accept Hub Account erstellen (Invite)
POST /api/machines/register Hub Zweitinstallation Token einlösen
GET /setup Light Setup-Wizard servieren
GET /api/setup/check Light Setup nötig? (config.yaml prüfen)
POST /api/setup/complete Light Setup abschließen
GET /api/update/status Light Update-Status abfragen
POST /api/update/check Light Auf Updates prüfen
POST /api/update/apply Light Update installieren
POST /api/update/rollback Light Rollback durchführen
GET /api/update/migrations Light Migration-Status
GET /api/marketplace Hub Packages auflisten — Auth erforderlich (?type=, ?search=, ?admin=true)
GET /api/marketplace/extensions Hub Nur Extensions auflisten (Alias für ?type=extension)
GET /api/marketplace/:slug Hub Package-Details + alle Versionen
GET /api/marketplace/:slug/:ver/download Hub Tarball herunterladen (Bearer Auth)
POST /api/marketplace/publish Hub Package veröffentlichen (Deploy Secret, multipart/form-data)
PUT /api/marketplace/:slug Hub Metadaten aktualisieren (Admin)
DEL /api/marketplace/:slug/:ver Hub Version löschen (Admin)
GET /api/marketplace Light Proxy → Hub (+ lokale Install-Status)
POST /api/marketplace/install Light Package herunterladen + installieren
📂 Datei-Übersicht — was wo liegt
CB Hub
├ public/install.sh — Install-Script
├ public/index.html — Dashboard (diese Seite)
├ src/routes/api.ts — Release & Invite Endpoints
├ db/init.sql — releases Table
├ src/routes/marketplace.ts — Marketplace API (list, publish, download, admin)
└ db/migrate_004_marketplace.sql — Marketplace DB Schema (3 Tabellen)
CB Light
├ src/update.ts — UpdateService (Hub + Git, Rollback)
├ src/migrations.ts — MigrationRunner
├ src/gateway/setup.html — Setup Wizard UI
├ src/gateway/web.ts — Routes (setup, update, rollback, migrations)
├ .github/workflows/release.yml — CI/CD für Tarball-Upload
└ src/gateway/ui/ — Update-Banner, Rollback-Button, Migration-Status

👋 User-Onboarding — Schritt für Schritt

So bringst du einen neuen User von Null auf eine laufende CB Light Instanz.
Alle Schritte werden hier im Hub-Dashboard durchgeführt.

1 User anlegen

Gehe zu 🔑 User-Verwaltung → ＋ Neuer User

  • Username — eindeutiger Handle (z.B. johndoe)
  • Name — Anzeigename
  • E-Mail — Kontakt-Adresse

→ System erzeugt automatisch einen 64-Zeichen Secret Key

2 Secret Key notieren

In der User-Tabelle: Klick auf den Secret Token um ihn anzuzeigen, dann 📋 zum Kopieren.

⚠️ Der Key wird dem User für die Setup-Konfiguration benötigt. Sicher aufbewahren!
3 Wallet aufladen

Gehe zu 💰 Wallets → 💳 Button beim neuen User → Betrag eingeben.

Ohne Guthaben kann der User keine LLM-Calls machen (402 Payment Required).

4 Einladung erstellen

Gehe zu 🔑 User-Verwaltung → 📨 Einladungen → ＋ Neue Einladung

E-Mail eingeben → System erzeugt einen Invite-Code (einmalig, zeitlich begrenzt).

Im Ergebnis-Dialog: 📋 Befehl kopieren — enthält den kompletten Install-Befehl mit Code.

5 Dem User mitteilen

Sende dem neuen User zwei Dinge:

INSTALL CLIDE_INVITE_CODE=<code> curl -fsSL https://api.cblight.de/install.sh | bash
SECRET Der 64-Zeichen Secret Key aus Schritt 2

Tipp: Am besten über einen sicheren Kanal (Signal, persönlich, etc.)

✓ User installiert & verbindet

Der User führt den Install-Befehl aus. Das Script:

  1. Prüft Voraussetzungen (macOS, Node.js ≥ 20)
  2. Lädt CB Light vom Hub herunter (Invite-Code = Download-Auth)
  3. Installiert und startet CB Light
  4. Öffnet den Setup-Wizard im Browser (localhost:3577/setup)

Im Setup-Wizard gibt der User ein:

  • Hub-URL: https://api.cblight.de
  • Secret Key: den 64-Zeichen Key aus Schritt 2

→ CB Light verbindet sich zum Hub, Heartbeat startet, User erscheint als ● Online

🔁 Ablauf-Diagramm
Admin: User anlegen ──→ Secret Key erzeugt │ Admin: Wallet aufladen ──→ Guthaben $50+ │ Admin: Invite erstellen ──→ Invite-Code erzeugt │ Admin ──→ sendet Install-Befehl + Secret an User │ User: curl ... | bash ──→ CB Light installiert │ User: Setup-Wizard ──→ Hub-URL + Secret eingeben │ ✅ Verbunden ──→ LLM-Calls möglich

✅ Quick-Check — Ist alles bereit?

☐ User in User-Verwaltung angelegt?
☐ Secret Key kopiert und sicher aufbewahrt?
☐ Wallet mit Guthaben aufgeladen?
☐ Einladung erstellt und Install-Befehl kopiert?
☐ Mindestens ein LLM Provider Key aktiv (⚡ LLM Proxy)?
☐ Install-Befehl + Secret Key an User gesendet?
–
RELEASES GESAMT
–
AKTUELLE VERSION
–
GESAMTGRÖSSE
🚀 Installation (neue User)

Invite-Code vorher unter User-Verwaltung → Invite erzeugen, dann dem User diesen Befehl geben:

CLIDE_INVITE_CODE=<code> curl -fsSL https://api.cblight.de/install.sh | bash

Ohne Invite-Code wird der Download verweigert (401). Der Code wird einmalig für den Download benötigt.

Ausblick: Desktop App Wrapper
Option 3 (Demnächst): Echte Desktop-App (Tauri/Electron). Die E-Mail an den User enthält dann einen Deep-Link (cblight://invite?code=HASH). Die Installation erfolgt per 1-Klick komplett nativ ohne Setup-Skripte oder Terminal.
📦 Alle Releases
VERSION DATUM GRÖSSE CHANGELOG SHA256 AKTION
—
Postfächer gesamt
—
Aktiv
—
Ungelesene Mails
—
Owner mit Postfach
📬 Registrierte Agenten-Postfächer
Agent E-Mail-Adresse Owner Status Ungelesen Zuletzt aktiv Registriert

Lade...
📖 Konvention & API-Referenz

E-Mail-Adresse Schema:

{agentslug}.{ownerusername}@cblight.de

Beispiel: klara.heiko@cblight.de

Slug-Regeln: lowercase a–z, 0–9, Bindestrich, max 20 Zeichen, kein Punkt.

CB Light API-Aufrufe:

PUT /api/agents/register — Postfach anlegen / aktualisieren
GET /api/agents — Eigene Postfächer auflisten
GET /api/agents/:slug/inbox — Neue Mails abholen
GET /api/admin/agents — Admin: alle Postfächer

Bug Reports

Zentrale Error-Reporter Ticket-Ansicht

🆕 Inbox 0

⏳ In Progress 0

✅ Resolved 0

—
Workspaces gesamt
—
Dateien gesamt
—
Owner mit Workspaces
🌐 Hub Workspaces
Workspace Owner Team Dateien Erstellt Aktionen

Lade...

🏗 System-Infrastruktur — Vollständige Dokumentation

Alles was ein Entwickler oder Administrator wissen muss, um das CB Hub + CB Light Ökosystem
zu verstehen, zu betreiben, zu warten und weiterzuentwickeln. Stand: 27. März 2026.

🌐 1. System-Architektur

Das System besteht aus zwei Komponenten:

CB Hub Zentraler Server — API-Gateway, User-Management, LLM-Proxy, Token-Bank (Wallets), Marketplace (Package-Katalog + Downloads)
CB Light (Clide) Lokale Instanzen — laufen auf den Rechnern der User, verbinden sich zum Hub
┌─────────────────────────────────────────────────────────┐ │ CB Hub (Hetzner) │ │ ┌─────────┐ ┌──────────────┐ ┌───────────────────┐ │ │ │ Caddy │→│ Express API │→│ PostgreSQL 16 │ │ │ │ (HTTPS) │ │ (Node 22) │ │ (Docker Alpine) │ │ │ └─────────┘ └──────────────┘ └───────────────────┘ │ │ ↕ ↕ │ │ Port 443 Port 4400 │ └─────────────────────────────────────────────────────────┘ ↕ ↕ ┌─────────┐ ┌─────────┐ │CB Light │ │CB Light │ (User-Instanzen) │ User A │ │ User B │ └─────────┘ └─────────┘

Kommunikation: CB Light → Hub via HTTPS (api.cblight.de). Auth: Bearer Token (Owner Secret).

LLM-Proxy-Flow: CB Light → Hub → Anthropic/OpenAI/Google → Hub → CB Light (SSE Streaming)

📂 2. Quellcode-Repositories
Repo URL Beschreibung
cb_hub github.com/AtariCoder76/cb_hub Hub-Server: API, Dashboard GUI, DB-Schema, Dockerfile, Deploy-Workflow
cb_light github.com/AtariCoder76/cb_light CB Light: Lokaler AI-Agent, Gateway UI, Toolchains

Hub-Struktur:

cb_hub/
├── src/
│ ├── index.ts  # Express Server, CORS, Rate Limiting
│ ├── auth.ts  # authMiddleware + adminMiddleware
│ ├── db.ts  # PostgreSQL Connection Pool
│ └── routes/
│ ├── api.ts  # Admin, Users, Invites, Wallets, Releases
│ ├── llm.ts  # LLM Proxy, Provider Keys, Usage Stats, Model Discovery
│ └── marketplace.ts  # Extension/Skill/Tool Marketplace
├── public/
│ ├── index.html  # Dashboard GUI (Single-Page)
│ └── install.sh  # CB Light Install Script
├── db/
│ ├── init.sql  # Schema: owners, wallets, ledger, ...
│ └── migrate_*.sql  # Migrationen
├── docker-compose.yml  # Lokal: Postgres + Adminer
├── Dockerfile  # Multi-stage: Build + Runtime
└── .github/workflows/
    └── deploy.yml  # CI/CD → Hetzner
🖥 3. Server-Infrastruktur
Provider Hetzner Cloud
IP 178.104.0.225
OS Ubuntu 24.04 LTS
Docker v29.3.0 + Compose v5.1.0
Domain api.cblight.de
TLS Automatisch via Caddy (Let's Encrypt)
SSH ssh root@178.104.0.225

Docker-Container:

Container Image Port Funktion
cb-hub-caddy caddy:2-alpine 80, 443 Reverse Proxy, TLS
cb-hub-app node:22-alpine (custom) 4400 (intern) Express API + GUI
cb-hub-postgres postgres:16-alpine 5433 (intern) Datenbank

Verzeichnisse auf dem Server:

/opt/cb-hub/
├── app/  # Git-Repo (cb_hub), Source Code
├── releases/  # CB Light Tarballs (*.tar.gz)
├── backups/  # Tägliche DB-Dumps
├── docker-compose.yml # Production Compose
├── Caddyfile  # HTTPS-Config
├── .env  # Secrets (POSTGRES_PASSWORD, DEPLOY_SECRET, ...)
├── backup.sh  # Backup-Script (Cron: täglich 03:00)
└── monitor.sh  # Health-Check (Cron: alle 5 Min)
🚀 4. Deployment Pipeline

Automatisch bei Push auf main:

git push → GitHub Actions → SSH auf Hetzner
→ git fetch + reset --hard origin/main
→ DB-Migrationen (migrate_*.sql)
→ docker compose up -d --build --force-recreate hub
→ Health-Check (curl /health)
→ ✅ oder ❌

Deploy-Datei: .github/workflows/deploy.yml

GitHub Secrets benötigt:

  • SERVER_IP — 178.104.0.225
  • DEPLOY_SSH_KEY — SSH Private Key für root-Zugang

Manuell deployen (Notfall):

ssh root@178.104.0.225
cd /opt/cb-hub/app && git pull
cd /opt/cb-hub && docker compose up -d --build hub
🗄 5. Datenbank-Schema
Tabelle Zweck Wichtige Felder
owners User-Accounts username, secret (SHA256), role (admin/user), status
wallets Guthaben pro User owner_id, balance (DECIMAL 12,4)
ledger Transaktions-Journal type (topup/usage/refund), amount, description
llm_usage LLM-Call-Log model, input/output_tokens, cost_usd, duration_ms
provider_keys API-Keys (Anthropic, etc.) provider, api_key, enabled
invites Einladungs-Links hash, status (pending/accepted/expired)
machines Lokale Client-Instanzen owner_id, machine_id, version, os, agent_count, last_seen
machine_tokens Zweit-Installation Tokens token, owner_id, expires_at, used
trust Trust-Beziehungen owner_a, owner_b
releases CB Light Versionen version, filename, sha256, changelog

Schema-Datei: db/init.sql

Migrationen: db/migrate_*.sql — werden beim Deploy automatisch ausgeführt

DB-Zugang (notfall):

ssh root@178.104.0.225
docker exec -it cb-hub-postgres psql -U cbhub -d cbhub
🔐 6. Authentifizierung & Sicherheit

Auth-Modell: Bearer Token (Owner Secret)

  • Jeder User bekommt bei Erstellung einen 64-Zeichen SHA256 Secret Key
  • CB Light speichert diesen in config.yaml → hub.secret
  • Alle API-Calls: Authorization: Bearer <secret>

Rollen:

admin Voller Zugriff auf Dashboard, User-Verwaltung, Wallets, Provider Keys
user Eigene Wallet abfragen, LLM-Calls machen, Heartbeat senden

Middleware-Kette:

  • authMiddleware — prüft Bearer Token, setzt req.owner
  • adminMiddleware — prüft req.owner.role === 'admin'

Dashboard-Login: Admin gibt Secret Key im Login-Overlay ein → wird in localStorage gespeichert → alle fetch()-Calls nutzen adminFetch() Wrapper der Header mitsendet.

Self-Registration: Deaktiviert. Nur Admin kann User über Dashboard anlegen.

📡 7. API-Endpoints (Vollständig)

Basis-URL: https://api.cblight.de

Method Endpoint Auth Beschreibung
GET /health — Health Check
GET /api/releases/latest — Neueste Version
GET /api/releases/download — Tarball herunterladen
POST /api/releases/upload Deploy-Secret Release hochladen (CI)
GET /api/releases/electron/latest-mac.yml — electron-updater Metadaten (YAML)
GET /api/releases/electron/:filename — Electron Update-Datei (ZIP)
User-Endpoints (Bearer Token)
POST /api/llm/chat Bearer LLM-Proxy (+ Wallet-Check)
GET /api/llm/wallet Bearer Eigene Wallet-Daten
PUT /api/heartbeat Bearer Instanz Heartbeat (OS, Version, Count)
GET /api/machines Bearer Übersicht verbundener Maschinen
POST /api/machines/tokens Bearer Token für Zweit-Installation generieren
POST /api/machines/register Token Neue Maschine verknüpfen (via Token)
GET /api/network Bearer Netzwerk-Übersicht
Admin-Endpoints (Bearer + Admin-Rolle)
GET /api/admin/dashboard Admin Dashboard-Daten (inkl. verbundener Maschinen)
POST /api/admin/users Admin User anlegen
PUT /api/admin/users/:id Admin User bearbeiten
DEL /api/admin/users/:id Admin User löschen
GET /api/admin/wallets Admin Alle Wallets
POST /api/admin/wallets/:id/topup Admin Guthaben aufladen
GET /api/llm/providers Admin Provider Keys auflisten
GET /api/llm/usage Admin LLM-Usage-Statistiken
GET /api/llm/discover Bearer Model Discovery — alle Provider-Modelle mit Tier + Pricing
GET /api/llm/discover/pricing Bearer Pricing-Lookup für ein einzelnes Model
🤖 8. LLM-Proxy — Multi-Provider Gateway

Unterstützte Provider: Anthropic ✅ | OpenAI ✅ | Google ✅

Datei: src/routes/llm.ts

📡 Request-Flow:

  1. CB Light sendet POST /api/llm/chat mit Model + Messages
  2. Hub prüft Auth (Bearer Token) + Wallet-Balance (≤ 0 → 402)
  3. Provider-Erkennung: explizites provider-Feld oder Auto-Detect aus Model-Name
  4. Hub lädt passenden API-Key aus provider_keys Tabelle
  5. Hub konvertiert Request ins Provider-Format (Tools, System-Prompt)
  6. Hub forwarded an Provider-API (Streaming oder Non-Streaming)
  7. Antwort wird 1:1 an CB Light durchgereicht (inkl. SSE)
  8. Token-Usage wird aus Response extrahiert → Kosten berechnet → Wallet belastet

📨 API-Definition — POST /api/llm/chat

{ "model": "claude-sonnet-4-20250514", "provider": "anthropic", // optional — auto-detect wenn leer "messages": [{"role":"user","content":"Hello"}], "system": "Du bist ein Assistent", "max_tokens": 4096, "tools": [...], // Anthropic-Format → wird konvertiert "stream": false, "thinking_budget": 10000 // nur Anthropic }

🧮 Kosten-Tracking:

  • Kein Provider gibt USD-Kosten zurück — nur Token-Counts
  • Kosten berechnet über MODEL_PRICING Tabelle (pro 1M Tokens)
  • Non-Streaming: Token-Counts direkt aus usage Feld der Response
  • Streaming: Anthropic: message_delta Event | OpenAI: stream_options.include_usage | Google: usageMetadata aus letztem Chunk

💰 Preistabelle ($/1M Tokens):

Provider Model Input Output
Anthropic claude-opus-4 $15.00 $75.00
Anthropic claude-opus-4.6 $5.00 $25.00
Anthropic claude-sonnet-4 $3.00 $15.00
Anthropic claude-3.5-haiku $0.80 $4.00
OpenAI gpt-5.2 $3.00 $12.00
OpenAI gpt-4o $2.50 $10.00
OpenAI gpt-4o-mini $0.15 $0.60
OpenAI gpt-4.1 $2.00 $8.00
OpenAI gpt-4.1-mini $0.40 $1.60
OpenAI gpt-4.1-nano $0.10 $0.40
OpenAI o1 / o3 / o3-mini / o4-mini $15–$1.10 $60–$4.40
Google gemini-3-flash-preview $0.10 $0.40
Google gemini-2.5-pro $1.25 $10.00
Google gemini-2.5-flash $0.15 $0.60
Google gemini-2.0-flash $0.10 $0.40

Quelle: MODEL_PRICING in llm.ts. Neue Modelle werden auch dynamisch über GET /api/llm/discover erkannt.

🔧 Provider-Detection (Auto):

  • claude-* → Anthropic
  • gpt-*, o1-*, o3-*, o4-* → OpenAI
  • gemini-* → Google
  • Default Fallback → Anthropic

🔍 Model Discovery (NEU):

  • GET /api/llm/discover — Fragt alle enabled Provider-APIs nach verfügbaren Modellen ab
  • Ergebnisse werden mit Tier-Heuristik klassifiziert: ⭐ Premium, 🔵 Standard, ⚡ Fast
  • Pricing aus MODEL_PRICING + Prefix-Matching
  • 1h Cache-TTL → erste Request pro Stunde fragt die APIs
  • Erreichbar über LLM Proxy Tab → 🔍 Discover Button
  • Identisch zu CB Light's ModelRegistry — synchrones API-Format

🔒 Filter- und Exclusion-Regeln:

  • Embedding-, TTS-, Whisper-, DALL-E-Modelle werden automatisch gefiltert
  • Fine-tuned Modelle (ft:), ältere Modelle (gpt-3.*, davinci) ebenfalls
  • Google: Nur gemini-* Modelle werden eingeschlossen
📦 9. CB Light Release-Flow
1. Push Tag auf cb_light: git tag v0.28.0 && git push --tags
2. GitHub Action (.github/workflows/release.yml):
   - npm ci && npx tsc
   - tar czf cb_light-0.28.0.tar.gz ...
   - curl -X POST api.cblight.de/api/releases/upload \
       -H "X-Deploy-Secret: $SECRET" \
       -H "X-Version: 0.28.0" \
       --data-binary @cb_light-0.28.0.tar.gz
3. Hub speichert Tarball in /opt/cb-hub/releases/
4. CB Light User: Update-Check → Download → Entpacken → Neustart

Tarballs auf dem Server: /opt/cb-hub/releases/

💾 10. Backup & Monitoring

Backups (Cron: täglich 03:00):

  • pg_dump → gzip → /opt/cb-hub/backups/hub_YYYY-MM-DD.sql.gz
  • Sonntags: zusätzliche Weekly-Kopie
  • Auto-Cleanup: Dailies > 7 Tage, Weeklies > 30 Tage

Monitoring (Cron: alle 5 Min):

  • curl /health — wenn fehlschlägt: Auto-Restart versuch
  • Log: /opt/cb-hub/backups/monitor.log

Restore aus Backup:

gunzip -c backups/hub_2026-03-18.sql.gz | \
docker exec -i cb-hub-postgres psql -U cbhub -d cbhub
💻 11. Lokale Entwicklung

Voraussetzungen: Node.js ≥ 22, Docker (für lokale DB)

# 1. Repo klonen
git clone https://github.com/AtariCoder76/cb_hub.git
cd cb_hub

# 2. DB starten
docker compose up -d postgres

# 3. Dependencies
npm install

# 4. .env anlegen
echo 'DATABASE_URL=postgresql://cbhub:cbhub_dev@localhost:5433/cbhub' > .env

# 5. Starten
npx ts-node-esm src/index.ts
# → http://localhost:4400

Neue Migration erstellen:

# Datei: db/migrate_002_add_feature.sql
ALTER TABLE ... ;

# Wird beim nächsten Deploy automatisch ausgeführt

Neuen API-Endpoint hinzufügen:

  1. Route in src/routes/api.ts oder llm.ts hinzufügen
  2. authMiddleware und ggf. adminMiddleware als Route-Handler einhängen
  3. GUI in public/index.html erweitern (fetch → adminFetch())
  4. npx tsc --noEmit für Type-Check
  5. git push → automatischer Deploy
📋 12. Runbook — Häufige Aufgaben
Aufgabe Befehl
Logs anzeigen ssh root@178.104.0.225 'cd /opt/cb-hub && docker compose logs hub --tail 50'
Container neustarten ssh ... 'cd /opt/cb-hub && docker compose restart hub'
DB-Shell ssh ... 'docker exec -it cb-hub-postgres psql -U cbhub -d cbhub'
Caddy-Config ändern ssh ... 'vi /opt/cb-hub/Caddyfile && cd /opt/cb-hub && docker compose exec caddy caddy reload --config /etc/caddy/Caddyfile'
User zum Admin machen UPDATE owners SET role='admin' WHERE username='...';
Backup manuell ssh ... '/opt/cb-hub/backup.sh'
Disk-Usage ssh ... 'df -h && docker system df'

Umgebungsvariablen (/opt/cb-hub/.env):

POSTGRES_PASSWORD DB-Passwort
RESEND_API_KEY E-Mail-Service (Invite-Mails)
DEPLOY_SECRET CI Release-Upload-Authentifizierung
—
Packages
—
Extensions
—
Skills
—
Downloads
📭

Lade Marketplace...

⚙️ Hub Einstellungen

API Rate Limiting für /api

🏥 Model Health
Min. Abstand zwischen Health-Checks pro Modell

Re-Check Intervalle

Nach X gescheiterten Re-Checks → permanent gesperrt
Wie oft der Hub prüft ob Re-Checks fällig sind