breakpilot-compliance/docs-src/development/pass0b-cost-benchmark.md

# Pass 0b Kosten-Benchmark (Stand 2026-04-27)

Dokumentation aller Versuche die Pass-0b-Generierungskosten zu optimieren. Ergebnis: **v4-Prompt direkt mit Haiku Batch API ist die kosteneffizienteste Strategie.**

---

## Zusammenfassung

| Strategie | Kosten/10k | Qualitaet | Empfehlung |
|-----------|-----------|-----------|------------|
| **v4 direkt (Haiku Batch)** | **~$33** | Alle 18 Felder | **EMPFOHLEN** |
| v3 + Haiku Backfill | ~$31.60 | Gleich gut, 2 Schritte | Nicht empfohlen |
| v3 + Mac Mini Backfill | ~$25 + 77h Wartezeit | Schwaecher bei applicability | Nicht empfohlen |
| v4 direkt (Sonnet) | ~$95 (geschaetzt) | Gleich gut | Zu teuer |

---

## Getestete Strategien

### 1. Haiku Batch API mit v3-Prompt (14 Felder)

**Felder:** title, assertion, objective, requirements, test_procedure, evidence, pass_criteria, fail_criteria, severity, category, check_type (5 Typen), merge_key, dependency_hints, lifecycle_phase_order

| Batch | Obligations | Controls | Kosten | Kosten/10k |
|-------|-----------|----------|--------|-----------|
| Batch 1 | 10k | 9.885 | $23.00 | $23.00 |
| Batch 3 | 10k | 9.793 | $25.24 | $25.24 |
| Batch 4 | 20k | 19.546 | $49.77 | $24.89 |

**Durchschnitt: ~$24.40/10k**

Token-Verbrauch (Stichprobe):
- Avg Input: ~2.800 Tokens/Request
- Avg Output: ~4.000 Tokens/Request
- 5 Obligations pro Request

### 2. Haiku Batch API mit v4-Prompt (18 Felder)

**Zusaetzliche Felder:** applicability, scanner_hint, manual_review_required_if, evidence_type, provides_context

| Batch | Obligations | Controls | Kosten | Kosten/10k |
|-------|-----------|----------|--------|-----------|
| Batch 2 | 10k | 9.855 | $33.00 | $33.00 |
| Batch 5 | 20k | 19.469 | $67.50 | $33.75 |
| Batch 6 | 20k | 19.529 | $66.42 | $33.21 |
| Batch 7 | 20k | 19.569 | $65.96 | $32.98 |

**Durchschnitt: ~$33.24/10k**

Token-Verbrauch (Stichprobe 20 Requests):
- Avg Input: 3.128 Tokens/Request
- Avg Output: 6.165 Tokens/Request
- 5 Obligations pro Request

### 3. v3 generieren + Haiku Backfill fuer 6 Extra-Felder

**Idee:** Nur Basisfelder via Sonnet/Haiku generieren, Extra-Felder nachtraeglich per guenstigem Haiku-Batch ergaenzen.

| Schritt | Controls | Kosten | Kosten/10k |
|---------|----------|--------|-----------|
| v3 Generation (10k) | 9.885 | $24.40 | $24.40 |
| Haiku Backfill (28.5k) | 28.570 | $18.91 | $6.62 |
| **Gesamt** | — | — | **$31.02** |

**Ergebnis:** Nur ~$2 billiger als v4 direkt, aber 2 separate Schritte noetig. **Nicht empfohlen.**

### 4. Mac Mini (qwen3:30b-a3b) fuer Backfill

**Idee:** Extra-Felder kostenlos lokal per qwen3 generieren statt Haiku.

| Metrik | Wert |
|--------|------|
| Modell | qwen3:30b-a3b (MoE, 3.3B aktiv) |
| Batch Size | 3 (bei 10 → JSON-Parse-Fehler) |
| Avg pro Control | 13.9 Sekunden |
| Hochrechnung 20k | **77 Stunden (3+ Tage)** |
| Erfolgsrate | 100% (bei batch_size=3) |
| Kosten | $0 |

**Qualitaetsvergleich qwen3 vs. Haiku:**

| Feld | Haiku | qwen3 | Bewertung |
|------|-------|-------|-----------|
| check_type | Korrekt | Korrekt | Gleich |
| evidence_type | Korrekt | Korrekt | Gleich |
| applicability | Erkennt Bedingungen (z.B. `context.processes_personal_data`) | Meistens `{}` (universell) | **Haiku besser** |
| scanner_hint | Deutsch, praezise | Englisch, brauchbar | Haiku besser |
| provides_context | Sinnvolle Variablen | Aehnlich, andere Konvention | Gleich |

**Ergebnis:** Kostenlos aber 3 Tage Laufzeit und schwaecher bei applicability. **Nicht empfohlen.**

---

## Kostenmodell (Haiku 4.5 Batch API)

| Metrik | Preis |
|--------|-------|
| Input Tokens | $0.40/1M (Batch, 50% off) |
| Output Tokens | $2.00/1M (Batch, 50% off) |
| Cache Read | $0.04/1M (Batch, 50% off) |
| Cache Write | $0.50/1M (Batch, 50% off) |

**Hauptkostentreiber: Output-Tokens** (5x teurer als Input). Jedes zusaetzliche Feld im Prompt erhoeht die Output-Laenge.

| Prompt-Version | Avg Output/Request | Output-Kosten/Request |
|---------------|-------------------|----------------------|
| v3 (14 Felder) | ~4.000 Tokens | $0.008 |
| v4 (18 Felder) | ~6.165 Tokens | $0.012 |

---

## Warum v4 direkt die beste Strategie ist

1. **Kostendifferenz minimal:** v4 ($33/10k) vs. v3+Backfill ($31/10k) = nur $2 Unterschied
2. **Ein Schritt statt zwei:** Kein separater Backfill-Lauf noetig
3. **Konsistente Daten:** Alle Felder kommen aus dem gleichen LLM-Call, keine Inkonsistenzen
4. **Kein Backfill-Overhead:** Keine zusaetzliche DB-Aktualisierung, kein Monitoring
5. **Qualitaet:** LLM generiert applicability im Kontext der vollen Obligation (besser als nachtraeglich)

---

## Gesamtkosten Pass 0b (180k Obligations)

| Posten | Kosten |
|--------|--------|
| Batch 1 (v3, Test) | $23.00 |
| Batch 2 (v4, Test) | $33.00 |
| Backfill 1 (9.6k) | ~$1.50 |
| Batch 3 (v3) | $25.24 |
| Batch 4 (v3, 20k) | $49.77 |
| Backfill 2 (28.5k) | $18.91 |
| Batch 5 (v4, 20k) | $67.50 |
| Batch 6 (v4, 20k) | $66.42 |
| Batch 7 (v4, 20k) | $65.96 |
| Batch 8+ (v4, ~70k) | ~$231 (geschaetzt) |
| **Gesamt** | **~$582** |

**Urspruengliche Schaetzung:** $264 (basierend auf Sonnet-Batch mit weniger Feldern)
**Tatsaechlich:** ~$582 (Haiku mit 18 Feldern, doppelt so viele Output-Tokens)

---

## Lessons Learned

1. **Output-Tokens dominieren die Kosten** — Nicht Input, nicht Modellwahl
2. **Haiku ist bereits das guenstigste Modell** — Sonnet waere ~3x teurer
3. **Batch API (50% Rabatt) ist Pflicht** — Ohne Batch waere es $1.164
4. **Backfill lohnt sich nicht** — Der Overhead (DB-Updates, Monitoring, Fehlerbehandlung) ueberwiegt die minimale Ersparnis
5. **Mac Mini (qwen3) ist zu langsam** — 77h fuer 20k Controls, und schwaechere Qualitaet bei applicability
6. **v4-Prompt ist der Sweet Spot** — Alle Felder in einem Call, konsistente Qualitaet, akzeptable Kosten

---

## KRITISCH: Duplikat-Batch-Schutz

!!! danger "Batch API Duplikat-Fehler (2026-04-27) — $170 Mehrkosten"
    `curl` meldete einen Timeout/Parse-Error obwohl der Server den Batch bereits an Anthropic
    gesendet hatte. Durch Retry-Versuche wurden **3 identische Batches** erstellt statt 1.
    Die Anthropic Batch API ist NICHT idempotent — jeder POST erstellt einen neuen Batch.
    Auch ein `cancel` stoppt nur unverarbeitete Requests — bereits laufende werden abgerechnet.

### Schutzmassnahmen (implementiert)

1. **Idempotency-Sperre im Submit-Endpoint** — Verweigert Submit wenn letzter Batch <10 Min alt
2. **NIEMALS `curl` fuer Batch-Submits** — Immer `python3 httpx` mit 600s Timeout
3. **Vor jedem Submit** Batch-Liste pruefen: `GET /v1/messages/batches?limit=3`
4. **Anthropic Dashboard** pruefen wenn Kosten unklar

### Korrekte Submit-Methode

```python
# RICHTIG — Python httpx mit langem Timeout, kein Retry
ssh macmini "/usr/local/bin/docker exec bp-core-control-pipeline python3 -c \"
import httpx
resp = httpx.post('http://127.0.0.1:8098/v1/canonical/generate/submit-pass0b',
    json={'limit': 10000, 'batch_size': 5},
    timeout=600)
print(resp.json())
\""

# FALSCH — curl mit Retry-Risiko
# curl -sf -X POST http://127.0.0.1:8098/v1/canonical/generate/submit-pass0b ...
# Bei Timeout → NICHT nochmal ausfuehren!
```