Zuletzt aktualisiert: 2026-09-04

Coach-in-der-App: Form des Coach-Service auf dem Claude-Abo (Vorschlag StratoClaude, 04.09.2026)

Status: Vorschlag zur Abstimmung (Dennis entscheidet). Antwort auf Ahabs Vorabinfo vom 04.09. zur Spec „Coach in der App" (running-coaching/docs/silverscale-spec-coach-integration.md). Harte Randbedingung (Dennis): Abo, keine API-Tokens. Faktenbasis: Benchmark 30.08. (/dev/benchmark-claude-code-2026-08.html) + Handoff Finsight (/dev/handoff-finsight-claude-sdk-cli.html) + Prefix-Messung 04.09. (--tools). Alles darin ist auf diesem VPS gemessen (Max 5×-Abo, CLI jetzt 2.1.260).

Nicht claude -p pro Knopfdruck, nicht der geplante Messages-API-Tool-Loop.

Form	erstes Token (gemessen)	Urteil
`claude -p` je Knopf (wie `ai_jobs.py`)	5,6–7,4 s (≈4 s Prozess-Init, unverändert in 2.1.26x)	verfehlt < 3 s strukturell — nur für Hintergrund-Jobs ohne wartenden Menschen
SDK `query()` je Knopf (frischer Prozess)	4,1–4,8 s	verfehlt
SDK `ClaudeSDKClient`, Session vorgewärmt	0,7–1,4 s (Folge-Turn), 2,7 s erste Nachricht kalt	trifft das Ziel; einziger Weg auf dem Abo
Messages-API mit Cache-Breakpoints/`effort`	–	API-Key = abgelehnt; entfällt

Warum SDK statt CLI: gleicher Login (~/.claude/.credentials.json, OAuth, kein Key), aber der Prozess lebt weiter — der 4-s-Init fällt aus dem Nutzerpfad. --bare ist API-Key-only und damit tabu (Hilfetext + Messung).

2. Betriebsmodell (das Konkrete)

Host-Daemon auf dem VPS (Container hat kein claude, ADR-13): coach_service.py als Dauerprozess unter User dennis (tmux/systemd wie der AI-Worker), lauscht 127.0.0.1 (oder Unix-Socket in den Container gemountet). FastAPI POST /api/coach/ask reicht per httpx als SSE-Relay durch — der Container bleibt tokenlos, Auth wie gehabt (Session- Cookie außen, X-Internal-Token innen).
Ein Knopf = eine frische, vorgewärmte Session. Pool hält 1 (–2) verbundene Clients bereit (System-Prompt geladen, Mini-Turn gemacht). Knopfdruck → Client aus dem Pool, prefilled Kontext + Skill-Prompt als eine User-Message, Deltas (include_partial_messages) → SSE. Danach Client verwerfen, nächsten aufwärmen. Nachfragen zum selben Knopf laufen im selben Client weiter (Kontext gewollt), harte Grenze ~40–50k Kontext, dann neu. Nie zwei Nutzer/Threads in einem Client (session_id isoliert nicht — gemessen).
Kein Tool-Loop. Kontext ist prefilled (das ist die Stärke der Spec) → tools=[], max_turns=1, eigener kurzer system_prompt (kein claude_code-Preset), setting_sources=None, Auto-Memory aus. Prefix ≈ 250 Tokens + Skill-Text + Kontext, statt 9–29k Ballast pro Turn. Skills/Wissensbasis: der Service liest die Skill-Markdowns aus einem Coach-Repo-Checkout auf dem VPS und baut den Prompt selbst — deterministisch, testbar, kein SDK-Skill-Discovery.
Cache: Systemprompt+Skill-Text wandern von selbst in den Prompt-Cache (Folge-Turns fast nur cache_read); Breakpoints setzt man im SDK nicht selbst. Der prefilled Kontext ändert sich je Knopf, dort gibt es ohnehin nichts zu cachen.
Apply bleibt deterministisch: POST /api/coach/apply wendet strukturierte Vorschläge über die vorhandene Plan-API an (wie die MCP-Write-Wrapper: origin=coach, Notiz, Audit, user_edited-Schutz). Die Vorschläge holt der Service mit output_format (JSON-Schema → structured_output) aus der Antwort, Prosa wird gestreamt. Nicht gemessen — steht auf der Benchmark-Liste unten.
effort: SDK-Option effort (low|medium|high|xhigh|max) + max_thinking_tokens ersetzt output_config.effort 1:1. Für Schätz-Jobs war „Denken aus" richtig; für Coaching-Antworten ist das ungemessen — Start mit medium, dann messen.

3. Abo-Haushalt — der eigentliche Risiko-Punkt

Das 5-h-Fenster ist eines für alle: StratoClaude, MacClaude, Lexi, Finsight, jetzt der Coach. - Vor jedem Knopf GET https://api.anthropic.com/api/oauth/usage (Bearer aus credentials.json, anthropic-beta: oauth-2025-04-20) → five_hour.utilization. Ab 90 % degradieren (Sonnet→Haiku oder ehrliche Absage im Stream „Abo-Fenster voll bis hh:mm"), nie blind feuern. Utilization mit in die SSE-Antwort (meta-Event), die App darf es zeigen. - usage jeder Antwort loggen (cache_read_input_tokens, output_tokens, total_cost_usd nominal) — nominal-$ ist das ehrliche Verbrauchsmaß. - Modell — entschieden (Dennis via Ahab, 04.09.): immer die aktuellste Fable-Version, kein Sonnet-Default. (Mein Vorschlag war Sonnet 5 wegen ~2,6× geringerem nominalen Verbrauch bei gleicher Freitext-Qualität; Fenster-Schutz bleibt das Usage-Gate.) Benchmark vor dem Lock daher nur Fable × Effort-Stufen. - Login-Verfall: Refresh-Token läuft aktuell bis 03.10.2026; die CLI erneuert den Access-Token selbst, der Refresh-Token verlängert sich nur bei Nutzung (nicht im Code geprüft). Daemon braucht Health-Check (Usage-Endpoint 401 → Push an Dennis „claude /login auf dem VPS").

4. Realistische Latenz für Ad-hoc-Knöpfe

Schritt	Erwartung	Basis
Pool-Client nehmen	~0	–
erstes Token, kleiner Prompt	0,7–1,4 s	gemessen (Sonnet/Haiku/Fable 30.08.)
erstes Token, mit 5–10k Token prefilled Kontext	1,5–2,5 s	Schätzung: Input-Verarbeitung nicht gemessen
Antwort fertig (~300 Token Prosa)	+3–5 s Streaming	gemessen: Claude generiert ~1–2 s langsamer als Gemini bei 150–200 Tok
Pool leer (zwei Knöpfe kurz hintereinander)	2,7–4 s erstes Token	erste Nachricht einer kalten Session

Ziel < 3 s TTFT ist mit Warm-Pool realistisch, ohne Warm-Pool nicht. Der ungemessene Posten ist der prefilled Kontext — deshalb vor dem Lock ein Mini-Benchmark mit einem echten Knopf (echter Kontext, echter Skill-Text): TTFT/Wall/Usage je Modell × Effort, 24 Calls je Konfiguration. Dauert einen Nachmittag, kostet nur Abo-Fenster. Das mache ich, sobald die Spec Skill-Text + Kontextform für einen Knopf festgelegt hat.

5. Was ich vom Coach/Ahab brauche

Je Knopf: Skill-Text + Kontext-DTO-Form (welche compact-DTOs, ungefähre Tokenzahl).
Ob Nachfragen im selben Knopf-Kontext vorgesehen sind (Session-Lebensdauer).
Welche Knöpfe „schwer" sind (Modell-Upgrade) und welche strukturierte Apply-Vorschläge liefern.