Price a session that switched models per stretch, not at the one it ended on

[webmatze]

Closes #103

Session::Data held one model and one usage, so everything that turns tokens into money charged an entire session at the rate of whatever model it ended on. The case #99 left behind: 100k prompt + 20k completion on claude-opus-5, then /model claude-haiku-4-5, reported as $0.20 for $1.00 of work.

The shape

Usage is recorded per provider/model stretch and priced per stretch.

• Agent gains usage_by_model. It already added money up per response at the rates in force — that is what made --max-budget-usd immune to this — and now counts tokens the same way, keyed by the model that was asked. Keyed by model alone: /model switches the model and leaves the client, its key and its connection alone, so the provider is not the agent's to track.
• Session::UsageSegment — a list, not a hash keyed by "provider/model". A model name may contain a slash (anthropic/claude-sonnet-5 is how OpenRouter spells one), and a key that cannot be taken apart again is not a key.
• Data#usage stays the total. Plenty reads it and none of that wants to know about models. The split is for pricing, where the rate differs per stretch.
• The Eine Session verliert ihre Lebenszeit-Nutzung beim Resume #102 baseline gains a sibling, taken at the same moment and for the same reason: a run's split is added to what the session had, not written over it.
• Stats.aggregate iterates segments. Per entry, not per segment, for the session count — a session that switched is still one session.
• The running cost line reads spent_usd directly whenever a budget is set. That is criterion 4: the line and BudgetExceeded could not agree after a switch, because one summed per turn and the other priced the lot at the current model.
• smith sessions export prints the split, in Markdown and JSON, but only when there is more than one segment — one segment is the header again.

No migration

A record written before the split has one model and one block of usage, which is one segment, and is read as exactly that. Old rows are rewritten only when a real turn saves the session anyway. A spec pins this.

One subtlety that cost a spec failure before it was found: a session that has spent nothing gets no segment. Otherwise the model a fresh session merely declares enters the baseline through build_agent and gets merged into the run's real segments — and is then reported as a model that was never asked anything. The first version of this had that bug and the spec caught it as a phantom third model.

Two rules, both now in the README

• smith stats lists a session under every model it used, and still counts it as one session.
• A session with any stretch on a model with no known price reports n/a — not a sum quietly missing a part. Same rule as a single-model session; pricing.cr would rather say nothing than say something wrong.

The known-limitation note is gone

README.md carried it explicitly, and criterion 2 asks for its removal once the thing is true. The /model CHANGELOG entry for #94 now points forward to #103 rather than describing the limit as current.

Specs

Two, and each was verified against both halves of the change: reverting the per-model persist (one segment for the ending model) fails them, and so does reverting the per-segment aggregation (entry.segments[0, 1]). One drives a real switch through build_agent/persist and asserts the COST column, Stats.aggregate, the by-model breakdown and the session count — including an explicit assertion that the figure is not the old ending-model one. The other reads a segment-less record and pins the fallback.

crystal spec: 1434 examples, 0 failures. crystal tool format --check: clean.

🤖 Generated with Claude Code

[webmatze]

Review durch einen Reviewer-Agenten, drei Runden: REQUEST CHANGES, dann APPROVE WITH NITS, dann grün. Zwei der Befunde waren Wege, die Geschichte einer Session zu verlieren oder falsch zuzuordnen.

Blocker 1: der Leerheits-Guard prüfte ein Feld, das der Provider meldet

Data#segments testete usage.total_tokens.zero?. total_tokens ist aber kein berechnetes, sondern ein gemeldetes Feld: openai.cr:266, ollama.cr:281 und openrouter.cr:327 setzen es auf 0, wenn der Provider den Schlüssel weglässt, während prompt_tokens und completion_tokens echte Zahlen tragen. Anthropic rechnet es als input+output und lässt abrechenbare Cache-Tokens weg.

Eine Session mit 100k Prompt- und 20k Completion-Tokens und gemeldeter Null verlor beim nächsten Turn alles — aus den Segmenten, der COST-Spalte und smith stats — und zwar endgültig, weil die nächste Baseline die gekürzte Liste liest. Data#usage hielt die 120.120 weiter: genau der Pfad, auf dem Skalar und Segmente auseinanderlaufen können.

Usage#empty? fragt jetzt die vier Felder, die die Zählungen tragen. Der Reviewer hat gegengeprüft, dass das nicht bloß ein richtiger Test ist, sondern der: es ist genau dann wahr, wenn Pricing.cost unter jeder Ratentabelle 0.0 liefert. Alle acht Konstruktionsstellen von Usage bauen aus prompt/completion/cache — keine kann Geld außerhalb dieser vier kodieren.

Blocker 2: /model schrieb die Vergangenheit um

switch_model setzte session_data.model und überließ den Rest dem Speichern. Ein Datensatz von vor #103 trägt keine Segmente und leitet sein eines aus model ab — der Fallback las also die gesamte Lebenszeit als das Modell, auf das gerade gewechselt wurde.

Das Beispiel aus dem Issue selbst, auf diesem Branch reproduziert: 100k+20k echt auf claude-opus-5, resume, /model claude-haiku-4-5, kein Turn, quit → COST $1.00 → $0.20. Nicht vorübergehend: session.json trägt danach model: haiku bei weiter leeren Segmenten, also leitet jedes spätere Resume denselben falschen Split neu ab.

main verhält sich identisch — es ist also kein Regress dieses PRs. Aber der PR-Text und die README behaupteten beide, das könne nicht passieren. Der Split wird jetzt festgeschrieben, bevor das Modell sich bewegt. Der Reviewer hat die Ordnungs-Gefahren durchgespielt: fünfmal /model hintereinander samt abgelehntem Namen, No-Op und bloßem Aufruf → weiterhin ein Segment mit 120.000 und $1.00; auf einem Datensatz, der bereits Segmente hat, ist es eine Selbstzuweisung einer Kopie.

spent_usd war die falsche Zahl zum Anzeigen

Das Issue bot als Kriterium 4 an, die laufende Kostenzeile bei gesetztem Budget direkt aus Agent#spent_usd zu lesen. Das habe ich zuerst getan — und es ist falsch: spent_usd ist die Durchsetzungs-Zahl und zählt eine Strecke ohne bekannte Rate als nichts. Mit --max-budget-usd und einem unbepreisten Modell hätte die Zeile $0.00 gedruckt, wo main n/a druckt, und --json hätte "cost_usd": 0.0 statt null geliefert — gegen die Regel, die output.cr:353 wörtlich formuliert: „a caller must not read 'unknown' as 'free'".

Jetzt wird immer über die Segmente bepreist. Der Reviewer hat über einen echten Wechsel gemessen: spent_usd und run_cost unterscheiden sich um exakt 0.0. Der Widerspruch mit BudgetExceeded, um den es dem Kriterium ging, ist also beseitigt — nur eben von der ehrlichen Seite. Die Durchsetzung selbst ist unberührt: over_budget? liest weiter spent_usd.

Die n/a-Regel ist geteilt, nicht vereinheitlicht

Die Zahl einer Session ist n/a, sobald irgendeine ihrer Strecken auf einem unbepreisten Modell lief — kein Betrag, dem still ein Teil fehlt. Die Gesamtsumme in smith stats macht es weiter umgekehrt: sie addiert, was sie bepreisen kann, und zeigt die unbepreisten Modelle als eigene n/a-Zeilen in der Aufschlüsselung. Das ist Absicht und steht mit Begründung in README und CHANGELOG: eine Zahl beschreibt eine Session und muss stimmen oder fehlen, die andere fasst viele zusammen und sagt, welche Teile sie nicht bepreisen konnte.

Die Spec-Lücke war real

Mein PR behauptete, ein Spec halte die Kompatibilität fest. Der Reviewer zeigte: nichts lud einen echten Vor-#103-Index von der Platte — und genau der ist der Fallback, auf den es ankommt, weil smith stats und die COST-Spalte den Index lesen und nicht die Session-Datei. Das Löschen von IndexEntry#segments' Fallback ließ die gesamte Suite grün.

Jetzt schreibt ein Spec eine Vor-#103-index.json von Hand — dieser Build könnte nur die neue Form erzeugen — und fällt mit got: 0, wenn der Fallback entfernt wird. Jeder der drei neuen Specs fängt genau seinen Fehler und keinen anderen.

Was sonst gegengeprüft und sauber war

Mehrfaches Persistieren verdreifacht kein Segment (die Falle, vor der #102 warnt), Resume mit Rückwechsel dupliziert nichts, ein Fork startet ohne Segmente, ein handgeschriebener Vor-#103-Datensatz liefert identische Zahlen wie main, kein JSON::Serializable::Strict irgendwo — ein älterer Build ignoriert das neue Feld einfach —, Subagenten falten ihre Nutzung nicht in die des Elternteils, und same_target? benutzt dasselbe Pricing.key_for, nach dem Stats gruppiert, sodass Merge und Aggregation nicht über Identität uneins werden können.

crystal spec: 1437 Beispiele, 0 Fehler. crystal tool format --check: sauber. CI grün auf beiden Plattformen.