Cut AI Coding Agent Costs: Fix Context Before You Change Models

Reducing AI coding agent costs starts with controlling context growth, not switching to cheaper models. Agentic sessions resend accumulated files, tool results and history on every turn, so cost grows roughly quadratically with session length. Ending sessions after one task, isolating unnecessary reads into subagents, and maximising cache reuse cut spend before any model change matters.

My inference bill last month was large enough to require an explanation, and the cause looked obvious: I had run one expensive model for everything. So the fix looked obvious too. Route the cheap work to a cheap model, keep the frontier model for the hard parts, save two thirds.

That instinct is wrong, or more precisely it is third in line. Model selection turns out to be a smaller lever than two things nobody talks about, both of which are free and work with whatever model you are already using.

This piece assumes you can already see what is happening in your own sessions, cache hit rate, input to output ratio, which turn made a session expensive. If you cannot yet, the companion piece, Instrumenting OpenCode And Claude Code, covers exactly that, and is worth reading first.

1. What Actually Happened To The Money

A conversational request costs you one prompt and one response. An agentic session does not. At every turn, whatever is still active in the conversation gets resent: system prompt, tool definitions, and whichever files, tool results and prior exchanges have not yet been pruned or compacted out. Turn twenty pays for everything from turns one through nineteen that is still sitting in the context.

Split the context into two parts: a fixed prefix, roughly constant turn to turn, and a growing tail made of everything the session has accumulated. The fixed part costs you N times its size over N turns, which is linear and unremarkable. The growing part is what compounds: if it grows by roughly a fixed amount each turn, the tokens you pay for it across the session approach the order of N squared, not N. That distinction is what explains an uncomfortable invoice better than any model price comparison does.

Concretely: your agent reads a 20,000 token file on turn three of a forty turn session. You spent 20,000 tokens on turn three, and then again on each of the remaining thirty seven turns, roughly 760,000 input token appearances for one file read, before any pruning or compaction intervenes. That is a volume figure, not yet a dollar figure. Caching discounts a repeated prefix heavily, Anthropic and most providers price a cache read at a small fraction of standard input, so the invoice does not grow as fast as the raw token count does. What caching cannot do is make the volume smaller, and volume is what determines how much of your bill is even eligible for that discount in the first place, which is why the distinction matters practically rather than just academically.

Two consequences follow. First, input dominates. An input to output ratio of thirty or fifty to one is common in coding workloads, so your bill is mostly tokens you are resending, not tokens the model is generating. Second, the expensive decision is what enters the context, not which model reads it. A cheap model reading the wrong forty files is worse than an expensive model reading the right four, because anything retained keeps contributing to every subsequent request until pruned, compacted, or the session ends.

Model routing addresses the rate. Context discipline addresses the quantity. The quantity term is bigger, and it is the one you control for free. Which points at something worth stating plainly this early rather than only at the end: an agent’s real economic unit is not a model call, it is a token carried across calls, and almost everything below follows from taking that literally.

2. The Shape Of The Fix

Four increasingly powerful things you can do with a token that would otherwise sit in your context:

1. Carry it. Resend it every turn at the standard rate. The default, and the expensive option.
2. Cache it. Resend it at a discounted rate, because the provider recognises the prefix. Cheaper, same token, still there.
3. Isolate it. Let something read it without that something being your main context, typically an isolated subagent. The token still gets read. It just never enters the context that gets billed to you forty times over.
4. Eliminate it. Never read it at all, because the task never needed it. A file nobody had to open costs nothing, in any tier.

Caching makes carried context cheaper. Isolation stops that context being carried at all. Elimination means there was never anything to carry. Each move is categorically better than the one before it. Isolation is why context isolation, not model routing, is the strongest lever most people actually reach for in this article. Elimination is cheaper still, and it costs nothing but the discipline of asking, before any file gets opened, whether the task actually needed it.

One principle falls out of this and is worth stating alone: cacheability is not a justification for context. Cached junk is still junk, and the model still reads and reasons over it every turn. Eliminate unnecessary context first, then isolate what cannot be eliminated, then maximise cache reuse for whatever needs to remain.

The real hierarchy is do not read what you do not need, then isolate what must be explored, then cache what must remain, then route what is left to a cheaper model. That is not the order this article covers the levers in, deliberately. Session hygiene and cache topology come first because they cost nothing and take minutes; do the free things first regardless of rank, build the more powerful thing once the easy wins are banked.

3. Lever One: Session Hygiene, And The Real Cost Of Auto Compaction

The N squared term means session length is the dominant driver of context volume. Doubling a session from twenty to forty turns roughly quadruples the cumulative growing context processed across the whole session, assuming context accumulates at a similar rate each turn, even though the context present at turn forty itself is only about twice what it was at turn twenty. It is the cumulative total, not the instantaneous size, that the bill tracks. Whether that translates into four times the invoice depends on how much of it was cached, which is exactly why the two levers that follow, ending sessions and caching properly, both attack the same underlying quantity from different sides.

So the highest value change available costs nothing and involves no model: one task per session, ended deliberately. Write a short handoff, start a new session, paste the handoff. The new session begins small instead of inheriting forty turns of noise that will be resent on every future turn. This is the single largest saving in this article, and it also produces better output, because an abandoned context degrades reasoning as well as costing money.

Compaction is a trade, not a mistake, and it does not automatically forfeit your cache the way it might look like it should. Anthropic’s own account of how Claude Code implements this is worth knowing, because it corrects an assumption that is easy to make and wrong: the summarisation call itself is built as a fork that inherits the parent conversation’s system prompt, tools and prior messages under identical cache safe parameters, so that call reads the parent’s cached prefix rather than paying full price to summarise it. What genuinely changes is the conversational history itself, which is now a summary rather than the original turns, and that new shape has to establish its own cache going forward. So the honest description is narrower than either extreme: compaction is not free, because the new history is a fresh prefix that takes a turn or two to warm up again, and it is not a cache destroying event either, provided it is implemented as a cache safe fork rather than a naive separate call with a different system prompt. Whether your particular tool does the former or the latter is worth checking rather than assuming, since a naive implementation really does pay full price for the entire conversation just to produce the summary.

The honest comparison is compaction against ending the session, not compaction against doing nothing. Ending the session gives you a deliberately small context, and a written artefact whose contents you chose rather than one a machine summarised for you, which is deliberate selection rather than an absence of information loss; you are still discarding something, just on purpose and by your own judgement about what matters. Prefer the explicit end with a handoff over automatic compaction where that choice exists. Do not treat a higher compaction threshold as the fix, since that mostly leaves a large context alive for longer and can increase the cumulative total rather than reduce it. Terminate healthy task boundaries yourself, and leave compaction as the emergency mechanism for the sessions that genuinely have to continue past one.

4. Lever Two: Prompt Caching For Agentic Coding

If input is ninety plus percent of your tokens and cached input bills at a fraction of standard input, your cache hit rate is the second largest number in your bill. Discounts vary widely by model and provider, sometimes five to ten times, so check your current rate card rather than assuming a figure.

Caching is prefix based. Only the longest matching prefix counts, and everything after the first difference bills at the standard rate. One design rule governs everything: nothing that changes may appear before anything that does not. The usual failures are structural, not accidental:

1. Dynamic content at the top of the prompt. A timestamp, a branch name, a session id in the system prompt. Invalidates the entire cache on every call, invisibly.
2. Reordered tool definitions. If assembled from a map or a set, order may vary between calls. Sort it.
3. Editing history. Any mutation of an earlier message, including compaction, throws away the prefix.
4. Time gaps. Serverless caches are best effort and short lived. A long break mid session may cost you the cache. Work in bursts.

Layout, top to bottom: static system instructions, tool schemas, project conventions, stable repository context, the conversation, the current request last. One caution tying back to section 2: cacheability is not a justification for including the content in the first place. A hundred thousand token repository description is not a good idea because it is cheap to resend; eliminate first, then cache what remains.

Dedicated inference capacity, billed per hour rather than per token, is worth modelling if you have sustained load, but do the arithmetic with a live quote rather than a number from an article, since GPU rental rates move by the week and span a real range depending on the exact commitment.

5. Lever Three: Context Isolation With Subagents

Now, and only now, more than one model, and the first reason to do it is not price. Delegating exploration to a subagent removes tokens from your expensive context permanently: it reads thirty files in its own context, returns four hundred words, and its context is discarded. Those files are never resent, on any subsequent turn, ever. Caching makes carried context cheaper. Isolation stops that context being carried at all, which is why this lever outranks model selection.

The read tax on a file entering your main context is roughly its size multiplied by the turns remaining in the session. Isolation reduces that multiplier to one.

Three delegations to build, in order:

1. Explorer. Reads broadly, returns a short structured finding with evidence. Read only, no write access. The highest value delegation in any setup, and cost is a side benefit.
2. Triage. Test failures, build errors, log analysis. High volume, structured output, trivially verifiable.
3. Test author. Writes tests from a specification and an interface, forbidden from reading the implementation. Not really a cost optimisation: an agent that read the code writes tests confirming what it does, one that only saw the interface writes tests checking what it should do, and the second is far more likely to catch a bug the first would rationalise away.

The subagent cannot see your conversation, so everything it needs must be in the brief: goal, inputs, constraints, acceptance criteria, output shape, forbidden actions, and a condition under which it must stop and hand back rather than guess. That last field is the one everybody omits, and the one that prevents the expensive failures.

6. Lever Four: Reasoning Effort Before Model Tier

Reasoning tokens are generally billed as output tokens, and on many frontier APIs output tokens cost several times more than input, so check your specific rate card rather than assuming a fixed ratio. Most agentic turns do not need the top effort setting. Dropping effort is a smaller intervention than dropping model tier and preserves the model’s world knowledge, which is usually what you actually needed. Move along the effort axis before the model axis: default to the lowest effort that passes your gates, escalate effort on failure before escalating model, and treat a second failure at the same step as a sign the brief is wrong rather than the model being weak. Set effort per role rather than per session so it happens automatically.

7. Lever Five: The Model Ladder

The mistake is thinking of this as two tiers, expensive and cheap. It is four, drawn by what happens when the work is wrong rather than by how hard it is:

Work whose failure a test suite catches for free can run on the cheapest model that produces parseable output. Work whose failure shows up three weeks later as a design problem stays on the frontier model.

Every open weight rate quoted anywhere reprices monthly. Roughly, exploration and extraction sit at the very cheap end, bulk code generation from a clear spec a step up, independent review one step further because it needs a different model family than the one that wrote the code, and one tier below frontier for the heaviest lift you would still rather not pay frontier rates for. Use a different family for review specifically, not to save money: a reviewer from the same family may share more of the author’s blind spots, while a different one is more likely to reduce correlated mistakes. And test whether frontier is really needed on your own repository rather than trusting a leaderboard, because the gap between frontier and the tier below it is now often large enough that assumed necessity does not survive the test.

8. Setting Up A Zero Metered Inference Cost Worker Tier On Your MacBook

Section 7 priced the worker tier in cents per million tokens. There is a cheaper number than that on hardware you likely already have open in front of you: no per token charge at all, since the only ongoing cost is electricity and whatever you already paid for the laptop.

Apple Silicon’s unified memory means the GPU reads model weights straight out of the same memory pool the rest of macOS uses, which is why a MacBook with enough of it comfortably runs models that would need a dedicated GPU elsewhere. This is a real worker tier, not a toy, provided you match the model to the memory you actually have rather than the biggest one you can find a benchmark for.

Install and pull a model:

brew install ollama
ollama pull qwen3-coder:30b

Ollama runs as a background service after install and uses Metal acceleration automatically, nothing to configure. Keep it updated with brew upgrade ollama; recent versions added a faster backend on machines with enough memory, and updating is the entire cost of getting it.

Pick the model by unified memory rather than by reputation:

Two things worth fixing before you trust it with anything. First, do not trust the default context allocation. Current Ollama sizes it from available VRAM rather than a fixed number, roughly 4K under 24GB, 32K from 24 to 48GB, and up to 256K above that, and different pages in Ollama’s own documentation disagree about which of these is current, so the only reliable check is your own running server rather than any number in an article. What does not move is the practical conclusion: a system prompt, a set of tool definitions and one file read will exceed the bottom tier almost immediately in an agentic session, at which point Ollama truncates silently rather than warning you, and OpenCode’s own integration guidance calls for 64K tokens or more regardless of what the default happened to size itself to on your machine. Set it explicitly rather than trust the tier you landed on:

cat <<'EOF' > Modelfile
FROM qwen3-coder:30b
PARAMETER num_ctx 65536
EOF
ollama create qwen3-coder-64k -f Modelfile

The KV cache scales with context length, so doubling num_ctx roughly doubles the memory that context alone needs on top of the model weights; 64K is feasible for a 30B model of this kind on 32GB and above, but comfortable depends on your specific hardware and what else is running, so verify available memory and offloading before going further, and remember this model’s native window is 256K, so there is room to grow into if you later find 64K too tight.

Second, confirm tool calling actually round trips before you route any delegated work to it, the same caution that applies to any local endpoint. A model that answers plain questions correctly can still mangle a tool call. Write the request body to a file first, since a long inline JSON string is exactly the kind of thing that gets mangled in copying:

echo '{"model":"qwen3-coder-64k","messages":[{"role":"user","content":"read the file test.py"}],"tools":[{"type":"function","function":{"name":"read_file","description":"Read a file","parameters":{"type":"object","required":["path"],"properties":{"path":{"type":"string"}}}}}]}' > tool-test.json

Then send it:

If the response comes back with a populated tool_calls field rather than plain text, it works. If it does not, drop to a smaller model in the same family before assuming the whole approach is broken.

Wire it into the same routing config from section 11 by adding one more provider alongside Together, then pointing the cheapest roles at it:

{
  "provider": {
    "ollama": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "Ollama (local)",
      "options": { "baseURL": "http://localhost:11434/v1" },
      "models": { "qwen3-coder-64k": { "name": "Qwen3 Coder (local)" } }
    }
  },
  "agent": {
    "explorer": { "mode": "subagent", "model": "ollama/qwen3-coder-64k" },
    "triage":   { "mode": "subagent", "model": "ollama/qwen3-coder-64k" }
  }
}

One caution before you rely on this for a full working day. Ollama unloads an idle model from memory after a period of inactivity by default, which is the right behaviour on a laptop you also use for other things, but it means the first request after a gap pays a cold load. If you are routing to it constantly through the day, set OLLAMA_KEEP_ALIVE to a longer duration so it stays resident, and accept the memory it holds in exchange.

None of this replaces Together for the tiers above worker, and it will not touch frontier work at all. What it does is take the two cheapest, highest volume roles in the ladder, explorer and triage, off the metered bill entirely, for the cost of electricity and whatever you already paid for the laptop.

9. Lever Six: The Tier That Costs Nothing

Every model call for something a program could have decided is pure waste. Formatting, import sorting, type checking, linting, mechanical renames, structural search and replace: codemod tools do this faster, deterministically, and for free, and an abstract syntax tree based rewrite does not hallucinate.

Rule for review: if a deterministic tool can decide it, no model gets asked. Every deterministic gate you add also makes cheap model errors cheaper to catch, which moves the tier boundary in section 7 downward and lets more work run safely on the worker tier.

10. Lever Seven: Batch The Asynchronous Work

Together documents batch processing at up to a 50 percent discount for suitable asynchronous workloads, not a universal half price rate. A large share of what a coding agent does has no interactive requirement: test scaffolding on modules you are not currently editing, backlog triage, documentation generation, migration sweeps, repository wide analysis. Take those out of the interactive loop and queue them. This is one of the few savings with no quality cost and no judgement required, only the habit of not watching every task happen live.

11. Making Model Routing Automatic

Manual model switching does not survive a busy week, so this section is the load bearing one. Four mechanisms, none of which is a classifier.

11.1 The Role Is The Router

The temptation is to build a classifier in front of your requests that predicts which model each request needs. Do not. A classifier has to decide before the work starts, when it knows least, and the cost of misrouting is asymmetric: routing easy work to an expensive model wastes cents, while routing hard work to a cheap model produces a confident wrong answer that propagates through eight more tool calls.

Instead, define roles with models pinned to them, and let the orchestrator select roles. It picks a subagent by reading its description, exactly the way it picks a tool, and it makes that choice with full task context at the moment the work is understood. You have moved the routing decision to design time, where you can reason about it, and the runtime selection is done by the component best placed to make it.

Concretely, five or six roles, each pinned. Keep the descriptions sharply non overlapping, because overlapping descriptions cause misrouting that is genuinely hard to debug.

{
  "model": "frontier/architect-tier",
  "small_model": "together/deepseek-v4-flash",

  "agent": {
    "plan":  { "mode": "primary", "model": "frontier/architect-tier",
               "permission": { "edit": "deny", "bash": "deny" } },
    "build": { "mode": "primary", "model": "frontier/architect-tier",
               "permission": { "edit": "allow" } },

    "explorer":    { "mode": "subagent", "model": "together/deepseek-v4-flash",
                     "permission": { "write": "deny", "edit": "deny" } },
    "triage":      { "mode": "subagent", "model": "together/deepseek-v4-flash" },
    "test-author": { "mode": "subagent", "model": "together/gpt-oss-120b" },
    "refactorer":  { "mode": "subagent", "model": "together/minimax-m2-7" },
    "reviewer":    { "mode": "subagent", "model": "together/glm-5-2",
                     "permission": { "write": "deny", "edit": "deny" } }
  }
}

Use permission rather than the older tools boolean block for restricting an agent. The boolean form still works for backward compatibility, but it is deprecated in current OpenCode, and permission is also what lets you distinguish allow, ask and deny rather than a flat on or off.

One detail that catches everybody: in most harnesses a subagent with no model specified inherits the model of the agent that invoked it. Leave that alone and your explorer runs on your frontier model and you have built an elaborate delegation architecture that saves nothing. Pin every single worker explicitly.

One further caveat on permission, worth knowing before you rely on it as a hard boundary: there have been reports of agent level deny rules being ignored when a custom agent is invoked through the SDK rather than the interactive session. Treat permission: deny as a strong default rather than a guaranteed one, and for anything that must never be bypassed, prefer the plugin level hook in section 12, which throws in process rather than relying on a permission check.

11.2 Pin The Invisible Traffic

Session titles, summarisation, compaction calls, commit message generation. This traffic is invisible in the interface and visible in the invoice. Pin it to your cheapest tier deliberately, because the default behaviour is to reach for something convenient rather than something you chose, and in at least one harness that default has been observed routing to the vendor’s own hosted provider, which is a data flow question as well as a cost one.

11.3 Downward Fallback Only

Configure your gateway so that failover never escalates a tier. Falling back from a busy worker endpoint to another worker endpoint is correct. Falling back from a worker to the frontier model because the worker timed out is how a cost optimisation becomes an invoice incident, and it also destroys your ability to measure whether the worker tier is doing its job. Escalation must be an explicit decision by the orchestrator, recorded as such.

router_settings:
  routing_strategy: least-busy
  fallbacks:
    - worker-primary: [worker-secondary]     # sideways
  # deliberately no architect tier in any fallback list
  allowed_fails: 2
  cooldown_time: 60

# hard stops, per consumer
budgets:
  - key_alias: dev-primary
    max_budget: 400
    budget_duration: 30d
  - key_alias: ci-pipeline
    max_budget: 200
    budget_duration: 30d

11.4 Hard Caps, Not Alerts

Per developer and per pipeline monthly caps enforced at the gateway. Not a notification, a refusal. Alerts get muted and the thing you want is to discover the problem on the day it starts rather than at month end. Cap the retry ladder too, at three attempts and then a human, because unbounded retry is silent and every individual call looks cheap.

12. Enforce It Rather Than Remember It

Everything in sections 4 to 6 was described as a discipline, and disciplines decay in about a week. The three largest levers are the ones most vulnerable to this, because they are habits rather than settings. So convert them into configuration that refuses.

Make oversized reads impossible in the primary agent. The tool.execute.before hook can throw, and a thrown error blocks the call. Once a large read fails in your main context, delegating to the explorer stops being a good practice and becomes the only path that works:

// .opencode/plugins/read-guard.js
import { statSync } from "node:fs"

const MAX_BYTES = 48_000   // roughly 12,000 tokens

export const ReadGuard = async () => ({
  "tool.execute.before": async (input, output) => {
    if (input.tool !== "read") return
    const path = output.args.filePath
    let size = 0
    try { size = statSync(path).size } catch { return }
    if (size > MAX_BYTES) {
      throw new Error(
        `${path} is ${size} bytes and will stay in context for the rest of ` +
        `this session. Delegate this read to the explorer subagent, or read ` +
        `a specific line range.`
      )
    }
  },
})

Note the error message does the teaching. A refusal that explains the alternative changes behaviour; a refusal that just fails trains people to work around it. Scope this to your primary agents once you have confirmed how agent identity surfaces in the hook input on your version, otherwise the explorer will block itself.

Take control of compaction. The experimental.session.compacting hook fires before the continuation summary is generated, and it lets you inject context or replace the prompt entirely. Two good uses. Either force the summary into the handoff format you want, so that ending the session and restarting is cheap and lossless, or use the hook to write that handoff to a file and then end the session yourself rather than compacting at all. Section 4 covers when compaction is genuinely cache safe and when it is not; if you are not confident your tool implements the cache safe version, the second option removes the question entirely rather than betting on it.

Turn the alarms from your own per turn ledger into refusals once you trust them. Run them as warnings for a fortnight, check the false positive rate, then promote the ones that were always right into thrown errors. A session cost ceiling that stops work is more useful than one that sends a notification, because notifications get muted and the cost is already spent by the time you read one.

Treat cache hit rate as an error rate, not a metric. Alert on it dropping rather than reviewing it monthly. A sudden fall means somebody put something dynamic near the top of a prompt, and the gap between that change and somebody noticing is pure loss.

The general principle: every lever in this article that depends on a human remembering something should end up as either a hook that refuses, a pinned default in configuration, or an alarm that fires on the turn it happens. Anything that stays as advice will be gone by the end of the month.

13. The Waterfall

Applied in order, with illustrative multipliers rather than measurements, since the real numbers depend on the five diagnostics from the companion piece on observability:

Note the word illustrative: these are my own multipliers, not a benchmark. Steps one and two are free and, between them, do more than the model ladder alone. That is why context comes before the model in the ordering of this whole piece, model routing included, not excluded. The frontier model is still doing all the architecture and escalation work at the bottom of that table; you have not traded capability for cost, you have stopped paying frontier rates to resend a file forty times.

14. What This Actually Costs You

Reliability per step compounds. A model that is ninety percent reliable per step is much worse than ninety percent reliable over a twenty step task. Cheap tiers belong where a gate catches the error; push work down a tier without one and you pay for it in retries and in the specific failure of an agent proceeding confidently down the wrong path.

Retries can erase the saving. Three cheap attempts plus an escalation plus orchestrator overhead can exceed doing it once at the top tier, which is why you measure cost per accepted unit of work rather than cost per token.

Delegation has a specification tax. Every brief is written from scratch because the worker cannot see your conversation. For genuinely small tasks the tax exceeds the benefit, so do not delegate everything; the threshold is roughly whether the worker reads more than it writes.

More providers means more operational surface. Model identifiers that change without notice, a gateway to keep running, tool calling behaviour that varies subtly between endpoints. Start with one additional provider, not five.

15. The Part That Generalises

The bill was not high because the model was expensive. It was high because a long lived context is a liability that gets revalued on every turn, and nothing in the interface tells you that.

We tend to optimise the unit price of the thing on the invoice and ignore the quantity, because the unit price is visible and the quantity is emergent. Get the context accounting right first. Then the model ladder is a straightforward optimisation on a much smaller number, and a provider like Together becomes what it should be, a set of well priced tiers you allocate work to deliberately, rather than a cheaper place to make the same mistake.

If there is a single sentence worth keeping, it is the hierarchy from section 2: eliminate, then isolate what you cannot eliminate, then cache what you cannot isolate, and only then route what remains to a cheaper model. An agent’s real economic unit is not a model call. It is a token carried across calls, and the size of your bill is mostly a question of how many times you paid for the same one.

16. Sources

Prices and product behaviour move monthly. Verify everything before committing.

1. Together AI pricing documentation, covering automatic prefix caching, dedicated endpoint caching, and the batch discount: https://docs.together.ai/docs/inference/pricing
2. Together AI live rate card and pricing calculator: https://www.together.ai/pricing
3. Cross provider prompt caching comparison and cache hit discount methodology: https://artificialanalysis.ai/models/caching
4. Together AI pricing analysis including cached input multiples and dedicated endpoint arithmetic: https://www.eesel.ai/blog/together-ai-pricing
5. OpenCode agents, model pinning and subagent inheritance: https://opencode.ai/docs/agents/
6. OpenCode configuration, including the small model setting: https://opencode.ai/docs/config/
7. Anthropic, on how Claude Code implements cache safe forking for compaction and other side calls: https://claude.com/blog/lessons-from-building-claude-code-prompt-caching-is-everything
8. Claude Code documentation on prompt caching mechanics: https://code.claude.com/docs/en/prompt-caching
9. OpenCode’s Ollama integration guidance on required context length, and the tradeoffs in practice: https://localaimaster.com/blog/opencode-ollama-setup