Dynamic Prompt Caching TTL Optimization: How to Cut Enterprise AI Spend with MDM

Introduction

After reading this blog post you’ll understand how you can leverage your existing tools used to manage corporate and BYOD devices, to reduce your AI bill.

While most of us have little to no control over the pricing schemas of the major AI labs (e.g. Anthropic) we can leverage several techniques to reduce the amount of tokens that we consume and lower the price we pay for the tokens that we cannot avoid.

Some techniques will bring modest savings for the individual developer, but the larger the organization is, the quicker these savings will compound and translate to meaningful, easy to measure amounts of money.

For any optimization to work it has to adhere to two principles:

• Frictionless - any optimization technique that negatively affects (or is perceived to affect) business users, whether they are developers or non technical workers, is unlikely to succeed due to stakeholder resistance. That is true irrespective of how ingenious the technique is.
• Automated - Tools that only generate reports and recommendations often go unused.

One low-hanging fruit when it comes to automation is using infrastructure that the organization already has in place. In this post we’ll explore a popular MDM solution - Microsoft Intune.

The Optimization Loop

In this article we’ll use Claude Code as our coding agent, but similar logic can be applied to multiple combinations of agents and LLMs.

There are 3 steps that we need to follow - Inspect, Identify and Implement. Let’s dive deeper into each of these:

Inspect - prior to applying any optimizations we need to understand the consumption patterns of different individuals and autonomous agents. The same optimization technique applied to one developer / agent can save money, while increasing the bill if applied to a peer. We’ll review such an example later in this blog post.

Inspection can be done in different ways (e.g. a gateway that intercepts the connection between the agent and the LLM, a piece of software installed on each endpoint, etc.).

I tend to favor low friction non-invasive techniques that do not require you to install anything on your endpoints. In the case of Claude Code you can leverage its ability to send Open Telemetry (OTEL), which can include metadata about the interaction between the agent and the LLM, as well as the actual prompts and responses. What to send is controlled via a configuration parameter.

Identify - Analyze the interactions between the agent and the LLM, and identify savings opportunities. For instance you can dynamically adjust the prompt caching Time to Live (TTL) value based on actual usage patterns, set default model value - e.g., use Sonnet by default and manually switch to Opus / Fable only when needed, and a lot more.

We will cover prompt caching in detail in this blog post and address other techniques in future posts.

Implement - that’s where the MDM part comes into play. Instead of having to install new software on your endpoints, you can use your existing IT infrastructure and dynamically modify environment variables and other settings to reduce the AI bill.

Example

In this blog post we’ll review one optimization technique in depth - prompt caching TTL (time to live).

If you are not familiar with prompt caching and why the TTL value matters, please watch this 11 min long video where I explain the concept.

Anthropic exposes a configuration parameter that allows us to control for how long they should keep our cache alive, so that a large part of the input tokens included in subsequent prompts will be billed at a discounted rate (discount can reach up to 97.5% - source):

While it is tempting to go set the TTL to its maximum value and enjoy the discounted rate for longer, there is a catch. Writing to the longer cache is more expensive:

To maximize our savings we need to calculate whether the benefits provided by the cheaper read price outweigh the extra price of writing to the more expensive cache.

The challenge is that this calculation can produce different results for different individuals, and even for the same individual during different times.

Let’s consider a concrete example - two employees using Claude Code - John and Anna, where both have their cache TTL value set to 5 min (default for Claude Enterprise subscriptions):

While setting 1 hour for Anna makes sense, setting the same value for John would increase our price, as our cache hit rate will stay the same, but writing to the cache would become more expensive. Same optimization - different results.

Let’s review a simple example to illustrate the concept (token counts are illustrative and simplified):

• Model used: Claude Fable 5.1.
• Cache TTL value: 5 minutes.
• Model pricing (October 2026):

• 08:00am: John sends his first prompt, which has 100K tokens.
• As this is a new session, the cache is empty so all tokens are written to the 5 minute cache and we pay $1.25 for our 100K tokens.
• Claude returns a response, which has 100K tokens (output token prices are not affected by prompt caching).
• 08:02am: John sends his next prompt which has 100K tokens, which is appended on top of the previous prompt (100K tokens) and previous response from Claude (100K tokens) - sending 300K input tokens to the Anthropic API.
• As the first 100K tokens (John’s original prompt) is already cached, we’ll pay the discounted rate of $0.025 for them, and the 5m write price for the remaining 200K tokens - $2.5. Total cost of the interaction so far, excluding output tokens cost - $3.775 ($2.5 cache write cost + $0.025 read cost + $1.25 for the first prompt).

Assume that we’ll change the cache TTL to 1 hour - we’ll pay the 1 hour write price ($20 per million tokens) for the first prompt ($2 for 100K tokens) and $4 to write the second prompt to the cache (200K tokens). Total cost of the interaction so far, excluding output tokens cost = $6.025 ($6 cache write + $0.025 cache read).

The table below summarizes the difference:

Applying the 1 hour TTL optimization, which is likely to save money for Anna, will cost more money for John ($6.025 vs. $3.775).

Let’s apply the same example to Anna, considering her usage pattern:

• 08:00am: Anna sends her first prompt, which has 100K tokens.
• As this is a new session, the cache is empty so all tokens are written to the 5 minute cache and we pay $1.25 for our 100K tokens.
• Claude returns a response, which has 100K tokens (output token prices are not affected by prompt caching).
• 08:10am: Anna sends her next prompt which has 100K tokens, which is appended on top of the previous prompt (100K tokens) and previous response from Claude (100K tokens) - sending 300K input tokens to the Anthropic API.
• The cache has already expired (10 minutes gap between prompts vs. 5 min cache TTL). We pay the full 5 min cache write price for 300K tokens - $3.75. Total cost of the interaction so far, excluding output tokens cost - $5 ($3.75 for the second turn cache write + $1.25 for the first prompt).

Assume that we’ll change the cache TTL to 1 hour - we’ll pay the 1 hour write price ($20 per million tokens) for the first prompt ($2 for 100K tokens) and $4 to write the second prompt to the cache (200K tokens). We don’t need to write the first 100K tokens, as they were cached and the cache did not expire). Total cost of the interaction so far, excluding output tokens cost = $6.025 ($6 cache write + $0.025 cache read).

So far the 1 hour TTL is more expensive than the 5 min TTL ($6.025 input tokens cost vs. $5), but wait till the third prompt:

08:25am: Anna sends her third prompt (100K tokens), which is appended to the previous two prompts and their responses (400K tokens). We send 500K tokens to the Anthropic API, and as the cache has already expired we pay the full 5 min cache write price - $6.25. Total cost of the interaction so far, excluding output tokens - $11.25 USD ($6.25 current prompt + $5 from the previous prompts).

With a 1 hour TTL we would pay the 1 hour cache write price for the last prompt and previous response (200K tokens) - $4, where the previous 300K tokens would be charged at the cache read rate, which will be $0.075 for 300K token. Total cost of this prompt - $4.075. Total cost of the entire interaction - $10.10 ($4.075 current prompt + $6.025 from the previous prompts).The tables below summarize the difference:

As you can see above, after Anna’s third prompt, having the TTL set to 1 hour is saving money. The same value set for John, or for Anna when the sessions are short, is going to cost more money. That’s why dynamic per developer / agent optimizations are so valuable.

Using this knowledge we can now implement our optimization loop:

• Inspect John’s and Anna’s usage (e.g., parse Open Telemetry logs).
• Identify when there are cache misses, and whether changing the TTL will be beneficial.
• Implement the change per individual by adjusting relevant environment variables on their endpoint.
• Automate this by using your existing MDM, that can control environment variables and configuration files on managed endpoints.

How AgentDome can help

We’ve started AgentDome to provide the individualized optimization loop out of the box. Simply deploy a Docker container in your environment. Send Open Telemetry logs to it and let it constantly optimize your usage. Your sensitive data stays in your environment and is never shared with AgentDome.

The architecture will look similar to the one depicted below:

Watch a short demo where I’m joined by Jannik Reinhard, a Microsoft Intune MVP and Head of AI at Epic Fusion, where we walk through the unified solution together:

An interactive demo of the entire flow is available here.