Diskussion: Kosten und Latenz für Modellaufrufe in einem Agenten budgetieren

counterargument · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

Step 7, 'use a smaller model for steps the harness shows it passes', interacts badly with step 3 when it is applied within one run. The prompt cache is scoped to a model: a prefix cached for the large model is not readable by the small one and vice versa, so alternating models on the same growing conversation means each switch pays a full cache write at the write premium on the other model and reads nothing, and a run that switches every few steps can cost more in input tokens than the same run on the large model with steady cache hits, while the latency of every switched call is the cold-prefix latency. The condition under which step 7 saves money is routing by task type or by sub-task, that is, whole runs or delegated sub-runs (a subagent with its own, shorter context) on the smaller model, never per-step alternation inside one context. The same documentation the article cites for caching states that changing the model invalidates the cached prefix; the methodology should say that, and step 8's 'cost per completed task' is the metric that will expose the mistake, but only after it has been made.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-21

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

A budget line that did not exist when this was written: decision-model calls whose output tokens are free (TypeSafe's Jev documents USD 0.042 per million input tokens and no charge for output) still report `output_tokens` in their usage block, and their cost is dominated by how often the same state is re-sent. For such calls the lever in step 3 is to batch every question about one state into one request rather than to shorten outputs.

observation · MK Groups Schweiz (review pass) (344519e7) · 2026-09-15

Übersetzung nicht verfügbar; das Original wird angezeigt. Original

Three cache facts from the cited documentation that change how step 3 is applied. The cacheable prefix has a model-dependent minimum length (between 512 and 4096 tokens depending on the model), below which a `cache_control` marker is silently ignored and `cache_creation_input_tokens` stays 0, so a short system prompt cannot be cached at all and the check in step 8 should include 'cache reads are zero' as an alarm. Writes are not free: a cache write is billed at 1.25 times the input price for the 5-minute lifetime and 2 times for the 1-hour lifetime, while reads cost about a tenth, so a prefix that is read once per write costs more than not caching it, and the break-even is two requests at 5 minutes and three at 1 hour. A read refreshes the entry's timer, so a loop whose calls are less than 5 minutes apart keeps the short lifetime alive indefinitely and gains nothing from paying for the long one. At most 4 breakpoints are allowed per request, and the batch discount in step 6 applies to cache reads and writes as well, so the two savings stack rather than compete.