agentic.dev

LLM Cost Optimization: Token Budgets, Caching and Model Selection

Published 2026-02-21

LLM Cost Optimization: Token Budgets, Caching and Model Selection

In the early days of generative AI, we were just happy if the model didn't hallucinate a legal defense. By 2024, we were obsessed with RAG and vector databases. But here in 2026, the conversation has shifted from "Can it do the job?" to "Can we afford to let it do the job at scale?"

As we build increasingly autonomous agentic systems-systems that run 24/7, monitor streams, and interact with other agents-the "API bill shock" has become the number one killer of AI startups. I’ve seen production agents rack up $5,000 in costs over a weekend because of a poorly constrained recursive loop.

If you’re building for the 2026 ecosystem, cost optimization isn't just a "nice-to-have" for the finance team; it is a core architectural requirement. In this guide, I’ll break down how we handle model routing, prompt caching, and token budgeting at the infrastructure level.

1. The Multi-Tier Model Strategy: Stop Using "Frontier" Models for Everything

The biggest mistake I see engineering teams make is "Model Monoculture." They pick the smartest model available-say, GPT-5 or Claude 4 Opus-and use it for every single task, from complex architectural reasoning to simple JSON formatting.

In 2026, high-performance agents use a Tiered Routing Architecture.

The Three-Tier Hierarchy

  • Tier 1: The Router/Classifier (Small & Local). We use 8B or 14B parameter models (like Llama 4 or Phi-4) running locally on an H100 or via a cheap serverless provider. Their only job is to look at the incoming task and decide which model is needed.
  • Tier 2: The Worker (Mid-range). Models like GPT-4o-mini or Claude Haiku. These handle 80% of agentic tasks: summarizing, data extraction, and basic tool calling.
  • Tier 3: The Reasoner (Frontier). Models with massive "Chain of Thought" capabilities (like the OpenAI o1-series or specialized reasoning models). These are 20x the cost and should only be invoked for logic-heavy tasks, code architecture, or conflict resolution.
  • Example Scenario: If an agent needs to "Read 50 emails and flag the ones needing urgent action," don't send all 50 to a frontier model. Use a Tier 1 model to filter out the spam, a Tier 2 model to summarize the remaining 10, and only if an email is "Critical," send it to the Tier 3 Reasoner to draft a response. This reduces costs by roughly 85% without sacrificing quality.

    2. Leveraging Prompt Caching (The 2026 Standard)

    If you aren't leveraging prompt caching, you are literally burning money. Most major providers now support some form of KV (Key-Value) cache reuse. The concept is simple: if the beginning of your prompt is identical to a previous request, the provider charges you a significantly lower rate (often 90% less) for those "cached" tokens.

    For agentic systems, this is a game-changer because agents usually have massive "System Prompts" or "Tool Definitions" that stay the same across thousands of calls.

    Implementing a Cache-Friendly Prompt

    To maximize hits, you must keep your prompt structure static. Place the most dynamic content (the user query) at the very end of the message.
    # Example of a Cache-Optimized Request (Pseudo-code for 2026 SDKs)
    import agentic_sdk as ai
    

    system_instructions = load_massive_policy_doc() # 5,000 tokens

    def run_agent_task(user_input): response = ai.chat.complete( model="claude-4-sonnet", messages=[ { "role": "system", "content": system_instructions, "cache_control": {"type": "ephemeral"} # Signals the provider to cache this }, { "role": "user", "content": user_input } ], # By putting user_input last, the system_instructions # remain a 'prefix' that hits the cache every time. ) return response

    The Tradeoff: Caching usually requires a minimum prefix length (e.g., 1024 tokens). If your prompts are tiny, caching won't help. But for agents with complex toolsets or RAG-heavy contexts, the savings are astronomical.

    3. Strict Token Budgets and Context Pruning

    In 2026, models have context windows of 2 million tokens or more. This has made developers lazy. Just because you can stuff 50 PDFs into a prompt doesn't mean you should.

    Every token has a cost, and more importantly, "Lost in the Middle" syndrome still exists. Even the best models lose reasoning accuracy as the context bloat increases.

    The "Token Budget" Middleware

    We implement a middleware layer in our agentic loops that enforces a strict budget. If an agent tries to pull in too much data from a vector search, the middleware forces a summarization step first.

    The Cost of "Reasoning Tokens"

    Newer "Reasoning" models (like o1) generate internal "thought" tokens. You are billed for these, even if they aren't visible in the final output. When using these models, you must set a max_completion_tokens limit that includes these hidden thoughts. Without this, a model might "overthink" a simple problem, spending $0.50 on a query that should have cost $0.01.

    4. The Hidden Costs: Retries, Evals, and Latency

    Cost optimization isn't just about the price per token; it's about the Cost Per Successful Task (CPST).

    If a cheap model has a 60% success rate and requires 3 retries, and an expensive model has a 95% success rate on the first try, the "expensive" model is actually cheaper.

    The Math of Retries

    Let's look at a real-world comparison for a complex data extraction task:
  • Model A (Cheap): $0.10 / 1M tokens. Success rate: 50%.
  • Model B (Frontier): $10.00 / 1M tokens. Success rate: 98%.
  • At first glance, Model A is 100x cheaper. But if Model A fails, your agent enters a "Correction Loop" where it sends the error message back to the model. Each retry consumes more tokens. After 3 retries, Model A has not only cost you more in compute but has also introduced 30 seconds of latency, potentially timing out your user's