Zum Inhalt springen
Olivares AI docs

Modul II — Live-Betrieb & Sessions

Modul II ist die Live-Betriebs-Sicht des Estate: was jede Agent-Session gerade tut, ihre Live-Token- und Kostensummen, ein abgeleiteter Claude-Code-State und eine rekonstruierbare Timeline. Während Modul I (Inventar) das dauerhafte Estate materialisiert, hält Modul II ein Live-Betriebs-Overlay pro Session über demselben Beobachtungsstrom — und zeigt nur, was dieser Strom ehrlich trägt.

Olivares 0.4 startet auch offizielle Anbieter-CLIs als eigene Kinder unter einem Anbieterprofil. Dieser verwaltete Pfad ist dasselbe Modul. Er ersetzt das Overlay nicht und führt zwei Homes, die dieselbe Anbieter-Session-ID bekanntgeben, nicht zusammen (CHANGELOG.md [26.9.0] B1/B2).

Was es ist

Abschnitt betitelt „Was es ist“

Modul II ist ein busgetriebenes Modul der Core-Schicht, Geschwister des Inventars. Es pflegt einen Live-Datensatz, der nach der externen Referenz jeder Session gekeyt ist, aufgebaut aus dem kooperativen Beobachtungsstrom — nie gepollt, nie erfunden. Pro Session verfolgt es:

  • die aktuelle Aktion (das zuletzt verwendete Tool) und die Ressource/den Modus, die sie berührte;
  • die Live-Token- und Kostensummen, gelesen aus Kostenproben (das kanonische Kosten-Ledger und FinOps sind Modul XI, nicht hier — dies ist nur die Live-Zahl);
  • einen abgeleiteten Claude-Code-State (cc_state); und
  • eine Timeline, an die jedes beobachtete Event in Ingest-Reihenfolge angehängt wird.

Sein Vertrag & seine Entitäten

Abschnitt betitelt „Sein Vertrag & seine Entitäten“

Das Modul registriert zwei mandantenbezogene Entitäten. sessions.live hält den Live-Datensatz pro Session — aktuelle Aktion/Ressource/Modus, Modellreferenz, Live-Input/-Output-Tokens, Live-Kosten, Event- und Tool-Call-Zähler sowie First/Last-Event-Zeitstempel. sessions.timeline hält eine abspielbare Zeile pro Event, geordnet nach Ingest. Es gibt keine gespeicherte Lebenszyklus-Spalte: Der kooperative Strom trägt kein Ende-oder-Fehler-Signal, sodass das einzige ehrliche Lebendigkeitssignal der abgeleitete cc_state ist.

cc_state wird zur Lesezeit aus der Aktualität der Events abgeleitet — active / idle / ended — und wechselt in einen Silent-Evasion-State, wenn der Connector dieses Finding meldet (es wird nie vom Modul selbst geschrieben). Reads werden unter Modulrouten bedient (Live-Liste, einzelne Session, Session-Timeline) plus einem Live-SSE-Stream; jeder Read erfordert die Session-Leseberechtigung, und das Öffnen des Streams wird automatisch auditiert. Der SSE-Kanal ist streng mandantenisoliert (ein Client erhält nur Snapshots für seinen autorisierten Mandanten) und Best-Effort (ein langsamer Client verwirft den Zwischenframe und erhält den nächsten — die Ingestion blockiert nie).

Provider profiles and live_ref

Abschnitt betitelt „Provider profiles and live_ref“

Ein Provider-Profil ist die dauerhafte Identität einer konfigurierten Provider-Instanz auf einer Ausführungsumgebung: Treiber, Umgebung und das kanonische config_home / user_home. Es ist kein authentifiziertes Provider-Konto. Registrieren, umbenennen, deaktivieren/aktivieren und zurückziehen leben unter /v1/m/sessions/provider-profiles. Pfade erscheinen nur auf dem Admin-configuration-Read. Ein Start nennt provider_profile_ref; der Server löst die Homes auf und speichert vor dem Spawn einen nicht-geheimen Snapshot auf dem Run (CHANGELOG.md [26.9.0] B1; web/src/features/agentops/types.ts).

Eine Beobachtung fällt in die Live-Zeile ihres Kanals, den der Server aus der host-gestempelten Quellenregistrierung berechnet (CHANGELOG.md [26.9.0] B2):

Channel Meaning
legacy no registration
observed a source dedicated to a profile by a binding approved at host admission for the exact applied revision
source a known registration with no verifiable profile
managed a run the plane launched; the only row carrying canonical_sid and run_ref

Jede Live-Zeile stellt live_ref und attribution bereit. Zwei Homes, die dieselbe Provider-Session-ID bekanntgeben, sind zwei Zeilen mit zwei Timelines. Lesen Sie eine Zeile mit GET /v1/m/sessions/live/by-id/{live_ref} (und ihrer Timeline- / Stream- / Runs-Abfrage). Nackte External-ID-Routen bleiben und sind Legacy: sie antworten nur für die Legacy-Zeile.

Treiber werden beim Start auf jedem Knoten registriert. Beim Sitzungsstart verwendet die Engine die neueste verifizierte verwaltete Installation, danach die CLI im PATH der Engine. OLIVARES_SESSION_RUNTIME_CLAUDE_BIN, _CODEX_BIN, _GROK_BIN und _OPENCODE_BIN überschreiben diese Auflösung ausdrücklich (siehe Konfiguration). Wird keine Programmdatei gefunden, wird der Start verweigert. Weitere Bereitschaftsprüfungen, einschließlich Profil-Authentifizierung und Startrichtlinie, gelten weiterhin. Operator-Schritte: Eine Provider-Session betreiben.

Lebenszyklus verwalteter Läufe und Neustartgrenzen

Abschnitt betitelt „Lebenszyklus verwalteter Läufe und Neustartgrenzen“

Sessions ist ein Kernmodul: Es läuft auch dann weiter, wenn es nicht in der gespeicherten Modulauswahl steht. Das Ausschalten eines optionalen Moduls setzt keine Sitzungsdaten zurück.

Die Managed-Run-API unter /v1/m/sessions/runs und olivares session verwenden dieselbe Runtime. Das Lesen von Läufen erfordert sessions:run:read; Start, Eingabe, Stopp und Resume erfordern sessions:run:write. Ein Viewer kann einen Lauf lesen, ohne ihn stoppen zu dürfen. Mandanten- und Workspace-Autorität gelten weiterhin für jeden Lauf.

Terminal-Fenster
olivares session ls -o json
olivares session show <session> -o json
olivares session send <session> "continue the task"
olivares session stop <session>
olivares session resume <session>

Eine Nachricht kann Bilder enthalten. olivares session send <session> --attach shot.png "what is wrong here?" und das Eingabefeld der Konsole (Einfügen, Ablegen oder die Büroklammer) speichern jedes PNG, JPEG, WebP oder GIF bei der Sitzung, bis zu vier pro Nachricht und je 3.75 MB, und senden sie dann mit dem Text; eine Nachricht braucht ihren Text, daher wird ein Bild allein nicht gesendet (die CLI und das Eingabefeld fordern ihn an). Claude Code erhält einen Bild-Content-Block und Codex seine eigene Bildeingabe; ein Tool ohne Bildeingabe lehnt die Nachricht namentlich ab, bevor etwas gesendet wird. Die API ist POST /v1/m/sessions/runs/{ref}/attachments (das Bild, base64), GET .../attachments/{id} und attachments auf .../input. Bilder liegen unter dem Datenverzeichnis, je Mandant und Sitzung, und werden mit der Sitzung entfernt.

Gestoppte Läufe, ihre Referenzen auf Provider-Profil und Workspace sowie Lebenszyklus-Events überstehen einen Neustart der Engine. Resume startet einen neuen eigenen Kindprozess für den bestehenden Lauf. Die Live-Attach-Ausgabe ist ein begrenzter In-Memory-Ring; gespeicherte Lauf-Metadaten und Lebenszyklus-Events versprechen kein persistiertes Gesprächsprotokoll. Aufzeichnungsrichtlinie und die eigene Resume-Unterstützung des Tools bleiben getrennte Anforderungen.

Was es konsumiert (und was es ableitet)

Abschnitt betitelt „Was es konsumiert (und was es ableitet)“

Modul II konsumiert denselben Minimal-Data-Beobachtungsstrom wie das Inventar — edge.observed, cost.sampled und finding.reported. Nur Edges, deren Herkunft eine Session ist, erzeugen Live-Betrieb; an eine Session gebundene Kostenproben tragen zur Live-Token-/Kostenzahl bei (hier wird kein CostRecord geschrieben); Findings mit Session-Subjekt werden annotiert, und ein Anti-Evasion-Finding markiert den Evasion-State. Zwei Felder werden live abgeleitet aus denselben Signalen: agent_ref aus dem einer Session zugeordneten Agent und summary aus einem Context-Compaction-Finding (forensisch), dessen Titel per Vertrag summary-safe ist — niemals eine vom LLM erfundene Zusammenfassung.

Verwandt

Abschnitt betitelt „Verwandt“