Prompt-Cache in Launcherry: Schreibzugriffe ohne Wiederverwendung im Produktionsbetrieb
Bei Launcherry schrieben wiederholte Generierungsaufrufe zwar Prompt-Tokens in den Cache, lasen im selben Lauf jedoch nichts zurueck. Dasselbe Muster zeigte sich bei der Google Search Copy Bank und den Analyse-Aufzeichnungen.
Veröffentlicht am 8. Oktober • Ursprünglich veröffentlicht auf ivanped.ai
Ich fand das Caching-Problem in den Produktionsnutzungsprotokollen von Launcherry: Wiederholte Generierungsaufrufe schrieben Prompt-Tokens in den Cache, lasen innerhalb des Laufs aber nichts zurück. Die Google-Search-Kopiebank und die Analyseprotokolle zeigten dasselbe Muster. Ich musste verifizieren, was spätere Aufrufe durch die Anwendung tatsächlich wiederverwendeten, anstatt mich darauf zu verlassen, dass Caching konfiguriert war.
Ich behandelte das als eine Betriebsfrage, die Belege brauchte. Das relevante Ergebnis war, ob spätere Aufrufe tatsächlich geeigneten Kontext wiederverwendeten. Eine Cache-Einstellung, eine erfolgreiche Antwort oder ein niedrigerer Schätzwert in einer Tabelle konnte dieses Verhalten nicht belegen.
Die Verifizierung vom 17. September dokumentiert die Untersuchung und die Korrektur. In jedem von zwei späteren Generierungs-Reparaturaufrufen wurden 3.879 von 3.932 Eingabe-Tokens aus dem Cache gelesen. Das sind 98,65 %, gerundet 99 %. Das Ergebnis beschreibt die Wiederverwendung von Prompt-Tokens in diesen gemessenen Aufrufen, keine produktweite Wiederverwendungsrate oder eine Kostenersparnis von 99 %.
Generierung und Reparatur haben für diese Untersuchung eine nützliche Beziehung. Sie betreffen dieselbe zugrunde liegende Arbeit, während eine Reparatur eine spezifische Korrektur anfordert. Mancher Kontext kann über diese Aufrufe hinweg relevant bleiben; andere Teile müssen sich ändern. Das Anfragedesign muss die Unterscheidung bewahren.
Ich untersuchte das Verhalten über den eigenen Adapter der Anwendung und den Produktions-Pfad zum Anbieter. Der protokollierte Test verglich Anfragen, die relevante Bedingungen konstant hielten, mit Anfragen, die sie änderten. Das half festzustellen, welche Änderungen die Wiederverwendung beeinträchtigten, anstatt jeden Cache-Miss als dasselbe Problem zu behandeln.
Mein Ausgangspunkt ist die Anfrage, die das Produkt tatsächlich sendet. Zwei Prompts, die für einen Menschen ähnlich erscheinen, können sich in Weise unterscheiden, die für den Cache des Anbieters relevant sind. Das Modell, die Anfragekonfiguration und das umgebende Adapterverhalten gehören ebenso zur Untersuchung wie die geschriebenen Anweisungen.
Die Bedingungen der Anbieter unterscheiden sich ebenfalls. OpenRouters Dokumentation zum Prompt-Caching unterscheidet das Lesen gecachter Tokens vom Schreiben in den Cache und beschreibt anbieterspezifisches Verhalten. Ich nutze diese Dokumentation, um eine Prüfung zu rahmen, und verlasse mich dann auf die gemessene Antwort der Anwendung, um ihr Ergebnis festzustellen.
Ich richtete eine Korrektur auf das Design der Generierungsanfrage, damit wiederholte Reparaturarbeit ihren gemeinsamen Kontext wiederverwenden konnte. Die Arbeit behielt die Generierungsanforderungen und die Validierungsverantwortlichkeiten bei. Die Wiederverwendung musste die bestehende Aufgabe des Produkts unterstützen, statt zum Vorwand zu werden, seine Prüfungen abzuschwächen.
Die Implementierung wurde von Regressionstests begleitet, die das relevante Anfrageverhalten und die Beziehung zwischen Entwurf und Reparatur abdeckten. Diese Prüfungen liefern wiederholbare Belege dafür, wie die Anwendung ihre Arbeit konstruiert. Ein Live-Rerun lieferte dann den Nachweis über die Cache-Lesevorgänge.
Ich halte diese Prüfungen getrennt. Ein Unit-Test kann die Anfragestruktur der Anwendung unter seinen Testbedingungen feststellen. Er kann nicht beweisen, dass ein entfernter Anbieter einen Cache-Treffer zurückgab. Umgekehrt kann ein einzelner Anbieter-Treffer nicht belegen, dass alle umgebenden Anwendungspfade korrekt bleiben. Die Untersuchung brauchte beide Arten von Belegen.
Der protokollierte Rerun umfasst Vorbereitungsaufrufe vor den beiden erfolgreichen Reparatur-Lesevorgängen. Diese früheren Aufrufe schrieben Cache-Einträge. Die Reparaturen 2 und 3 lasen dann jeweils 3.879 von 3.932 Eingabe-Tokens aus dem Cache und schrieben keine neuen Cache-Tokens. Zähler und Nenner gehören jeweils zu diesen Aufrufen.
Ich berechne das Verhältnis, indem ich 3.879 durch 3.932 teile und mit 100 multipliziere. Die sich ergebenden 98,65 % können als kompaktes Ergebnislabel auf 99 % gerundet werden, sofern die Stichprobe sichtbar bleibt. Die Angabe des Nenners macht das Label überprüfbar.
Es wäre irreführend, dieses Verhältnis auf den gesamten Generierungslauf anzuwenden. Die früheren Cache-Schreibvorgänge sind Teil des Laufs, und das protokollierte Verhältnis betrifft Eingabe-Tokens und nicht jedes abgerechnete Token. Eine weiterreichende Behauptung würde eine umfassendere Messung erfordern.
Ebenso vermeide ich es, Wiederverwendung mit Latenzverbesserung gleichzusetzen. Die Cache-Belege stellen Lesevorgänge fest. Eine Latenzaussage braucht Timing-Messungen unter relevanten Bedingungen. Dieselbe Disziplin gilt für Aussagen über Durchsatz, Margen oder Kundeneinsparungen.
Die KI-Nutzung ist ein Betriebskostenfaktor in Launcherry. Caching kann diese Kosten beeinflussen, aber die Gesamtwirtschaftlichkeit hängt auch von den Preisen des Anbieters, der Ausgabegenerierung, der Anzahl der Aufrufe und dem Ausmaß der erforderlichen Reparaturen ab. Eine stark wiederverwendete Eingabe kann dennoch mit einem unbrauchbaren Ergebnis oder einer teuren Sequenz einhergehen.
Meine Abnahmeentscheidung hält daher Qualität und Wirtschaftlichkeit verbunden, aber getrennt gemessen. Die Ausgabebewertung beurteilt das Ergebnis (Deliverable). Die Produktionsnutzung stellt die in dieser Umgebung beobachteten Kosten und das Cache-Verhalten fest. Die Workflow-Architektur bestimmt, welche Arbeit geschieht und wie oft.
Für ein Produktteam, das eine Optimierung erwägt, würde ich mit einem vollständigen Nutzerergebnis und seinen tatsächlichen Nutzungsprotokollen beginnen. Wiederholte Arbeit lokalisieren, wiederverwendbaren Kontext identifizieren und die Wirkung einer begrenzten Änderung messen. Die ursprünglichen Qualitätsanforderungen bewahren, damit ein billigerer Lauf nicht einfach dadurch bestehen kann, dass er weniger nützliche Arbeit leistet.
Diese Untersuchung hat verändert, wie ich das Ergebnis beschreibe. Ich kann auf eine konkrete Diagnose, eine Korrektur des Anfragedesigns, Regressionsabdeckung und Live-Belege für Cache-Lesevorgänge verweisen. Ich kann diese beiden Aufrufe nicht verwenden, um eine universelle Einsparung zu belegen, und ich brauche diese größere Behauptung nicht, um den Wert der Arbeit zu erklären.
Ich möchte eine Betriebsannahme bis in das Anwendungsverhalten zurückverfolgen, sie testen und korrigieren können. Es verbindet die Konstruktion von KI-Workflows mit den Kosten der Product-Lieferung und hält die Belege zugleich verständlich.
Die Launcherry-Case-Study trägt das kompakte Ergebnis. Dieser Artikel bewahrt den dahinterstehenden Geltungsbereich. Bei einem anderen System würde ich dieselbe konkrete Frage stellen, bevor ich Caching als erfolgreich bezeichne: Welche späteren Aufrufe lasen gecachten Kontext, wie viel lasen sie, und was kostete der vollständige Lauf, um ein akzeptables Ergebnis zu erzielen?
Ursprünglich veröffentlicht auf ivanped.ai: Prompt caching in practice: Diagnosing writes without reuse. Mehr von meiner Arbeit: ivanped.ai
Mit Vorlagen kannst du schnell FAQs beantworten oder Snippets zur Wiederverwendung speichern.
Bist du sicher, dass du diesen Kommentar ausblenden möchtest? Er wird in deinem Beitrag ausgeblendet, bleibt aber über den Permalink des Kommentars sichtbar.
Für weitere Maßnahmen kannst du erwägen, diese Person zu blockieren und/oder Missbrauch zu melden.
Automatisch übersetzt. Das Original auf Englisch ist unten aufklappbar.
Original (Englisch) anzeigen
Posted on Oct 8 • Originally published at ivanped.ai
I found the caching problem in Launcherry's production usage records: repeated generation calls wrote prompt tokens to cache but read nothing back within the run. The Google Search copy bank and analysis records showed the same pattern. I needed to verify what later calls reused through the application, rather than rely on the fact that caching was configured.
I treated that as an operating question that needed evidence. The relevant outcome was whether later calls actually reused suitable context. A cache setting, a successful response or a lower estimate in a spreadsheet could not establish that behaviour.
The September 17 verification records the investigation and correction. In each of two later generation-repair calls, 3,879 of 3,932 input tokens were read from cache. That is 98.65%, rounded to 99%. The result describes prompt-token reuse in those measured calls, not a product-wide reuse rate or a 99% cost saving.
Generation and repair have a useful relationship for this investigation. They concern the same underlying work, while a repair asks for a specific correction. Some context can remain relevant across those calls; other parts need to change. The request design has to preserve the distinction.
I examined the behaviour through the application’s own adapter and the production provider path. The recorded probe compared requests that held relevant conditions steady with requests that changed them. That helped establish which changes interfered with reuse, rather than treating every cache miss as the same problem.
My starting point is the request the product actually sends. Two prompts that seem similar to a human can differ in ways that matter to the provider’s cache. The model, request configuration and surrounding adapter behaviour belong in the investigation alongside the written instructions.
Provider conditions also differ. OpenRouter’s prompt-caching documentation distinguishes cached-token reads from cache writes and describes provider-specific behaviour. I use that documentation to frame a check, then rely on the application’s measured response to establish its result.
I directed a correction to the generation request design so repeated repair work could reuse its shared context. The work retained the generation requirements and validation responsibilities. Reuse needed to support the product’s existing job, rather than become a reason to weaken its checks.
The implementation was accompanied by regression cases covering the relevant request behaviour and the relationship between draft and repair. Those checks provide repeatable evidence about how the application constructs its work. A live rerun then provided the evidence about cache reads.
I keep those checks separate. A unit test can establish the application’s request structure under its test conditions. It cannot prove that a remote provider returned a cache hit. Conversely, one provider hit cannot establish that all the surrounding application paths remain correct. The investigation needed both kinds of evidence.
The recorded rerun includes preparation calls before the two successful repair reads. Those earlier calls wrote cache entries. Repairs 2 and 3 then each read 3,879 of 3,932 input tokens from cache and wrote no new cache tokens. The numerator and denominator belong to each of those calls.
I calculate the ratio by dividing 3,879 by 3,932 and multiplying by 100. The resulting 98.65% can be rounded to 99% for a compact outcome label, provided the sample stays visible. Reporting the denominator makes the label inspectable.
It would be misleading to apply that ratio to the whole generation run. The earlier cache writes are part of the run, and the recorded ratio concerns input tokens rather than every billed token. A broader claim would require broader measurement.
I also avoid equating reuse with latency improvement. The cache evidence establishes reads. A latency claim needs timing measurements under relevant conditions. The same discipline applies to claims about throughput, margins or customer savings.
AI usage is an operating cost in Launcherry. Caching can affect that cost, but total economics also depend on the provider’s rates, output generation, the number of calls and the amount of repair required. A highly reused input can still accompany an unhelpful result or an expensive sequence.
My acceptance decision therefore keeps quality and economics connected but separately measured. Output evaluation assesses the deliverable. Production usage establishes the cost and cache behaviour observed in that environment. The workflow architecture determines which work happens and how often.
For a product team considering optimisation, I would begin with a complete user outcome and its actual usage records. Locate repeated work, identify reusable context and measure the effect of a bounded change. Preserve the original quality requirements so a cheaper run cannot pass simply by doing less useful work.
This investigation changed how I describe the result. I can point to a specific diagnosis, a request-design correction, regression coverage and live cache-read evidence. I cannot use those two calls to establish a universal saving, and I do not need that larger claim to explain the value of the work.
I want to be able to trace an operating assumption into application behaviour, test it and correct it. It connects AI workflow construction to the cost of delivering the product, while keeping the evidence understandable.
The Launcherry case study carries the compact outcome. This article preserves the scope behind it. For another system, I would ask the same concrete question before calling caching successful: which later calls read cached context, how much did they read and what did the complete run cost to produce an acceptable result?
Originally published at ivanped.ai: Prompt caching in practice: Diagnosing writes without reuse. More of my work: ivanped.ai