<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Cost on PG Blog</title><link>https://pg-blogs.netlify.app/tags/cost/</link><description>Recent content in Cost on PG Blog</description><generator>Hugo</generator><language>en-us</language><lastBuildDate>Sat, 04 Jul 2026 00:00:00 +0000</lastBuildDate><atom:link href="https://pg-blogs.netlify.app/tags/cost/index.xml" rel="self" type="application/rss+xml"/><item><title>Prompt Caching and Cost Control in Java</title><link>https://pg-blogs.netlify.app/posts/32-prompt-caching-and-cost-control-in-java/</link><pubDate>Sat, 04 Jul 2026 00:00:00 +0000</pubDate><guid>https://pg-blogs.netlify.app/posts/32-prompt-caching-and-cost-control-in-java/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;We already covered picking the right model tier for the task and caching a large shared prefix in https://pg-blogs.netlify.app/posts/11-building-reliable-llm-apps-in-java/. Those two lines were the tip of a bigger discipline: &lt;strong&gt;LLM cost is not a fixed line item, it&amp;rsquo;s an engineering variable&lt;/strong&gt; — one you can measure and shrink with the same rigor you&amp;rsquo;d apply to database query time or container memory.&lt;/p&gt;
&lt;p&gt;This post goes deeper: how input/output pricing actually works, the exact &lt;code&gt;cache_control&lt;/code&gt; shape and how to &lt;em&gt;prove&lt;/em&gt; a cache hit rather than assume one, the Batches API for work that isn&amp;rsquo;t latency-sensitive, and model routing — using a cheap model to triage, escalating only the hard cases to a stronger one. The honest framing throughout: &lt;strong&gt;measure before you optimize.&lt;/strong&gt; Every technique here has a cost of its own; applied to the wrong workload, &amp;ldquo;optimization&amp;rdquo; makes things slower or more expensive.&lt;/p&gt;</description></item><item><title>Prompt Caching and Cost Control in Python</title><link>https://pg-blogs.netlify.app/posts/33-prompt-caching-and-cost-control-in-python/</link><pubDate>Sat, 04 Jul 2026 00:00:00 +0000</pubDate><guid>https://pg-blogs.netlify.app/posts/33-prompt-caching-and-cost-control-in-python/</guid><description>&lt;h2 id="introduction"&gt;Introduction&lt;/h2&gt;
&lt;p&gt;https://pg-blogs.netlify.app/posts/10-building-reliable-llm-apps-in-python/ closed with a section on picking the right model per task and caching a shared prefix. That was the entry point into a bigger discipline: &lt;strong&gt;LLM spend is an engineering variable, not a fixed bill&lt;/strong&gt; — one you can measure and reduce with the same rigor you&amp;rsquo;d apply to query latency or memory footprint.&lt;/p&gt;
&lt;p&gt;This post goes deeper on four levers: how input/output pricing actually works and why the &lt;em&gt;prefix&lt;/em&gt; is usually where the money goes, the exact &lt;code&gt;cache_control&lt;/code&gt; shape and how to prove a cache hit instead of assuming one, the Batches API for work that isn&amp;rsquo;t latency-sensitive, and model routing — a cheap model triaging requests and escalating only the hard ones. The throughline is honest: &lt;strong&gt;measure before you optimize.&lt;/strong&gt; Every lever here has its own cost; misapplied, it makes things slower or pricier, not cheaper.&lt;/p&gt;</description></item></channel></rss>