Preisbasis (First-Line-Konto). Offizieller fable-5-Listenpreis: $10 / M Input-Tokens (erfasst 2026-07-24 04:37 UTC von der offiziellen Preisseite; die Seite zeigt $10/MTok — keine Abweichung gegenüber dem hier verwendeten Wert von $10/M; gleiche Erfassung: Cache-Hits $1/MTok, Batch-Input $5/MTok). Die Kosten agentischer Workflows werden von Input-Tokens dominiert: Am Ledger-Tag 2026-07-23 machten Input-Tokens 99.0% des Token-Volumens aus (769,249,823 Input vs 7,387,431 Output) — 95.4% der Dollarkosten zu reinen Listenpreisen und immer noch ≈75.3% nach dem Cached-Input-Rabatt (Output kostet $50/M, ist aber <1% des Volumens). Gemessener effektiver Input-Preis nach den drei Hebeln: $10/M × [(1−94.9%) + 94.9% × $1/$10 Cached-Input-Rabatt] = $1.46/M cache-gemischt → ÷ 2.83× gemessene Kompression (Fenster 07-23, n = 7,222, Median) = $0.52/M → × 50% Saver (offizieller Batch/Flex-Preis) ≈ $0.26 / M (2.6% des Originalpreises) Input-Tokens — der Prozentsatz ist der gemessene effektive Input-Preis ÷ der offizielle Listenpreis von $10/M, berechnet auf der ungerundeten Hebelkette. Vollständige Formel und Vorbehalte in der Methodik-Tabelle.
Engineering-Report
coder: 5.66× Kosteneffizienz auf fable 5 & SWE-Qualität
Alles auf dieser Seite ist eine reale Messung aus unseren eigenen Produktions-Ledgern und Benchmark-Läufen. Jede Zahl ist auf eine maschinell aufgezeichnete Quelle rückverfolgbar. Keine Projektionen, keine Extrapolation.
Aufbauend auf dem Open-Source-codex-CLI/-Agent fokussiert sich coder auf autonomes, langlaufendes Arbeiten (effektives Kontextfenster, §1.1b · SWE-bench A/B, §2) und Kosteneffizienz (Kompression, §1.1 · Saver-Stufen, §1.2). Wer es selbst ausprobieren möchte: coder lässt sich über die offizielle Seite installieren: run.ceo/coder. Da ein externes Verfahren in unserer Produktionsumgebung keine stabilen Ergebnisse lieferte, haben wir unseren eigenen Algorithmus beibehalten.
1 · Kosteneffizienz: zwei unabhängige Hebel
coder senkt die abgerechneten Kosten über zwei getrennte Mechanismen, und diese Seite hält deren Buchführung getrennt: Kompression (gemessen) und Saver-Stufen (ein Preislisten-Fakt). Jeder Hebel hat seine eigene Formel, seine eigene Evidenz und seine eigene Zeile in der Methodik-Tabelle.
Zusammensetzung des Headline-Faktors. Kompressionsterm: gemessener Median pro Request, Session-Ledger 2026-07-23 (n = 7,222, ~/.coder/sessions/2026/07/23/rollout-*.jsonl, 80 Dateien). Saver-Term: offizielle Batch/Flex-Preisliste (beide Lanes zu 50% des Listenpreises ⇒ 2.00×) — ein Preisfakt, keine Traffic-Messung dieses Fensters.
1.1 · Kompression (gemessen)
Die Pipeline liefert dem Modell eine kompakte Repräsentation derselben Session. Pro Request hält das Ledger die unkomprimierte Baseline und den tatsächlich gesendeten Input fest: Faktor = Baseline ÷ gesendet. Median 2.83× (p10–p90 2.26–3.08×) im jüngsten vollständigen Ledger-Fenster (2026-07-23, n = 7,222 Requests).
Qualitätsevidenz für diesen Hebel: das SWE- / SWE-Pro-A/B mit Kompression ON vs OFF (§2) — identische Aufgaben, offizielles Docker-Grading, Pipeline an versus aus — ist die Qualitätsevidenz für diese Kompression: Die Resolution-Ergebnisse folgen dem unkomprimierten Arm innerhalb des Rauschens. Formel und Stichprobenfenster für die 2.83× selbst stehen in der Methodik-Tabelle; dieser Absatz behandelt nur den Kompressionshebel — Saver hat unten einen eigenen Abschnitt.
💰 #.#x = Sparrate — der Statusleisten-Indikator unten links in dieser unbearbeiteten Bildschirmaufnahme ist der live angezeigte Kompressions-Spar-Multiplikator: Er startet am Boden von 2.0× und klettert bis zum Laufende auf 5.1× (Spitze 6.1×), während sich gecachter/komprimierter Kontext ansammelt — 92.4% Cached-Input-Anteil über den gesamten Lauf, laut Session-Rollout-Ledger (12 API-Usage-Einträge, 287,269 Input-Tokens). Die Aufgabe ist eine echte öffentliche SWE-Aufgabe auf pallets/flask (CLI-Feature + Tests, alle grün). Die Wiedergabe ist 8× beschleunigt (Annotation oben rechts); Inhalt unverändert.
1.1b · Effektives Kontextfenster (gleiche Messung, zweite Dividende)
Kompression hat neben den Kosten einen zweiten Effekt: Das physische Kontextfenster des Modells hält die komprimierte Repräsentation, seine effektive Kapazität skaliert also mit demselben gemessenen Faktor. Beim gemessenen Median von 2.83× (p10–p90 2.26–3.08×) trägt ein physisches 200K-Token-Fenster grob 450K–620K Tokens an Session-Inhalt (200K × 2.26–3.08). Die praktische Konsequenz: Lange Sessions geraten selten unter Kontextfenster-Druck — weniger Compaction, weniger verlorener Kontext, stabile langlaufende Arbeit.
- Umrechnungszeile: effektive Kapazität = physisches Fenster × gemessener Kompressionsfaktor. Gleiche Datenquelle wie §1.1; keine separate Messung.
- Reales Beispiel vom selben Ledger-Tag: Eine Session vom 2026-07-23 akkumulierte 58,815,232 Tokens an Would-have-sent-Input, ausgeliefert als 18,622,941 tatsächlich gesendete Tokens (3.16×) — ein Arbeitstag an Kontext-Traffic, getragen mit grob einem Drittel seiner Rohgröße (Session-Ledger
rollout-2026-07-23T09-27-46-019f8fcd….jsonl, kumulativesimgctxOriginalInputTokensvs gesendet).
1.2 · Saver-Stufen (Preisfakt)
Unabhängig vom oben gemessenen Kompressionshebel bietet coder zwei Auslieferungs-Lanes zum halben Preis. Formel: abgerechnet = 50% × Preis der Standard-Lane — ein Preislisten-Fakt, der keine Testevidenz braucht. Er geht in die Headline nur als offiziell bepreister Faktor ein (50% des Listenpreises ⇒ 2.00×) und wird nie in die gemessene Kompressionszahl selbst eingemischt:
- batch — asynchrones Submit-and-Retrieve für nicht-interaktive Workloads (Bulk-Evaluation, Hintergrund-Analysen, geplante Jobs): 50% der Standardkosten.
- flex — dieselbe synchrone Streaming-Schnittstelle, eingeplant auf flexibler Kapazität, für Arbeit ohne Bedarf an reservierter Kapazität: 50% der Standardkosten.
- Gleiche Modelle, gleiche Qualität, gleicher Output — die Stufen ändern das Scheduling, nicht die Ergebnisse.
- Headline-Buchführung: Headline-Faktor = Kompression (gemessener Median 2.83×) × Saver (offizielle Preisliste 2.00×) = 5.66×. Der Saver-Term stammt aus der offiziellen Preisliste (Batch/Flex zu 50% des Listenpreises ⇒ 2.00×), nicht aus dem Traffic dieses Fensters — das Headline-Fenster 2026-07-23 selbst enthielt keinen Saver-Lane-Traffic, weshalb der Term bepreist und nicht traffic-gewichtet ist.
Gemessene Kompressionsfaktor-Quantile, pro Request. Headline-Zeile: Session-Ledger 2026-07-23 (jüngster vollständiger Ledger-Tag, 80 Dateien, n = 7,222). Flotten-Zeilen: Pro-Request-Quantile über 7 Tage realen Gateway-Traffics, 2026-07-14 → 07-21 (reports/CHECK-gateway-real-compression-20260721.md, scratch/gw-real-compression-0721/). Die Baseline-Abdeckung der Flotten-Zeilen ist auf Traffic mit aufgezeichneter unkomprimierter Baseline begrenzt.
Flottenweite reine Kompression (konservativer Gegencheck)
Die Zahlen oben stammen aus den Ledgern einer einzelnen Maschine. Als Gegencheck auf Flottenskala haben wir ausschließlich reine Token-Kompression über 7 Tage realen Gateway-Traffics gemessen:
| Traffic-Bucket | aggregierte Kompression | Median pro Request | Requests mit Baseline-Abdeckung | Fenster |
|---|---|---|---|---|
| fable5-Lane | 2.49× (15.35B → 6.17B Tokens) | 2.45× | 53,500 | 2026-07-14 → 07-21 |
| sol-Lane | 2.14× (1.94B → 0.91B Tokens) | 1.89× | 10,024 | 2026-07-14 → 07-21 |
2 · SWE / SWE Pro: Kompression ON vs OFF
Die Effizienz-Pipeline ist nur dann auslieferungswürdig, wenn sie die Output-Qualität erhält. Wir haben die industrieüblichen SWE-bench-Suiten als internes A/B ausgeführt — identische Aufgaben, identische Modelle, offizielles Docker-Grading-Harness, Pipeline ON (komprimiert) versus OFF (direkt) — beide Suiten neu ausgeführt auf demselben aktuellen Pipeline-Build.
| Suite | ON (komprimiert) | OFF (direkt) | Übereinstimmung | Anmerkungen |
|---|---|---|---|---|
| SWE-bench Lite (n = 10 Paare) | 10/10 | 10/10 | 10/10 | Rerun 2026-07-24, Pipeline 8a9175d |
| SWE-bench Pro (n = 18 Paare) | 15/18 | 16/18 | 17/18 | Rerun 2026-07-23, Pipeline 8a9175d · abweichende Aufgabe: navidrome-0488 (N=5-Äquivalenz-Rerun unten) |
Resolved-Zahlen pro Arm ausschließlich unter den offiziellen Docker-Harnesses (Lite: swebench run_evaluation auf princeton-nlp/SWE-bench_Lite; Pro: SWE-bench_Pro-os, jefzda/sweap-images) — kein LLM-Judging; Pipeline für beide Reruns auf 8a9175d fixiert. Quellen: eval/swe-bench/bench-20260724/, eval/swe-bench-pro/bench-20260723/ (compare_final.txt, eval_results_{on,off}.json). Die Stichproben sind klein (10 + 18 Paare): Das Diagramm zeigt Parität/Übereinstimmung, nicht Überlegenheit.
Die einzige abweichende Pro-Aufgabe, navidrome-0488, wurde mit einem dedizierten Äquivalenz-Rerun mit N=5 pro Arm geklärt: ON 3/5 vs OFF 3/5 — die beiden Arme sind innerhalb des Rauschens äquivalent (Fisher exakt p = 1.0). Alle Verdikte stammen vom offiziellen Docker-Harness (10/10 Läufe benotet, rc = 0), und alle 10 Lauf-Fenster zeigen collapsed_turns = 0 mit null Rewrites, d.h. der Kompressionspfad ließ die Transkripte unangetastet. Varianz-Bilanz: Die 4 fehlgeschlagenen Läufe verteilen sich ON 2 + OFF 2 und teilen dasselbe Modell-Selbstfehler-Muster — der unkomprimierte Arm tritt in dieselben Löcher. Verdikt: Die ursprüngliche Abweichung ist agentische Run-to-Run-Varianz, kein Kompressionsschaden (N=5-Verdikt-Report). Scope-Anmerkung: N = 5 pro Arm auf einer Instanz, gleiches Protokoll und gleiche Instanz wie §2, Pipeline 8a9175d — eine Äquivalenz-Lesart bei kleinem N, keine universelle Aussage.
- SWE-bench Lite (n=10 Paare, Rerun auf aktueller Pipeline): ON 10/10 vs OFF 10/10, Übereinstimmung 10/10 — null abweichende Instanzen; jedes Paar wurde in beiden Armen identisch gelöst. Lite ist eher leicht, diese Suite misst also Parität bei gleicher Schwierigkeit, nicht Überlegenheit.
- SWE-bench Pro (n=18 Paare, Rerun auf aktueller Pipeline): ON 15/18 vs OFF 16/18; die Verdikte stimmten bei 17 von 18 Aufgaben überein. Die einzige abweichende Aufgabe ist oben geklärt (navidrome-0488 N=5-Äquivalenz-Rerun: ON 3/5 vs OFF 3/5, Fisher p = 1.0, Verdikt: agentische Varianz).
- Fehler-Ausrichtung (Pro): Abgesehen von der einen abweichenden Aufgabe schlug jeder Pro-Fehlschlag in beiden Armen fehl (ansible, eine element-web-Instanz).
- Kontexttreue: 98/98 beantwortbare Recall/State-Proben in beiden Armen korrekt, und 0/16 fabrizierte Antworten bei bewusst unbeantwortbaren Proben in beiden Armen.
Aufgabenliste & rohe Grading-Belege
Lite-Instanzen (Rerun 2026-07-24, gleiche feste Stichprobe wie der 06-10-Pilot): django-14999, sympy-16503, matplotlib-23913, scikit-learn-13497, pytest-dev-5221, astropy-6938, sphinx-doc-7975, psf-requests-2674, pylint-dev-5859, pydata-xarray-3364 — ON 10/10 vs OFF 10/10, Übereinstimmung 10/10, keine abweichenden Instanzen (offizielles Docker-Harness, swebench==4.1.0, Resolved-Verdikte). Pro-Stichprobe (n=18 Paare, Rerun der neuesten Pipeline auf identischen Instanzen): NodeBB ×2, qutebrowser ×2, flipt ×2, openlibrary ×2, teleport ×2, tutanota ×2, element-web ×2, navidrome ×2, ansible, vuls — ON 15/18 vs OFF 16/18; Fehlschläge in beiden Armen: ansible und eine element-web-Instanz; die einzige Einzelarm-Abweichung ist navidrome-0488 (geklärt durch den N=5-Äquivalenz-Rerun oben). Rohe Judge-JSON: eval/swe-bench/bench-20260724/ (compare_final.txt, eval_results_{on,off}.json, preds_{on,off}.json), eval/swe-bench-pro/bench-20260723/ (gleiches Layout); Proben-Antworten: eval/gist-recall/work*/results.jsonl.
3 · Methodik: woher jede Zahl kommt
Unsere Regel für diese Seite: Eine Zahl erscheint nur, wenn sie sich auf einen maschinell geschriebenen Datensatz oder ein reproduzierbares Skript zurückführen lässt. Formeln und Stichprobenfenster unten.
| Zahl | Formel / Definition | Stichprobenfenster | Primärquelle |
|---|---|---|---|
| Kompression 2.83× (2.26–3.08) | pro Request savingsBreakdown.factors[compression]; unkomprimierte Baseline ÷ tatsächlich gesendeter Input |
2026-07-23 (jüngster vollständiger Ledger-Tag), n=7,222 | ~/.coder/sessions/2026/07/23/rollout-*.jsonl (80 Dateien) |
| effektives Fenster ≈ physisch × 2.26–3.08; Beispiel 58.8M→18.6M (3.16×) | die Kapazitätsumrechnung nutzt die Kompressionsverteilung aus §1.1 unverändert; Beispiel = kumulatives imgctxOriginalInputTokens ÷ (Original − imgctxSavedInputTokens) für eine Session |
gleiches Fenster; Beispiel-Session 2026-07-23 | gleiche Ledger · rollout-2026-07-23T09-27-46-019f8fcd….jsonl |
| Saver 2.00× (Batch/Flex zu 50% des Listenpreises); Headline 5.66× = 2.83× × 2.00× | Batch-/Flex-Lane-Preis = halber Preis der Standard-Lane ⇒ konstanter bepreister Faktor 2.00×; offizielle Preisdefinition, keine Messung (Ledger-Kodierung: Saver-Lane-Anteil von C2 zu ½ in C3 abgerechnet); Headline-Produkt = gemessener Kompressions-Median × 2.00 — der Saver-Term ist aus der Preisliste bepreist, nicht traffic-gewichtet (dieses Fenster enthielt keinen Saver-Lane-Traffic) |
Preisfakt (n/a); Kompressionsterm: gleiches Fenster 2026-07-23 | Preisliste · Ledger-Formelfeld savingsBreakdown.formula |
| First-Line-Preiskonto: Liste $10/M → effektiv ≈ $0.26/M Input | effektiv = $10/M Liste (offiziell) × [(1−c) + c × ($1/$10) Cached-Input-Preisverhältnis] ÷ 2.83 (gemessener Kompressions-Median) × 0.50 (offizieller Batch/Flex-Faktor), mit c = 94.9% gemessenem Cached-Input-Anteil (729,830,406 gecachte von 769,249,823 Input-Tokens). Input-Dominanz: Input = 99.0% des Token-Volumens; 95.4% der Dollarkosten zu reiner Liste, ≈75.3% nach dem Cached-Input-Rabatt (Output zu $50/M). Die Cache-Write-Prämie ($12.50–$20/M Write-Lanes) ist in diesem Konto nicht verrechnet — als Vorbehalt genannt, nicht versteckt. Die Annotation “(2.6% des Originalpreises)” = ungerundeter effektiver Input-Preis ÷ offizieller Listenpreis von $10/M ($0.2582/M ÷ $10/M = 2.58%, angezeigt als 2.6% mit einer Dezimalstelle). | Preiserfassung 2026-07-24 04:37 UTC; Token-Aufteilung & Cached-Anteil: Ledger-Tag 2026-07-23, 140 Rollout-Dateien, 6,102 Requests mit Usage-Daten (eigener Ganztages-Rescan; die Kompressions-Median-Zeile nutzt das ursprüngliche 80-Dateien-Fenster) | Capture der offiziellen Preisseite (/tmp/perf-v10-ab/8d742ca7.html) · ~/.coder/sessions/2026/07/23/rollout-*.jsonl, Summen von last_token_usage pro Request |
| SWE-bench Lite 10/10 vs 10/10, Übereinstimmung 10/10 | offizielles Docker-Harness swebench run_evaluation (princeton-nlp/SWE-bench_Lite), Resolved-Verdikte |
feste 10-Paar-Stichprobe · Rerun 2026-07-24, Pipeline 8a9175d | eval/swe-bench/bench-20260724/ (compare_final.txt, eval_results_{on,off}.json) |
| SWE-bench Pro 15/18 vs 16/18, Übereinstimmung 17/18 | offizielles SWE-bench_Pro-os-Harness, jefzda/sweap-images |
feste 18-Paar-Stichprobe · Rerun der neuesten Pipeline (8a9175d) | eval/swe-bench-pro/README.md + bench-20260723/ (compare_final.txt) |
| navidrome-0488 N=5-Äquivalenz: ON 3/5 vs OFF 3/5, Fisher p = 1.0 | ausschließlich offizielle Docker-Harness-Verdikte (10/10 Läufe benotet, rc = 0); Fisher-Exakt-Test auf 3/5 vs 3/5; alle 10 Lauf-Fenster collapsed_turns = 0, null Rewrites; 4 Fehlschläge = ON 2 + OFF 2, gleiches Modell-Selbstfehler-Muster in beiden Armen |
N = 5 pro Arm, einzelne Instanz (navidrome-0488), Pipeline 8a9175d | N=5-Verdikt-Report |
| Benchmark-Kompression pro Request 2.00× / 2.49× | kontrafaktisch: count_tokens(would-have-sent) ÷ gesendet, pro Request summiert — kein Turn-Count-Confound |
Lite 198 Requests (Rerun 2026-07-24) / Pro 316 Requests | gleiche READMEs (Lite: 85,804,350 vs 29,942,152 Tokens) |
| Kontexttreue 98/98, 0/16 | benotete Recall-/State-/Fabrikations-Proben, Text-Arm vs Imaged-Arm in Produktionsdichte, gleiches Modell (fable5), deterministisches String-Grading, Answer-or-UNKNOWN-Protokoll | 114 + 16 Proben pro Arm, ein Seed, 228 Modellaufrufe (2026-06-10) | eval/gist-recall/README.md + work*/results.jsonl |
| Imaged-Route verbatim 0/15; semantisch 27–40% | eindeutiger 12-Zeichen-Hex nur innerhalb von Imaged-Content platziert; exakte und semantische Retrieval-Proben über den Live-Proxy; 2×2 {verbatim, semantisch} × {Kompression ON, OFF}, N=15 pro Zelle | opus-4-5- und opus-4-8-Läufe | eval/needle-haystack/README.md + results2.tsv |
| Dichte-Klippe 1/4 (+3 Konfab) bei 5x8 → 4/4 (0 Konfab) bei 9x12 | Exact-String-Recall auf dem Produktions-Renderer, ein Lauf pro Zelle; ein unabhängiger TrueType/Levenshtein-Sweep reproduziert dieselbe monotone Klippe | Live-Lauf 2026-07-05 (n=1 pro Zelle, Richtung stabil über 3 Läufe) | eval/opus-density/RESULTS.md + results.json |
Bekannte Grenzen (genannt, nicht versteckt)
- Der Kompressionsterm der Headline (2.83×) ist auf den Session-Ledgern einer einzelnen Build-Maschine gemessen — der Saver-Term (2.00×) ist ein Preisfakt, keine Messung; der flottenweite Gegencheck berichtet reine Kompression auf Flottenskala.
- Die Benchmark-Stichproben sind klein (10 + 18 Paare; der Äquivalenz-Rerun ist N=5 pro Arm auf einer Instanz). Wir berichten Parität, Übereinstimmung und Äquivalenz innerhalb des Rauschens, nicht Überlegenheit.
- Das First-Line-Preiskonto mischt den Eintages-Cached-Input-Anteil einer Maschine (94.9%) mit offiziellen Listenpreisen; Cache-Write-Prämien sind aus der Mischung ausgeschlossen und als solche genannt. Effektivpreis-Zahlen sind Arithmetik über gemessene Konten, kein Abrechnungsangebot.
- Dollarsummen ganzer Läufe über Arme hinweg enthalten Turn-Count-Varianz und werden auf dieser Seite bewusst nicht als Kompressionsevidenz verwendet.
- Die Kontexttreue-Matrix ist ein Modell, ein Seed, ein Tag (98 beantwortbare Proben pro Arm).
- Währungsumrechnungen in Ledgern nutzen eine geschätzte FX-Referenz (frankfurter, 2026-06-30), keine Rechnungs-FX.