A coding agent has no memory between turns. Each time it takes a step, the harness (the program that wraps the model, runs its tools, and builds every request) assembles a new request and sends all of it again: the system instructions, the definition of every tool, some setup text, and the whole conversation so far [1]. By turn 40 the model is reading the same opening for the 40th time. The provider bills for every read. Providers bill by the token, a chunk of text a bit shorter than an average word. So a long session costs far more than the new work inside it would suggest.
Cursor reports that changing how its harness builds that request cut token costs for its users by 7% without reducing agent quality [1]. The post never says whether the 7% counts tokens or dollars, and it gives no baseline or sample size, so we read it as one vendor’s self-report. The useful part is where the savings came from. A developer can inspect each source in a harness they control, and none of them swaps the main model.
Figure 1 - The same front half, sent again every turn: Each request repeats the instructions and tool definitions that came before it and adds the newest part of the conversation.
What one request is made of
Cursor lists the pieces of every request as tools, system instructions, setup, and the conversation so far [1]. The system instructions are the standing rules the harness gives the model. The tool definitions describe each tool: its name, the arguments it takes, and when to use it. The setup is context that depends on the user or the request, such as which skills (packaged instructions the agent can load) and subagents apply and what the working environment looks like. The conversation is everything said and done so far.
Much of the beginning stays the same from one turn to the next [1]. The setup is the exception. Part of it can differ per user or per request, and that matters later. Cursor calls the system prompt and tool definitions “one of the largest sources of spend that we fully control” [1].
Providers quote prices per MTok, which means per million tokens. Anthropic’s published rate for Opus 5.5 is $4 per MTok of input and $20 per MTok of output [2]. Now take an illustration, not a measurement. Say the unchanging front half of a request is 30,000 tokens and a session runs 50 turns, so the model reads that front half 50 times. That’s 1,500,000 tokens, or 1.5 MTok. At $4 per MTok, that’s $6.00 of input for text that never changed.
Figure 2 - What one request contains: 4 kinds of content sit in every request. Tool definitions and system instructions barely change from turn to turn. Setup can vary by user or request, and the conversation grows every turn.
The first thing most teams reach for is a cheaper model. It’s a reasonable move. We leave it alone on purpose. A cheaper model can cost the quality you chose your model for. Switch in the middle of a session and it can also throw away the stored copy of the front half that keeps long sessions affordable. So we hold the main model fixed and ask what the harness is sending. A cheaper model shows up in one place only: inside a subagent (a helper agent the main agent hands a side task), where the harness decides which model the helper uses.
Send less: trim the prompt and load tools on demand
Cursor’s first cut was to send less, starting with the system prompt. Back when its models were less capable, the prompt had to spell out how to use each tool. It also had to head off odd behavior such as long hash dumps, binary output, and emojis [1]. As models improved, long lists of “DO NOT do this” and “You must” instructions became unnecessary. Cursor could simply define how a tool behaves and the models generally complied. That held “across model families,” which let it trim roughly 66% of its system prompt [1].
Anthropic reports the same direction on its own product. It removed over 80% of Claude Code’s system prompt for Claude 5 generation models such as Opus 5 and Fable 5 with “no measurable loss on our coding evaluations” [3]. Those are Anthropic’s own internal evaluations. Each percentage is measured against a different prompt, so the two agree on direction and say nothing about amount. We cover how to find the rules in your own prompt that are safe to delete in Context Engineering for Claude 5: The Six New Rules (and How to Find the Rules You Can Delete) [4].
Tool definitions are the second block resent every turn. They had grown a lot. Cursor says most of its newer tools matter, but each is needed in fewer than 20% of conversations [1]. So Cursor kept them available without sending their full definitions every time, loading them only when the agent needs them. Cursor calls the part sent in every request static context, and the part loaded on demand dynamic context. It did this first for tools from MCP servers (the Model Context Protocol, a standard way to plug outside tools into an agent). That change cut total tokens by 46.9% across sessions that called an MCP tool [1]. Cursor then did the same with its own built-in tools. Static-context tool-description tokens fell by 60% [1]. We explain why tool definitions bloat in MCP Tool Design: The Two Ways Your Agent’s Tools Fail (Bloat vs. Confusion) [5].
Which tools stayed matters as much as which left. Cursor kept the high-frequency tools for reading, searching, editing, and using the shell in static context. It also kept ask_question, “which some models tended to hallucinate calls for” (they invented calls to a tool that was not available). It kept tools that specific product flows depend on, too, such as create_plan in Plan Mode (a mode where the agent plans before it edits) [1]. It picked the set by A/B testing several configurations, running competing versions side by side on real users and tracking token usage, cost, latency, tool-call errors, and overall agent usage [1]. The ask_question case shows the risk of lazy loading. A model that can’t see a tool’s definition can still try to call it.
Keep the 3 percentages apart. The 66% is a share of the system prompt’s length. The 60% is a share of tool-description tokens in static context. The 46.9% is a share of total tokens, counted only in sessions that called an MCP tool, and it came from the earlier MCP change rather than the later built-in one. Each number has its own base, so you can’t add them or rank them. None of them is a share of the 7%.
Figure 3 - 3 trims, 3 different bases: Cursor reports each number against a different quantity, so the figure keeps them on separate cards.
Figure 4 - Which tools stayed in every request: Read, search, edit, shell, ask_question, and create_plan stayed in static context. The rest load on demand, and Cursor says each is needed in fewer than 20% of conversations.
This fix leaves one thing broken. The front half is smaller, but the harness still sends all of it on every turn, and the provider still bills it as fresh input every time. Cut our hypothetical 30,000-token front half in half and it’s still read 50 times.
Let the provider remember the front half
Providers have a feature for this, called prompt caching. When a request arrives, the provider can keep the work it did on the beginning of that request. That beginning is the prefix, everything from the first token up to a chosen point, and the provider reuses it when a later request starts with exactly the same text. Anthropic describes it as prefix matching: the API caches everything from the start of the request up to each cache breakpoint [6]. A cache breakpoint is a marker that tells the provider where the prefix ends, so it can save it.
Reading a cached prefix back costs a fraction of the normal input price, while storing it costs a little more than normal. On Anthropic’s API a cache read costs 0.1 times the base input price. A write costs 1.25 times for the default 5-minute lifetime, or 2 times for a 1-hour lifetime [7]. On Opus 5.5 reads are cheaper still: 0.05 times the base price, or $0.20 per MTok against $4 for fresh input [2]. OpenAI’s GPT-5.6 and later models (GPT is its model family) charge 1.25 times for a write and 0.1 times for a read on most models [8]. Its GPT-6 guide says cached input tokens cost “up to 95% less” than uncached ones, depending on the model [9]. Treat “up to” as a ceiling. It tells you nothing about a typical saving.
Run our hypothetical session again with Anthropic’s Opus 5.5 rates. Assume every turn reaches the cache inside its lifetime. One write of the 30,000-token front half at $5 per MTok (1.25 times the base price) costs $0.15. Then 49 reads of 30,000 tokens at $0.20 per MTok cost $0.29, for a total of about $0.44 against $6.00. That’s our arithmetic on published prices, in the best case. Nobody measured it.
Figure 5 - Write once, then read cheaply: The first request pays a little extra to store the prefix. A later request that starts with identical text reads it back at a fraction of the price. The multipliers are Anthropic’s defaults for the 5-minute lifetime. Opus 5.5 reads cost 0.05 times ($0.20 per MTok), which the worked example uses, and the figure shows the general 0.1 times.
Both vendors let the developer choose where the prefix ends. Anthropic allows up to 4 explicit breakpoints per request, and its minimum prefix length runs from 512 to 4,096 tokens depending on the model. Its TTL (time to live, how long a stored prefix stays reusable) is 5 minutes by default, or 1 hour on request [7]. Since GPT-5.6, OpenAI’s API lets clients mark explicit breakpoints alongside its default automatic (“implicit”) caching. It allows up to 4 cache writes per request, with a 1,024-token minimum and a 30-minute window after the most recent write or reuse [8]. Anthropic’s two lifetimes can also work together in one request. Postman’s Agent Mode, which runs on Amazon Bedrock, keeps its near-immutable core behind a 1-hour checkpoint and its more variable context behind a 5-minute one, and the order matters: “Bedrock requires the longer-lived checkpoint to appear before the shorter-lived checkpoint” [10].
Anthropic’s API has documented explicit breakpoints for a while [7]. What changed for Cursor is that OpenAI’s API gained them, and Cursor says how much control you get over caching varies by provider [1]. Before GPT-5.6 the cache boundary was chosen automatically from the latest request. So tools and system instructions, though they rarely changed, “were not cleanly marked as reusable on their own” [1]. Cursor now places breakpoints after the stable layers of the request and before the growing conversation, so later turns reuse more of the unchanged prefix [1].
Figure 6 - Where Cursor puts the breakpoint: Stable layers sit in front, the breakpoint marks where the reusable prefix ends, and the growing conversation comes after it.
What this fix leaves broken is a condition. Cursor states it in one sentence: “Breakpoints only help if the prefix itself stays stable” [1]. OpenAI’s docs describe the failure. If content or a relevant setting changes before a breakpoint, “the prefix after that change cannot match the existing cache entry” [8]. Change one character near the top, and everything behind it is read at full price again. Cursor’s own fix implies that some variable setup text sat ahead of the boundary. The fix was to move it behind.
Make the front identical, not only short
Cursor reserved the tools and system instructions for content that rarely changes, then moved more variable setup past the cache boundaries. That setup now lives in what Cursor calls its phantom user message: an extra message placed after the boundary that holds user- and request-specific context like skills, subagents, and environment info [1]. Cursor reports that these changes reduced the rate of cold cache misses by 20% [1]. A cold cache miss, as we read Cursor’s term, is a request where nothing stored matched, so the provider processes the whole front half from scratch at full price. The 20% is a drop in the rate of those misses, from the breakpoints and the relocation together. It measures misses, so don’t read it as a share of the bill.
Anthropic published the same layout rule months earlier. Its post is frank about how easy the rule is to break. The best structure, it says, is “static content first, dynamic content last” [6]. Anthropic lists mistakes it made itself. It put an in-depth timestamp in the static system prompt. It shuffled the tool definitions into a different order from one request to the next. It updated the parameters of a tool [6]. When information goes stale mid-session, editing the prompt would cause a cache miss, so Claude Code adds a <system-reminder> tag to the next user message or tool result instead [6]. That’s the same move as Cursor’s phantom message.
The same rule settles a tension with the previous section. Loading tools on demand sounds like changing the tool list mid-session. Anthropic says changing the tool set is one of the most common ways people break prompt caching. Tools are part of the cached prefix, so adding or removing one invalidates the cache for the entire conversation [6]. Claude Code’s answer is a lightweight stub for each deferred tool: only its name with a defer_loading flag, in the same order every turn. It loads the full schema only when the model selects the tool [6]. Cursor’s post doesn’t say how it announces its on-demand tools, so we can’t say Cursor uses stubs. Either way, anything that varies belongs behind the boundary.
Anthropic’s API now documents a way to add a tool without touching the front. On models that support mid-conversation tool changes, an inline-tools-2026-09-15 beta header lets a harness add a tool, or change a tool’s definition, partway through a conversation. The definition goes in a tool_addition block inside a mid-conversation system message, and the original tools list stays exactly as first sent. In Anthropic’s words, “The cached prefix still matches, so only the appended message is processed as new input” [7]. That’s the phantom-message move applied to tools: the change lands after the boundary. It’s a beta, so check which models support it before you depend on it, and note the one exception the docs give: if the tools array holds no non-deferred tool, the first tool added this way costs one full cache miss [7]. OpenAI’s docs describe two related controls. A developer-role additional_tools input item adds tools during a thread, though those items “do not currently accept prompt_cache_breakpoint” [8]. Its allowed_tools setting restricts which tools are callable while keeping the supplied tools list stable [8]. That one narrows the set without adding to it.
OpenAI’s GPT-6 guide gives the same advice from the provider’s side of the bill: “Put stable instructions and reference material before changing task details, and keep tool definitions consistent” [9]. Its caching docs add a concrete case. With no breakpoint between a static developer message and a dynamic user message, the cache entry runs through the dynamic content and misses on the next turn. The fix is an explicit breakpoint after the static part [8].
On one newer model the rule has a hard edge. Anthropic’s migration guide for Claude Haiku 5.5 says a thinking block “stays valid only while everything sent before it is unchanged: a request that sends a thinking block back after a change to system, tools, or earlier messages returns a 400 error” [11]. On accounts created before August 31, 2026, the error appears only when a request opts into the check [11]. Where it applies, editing the front no longer just costs a cache miss. The request fails.
You can find out what broke. OpenAI offers a diagnostics tool that compares a request with a recent response and points at changes to the model, tools, settings, or input that prevented reuse [12]. Claude Code’s own prompt layers are mapped in AI Harness Cleanup: A Map-First Audit, and the Fix That Held for 8 Days [13], so we won’t rebuild that table here.
Figure 7 - Move the variable part behind the boundary: Setup text that changes per user or per request, if it sits in front of the boundary, makes everything behind it miss. Moved after the boundary, the front stays identical. Cursor reports the 20% drop in cold cache misses came from its breakpoints and this relocation together.
KEY INSIGHT: Find your cache breakpoint and ask what above it can differ between 2 turns. Timestamps, per-user text, and reordered tools are the usual culprits. Anything that differs belongs in a message after the boundary.
Smaller savings at the growing end
The conversation after the boundary is new every turn, so it can’t be cached away. Every later turn rereads it, though, so its size still matters. Cursor’s Read tool numbered every line of a file. Models aren’t good at counting lines on their own, and they need to cite sections for the user [1]. A line number costs only about 3 to 5 tokens. Across a session, an agent reads tens of thousands of lines. It adds up [1]. Cursor now numbers every tenth line. That’s still often enough for models to cite code. Cursor reports that this cut cache-read tokens by 1.6% with no reduction in quality [1]. It’s the smallest number in the post, and it’s measured against cache-read tokens.
Figure 8 - Number every tenth line: Each line number costs a few tokens, and a long session reads tens of thousands of lines. Cursor reports 1.6% fewer cache-read tokens.
Figure 9 - The request as a stack, with a lever per layer: Each lever sits on the layer it acts on. Every percentage names its own base, and none of them is a share of the 7%.
Subagents, model choice, and the effort dial
A subagent is a helper agent that the main agent starts for a side task, such as exploring a codebase. It begins with a fresh context window (the working memory of text the model can see in one request) instead of the parent’s full conversation [1]. That can save tokens. Agents that don’t share context can also duplicate work. Cursor calls that a coordination tax [1]. Cursor removed instructions that strongly pushed agents to use subagents for codebase exploration, because models had learned the pattern on their own. It also changed its tool arguments so agents choose a different model only when the user or the harness directs it [1]. That’s the harness deciding which model a helper uses, and it’s the one place a cheaper model enters this article.
A side task doesn’t need a whole agent to keep text out of the main context. NVIDIA’s KGMON team, which reports placing second in the KDD Cup 2026 data-agent competition with a small, fixed model, blocked its agent from reading whole files. After the agent found a relevant section, it handed that section to a tool called prose_helper, which sent it to “a separate LLM call with temperature set to 0 and reasoning disabled” (temperature 0 makes the model’s output as repeatable as it can be). The post doesn’t say which model that call used. The tool returned answers or extracted tables, “keeping raw document contents out of the main agent’s context” [14]. The post gives no token counts, so treat this as a pattern to try rather than a measured saving.
Anthropic sells models in tiers. Haiku and Sonnet are the smaller, cheaper ones, and Opus and Fable are the more capable ones. A video on Anthropic’s Claude channel makes a related point about Claude Code: “A sub agent that’s only exploring the codebase doesn’t need opus level reasoning,” and the presenter runs read-only subagents on “sonnet and sometimes even haiku” [15]. A custom subagent sets its model in its frontmatter (the settings block at the top of its definition file) [16]. Cole Medin says using Fable for planning and implementation gets “essentially the same results as using Fable for planning and Sonnet for implementation” [17]. Neither puts a cost measurement behind it.
The model can also be chosen by accident. AWS warns about this: “Without pinning, model aliases such as sonnet and opus resolve to Claude Code’s built-in defaults, which may change between releases” [18]. Claude Code’s docs list Opus 5.5 as the default on the Anthropic API and on Bedrock at the time of writing [19]. Pin the model to a full model ID and the surprise goes away [19].
Switching the main model mid-session throws the cache away, because each model has its own cache [20]. LangChain puts it this way: “The cost is the prompt cache: switching models throws it away,” and it recommends routing once per thread rather than once per turn [21]. For an asynchronous agent (one that works while the human is away), the loss is often small, since “the cache often expires anyways between human turns” [21].
Reasoning effort, how hard the model thinks before it answers, works differently. OpenAI says GPT-6 models keep the cache when effort changes between responses [12]. In Claude Code, only Opus 5.5, Sonnet 5.5, and Fable 5.1 with an API key or a Claude subscription do. Most other models recompute the whole request [20]. The dial still costs quality. BottleCap AI reports numbers for Qwen 3.8 27B, an open-weights model (one whose weights anyone can download). Medium effort instead of the xhigh (extra high) setting cut mean thinking tokens from 10,541 to 5,830, which is 52.1% fewer. It also lowered accuracy by 9.16 percentage points across 11 benchmarks [22]. That’s one vendor’s report on one model. We don’t read it as a rule for Claude or GPT effort levels.
How to tell it worked on your own traffic
Cursor chose its static tool set by A/B testing on real traffic, tracking token usage, cost, latency, tool-call errors, and overall agent usage, so a saving couldn’t hide a quality loss. It calls A/B tests on a large user base essential for tuning a harness [1]. It also explains why it doesn’t trust evals (automated test sets) alone: they “often represent ‘hard’ problems and don’t properly reflect the true distribution of user requests” [1].
You don’t need Cursor’s traffic to run a smaller version of the same check. Nate B Jones describes a rerun protocol for testing a new model, and it works just as well for a harness change. Take a task you’ve already done. Rerun it from the same starting point with the same prompt. Record the tokens, the bill at API prices, and, on a subscription, the share of your weekly allowance [23]. We split the tokens into 4 buckets: fresh input, output, cache writes, and cache reads. Each is priced differently. Anthropic says Opus 5.5 costs 40% less than Opus 5 on typical workloads at default settings [24]. Jones warns that “40% less cost doesn’t tell you that a task used 40% fewer tokens” [23]. His own run was 89 million tokens, “at least $44” at API pricing, about 1% of his weekly usage [23]. That works out to at least about $0.49 per MTok, far below the $4 base input price [2]. So by count most of that run was probably cache reads, while by dollars the output and cache writes probably carry most of the bill. That last part is our inference. Jones gives no breakdown by bucket.
Figure 10 - Rerun a task you already did: Record all 4 token buckets (our split), the bill at API prices, and on a subscription the slice of the weekly allowance.
KEY INSIGHT: Record every token bucket and the bill for the whole task. A change can lower the price per token without lowering the number of tokens.
Where this stops working
The evidence is thin in places. Cursor’s numbers are a single vendor’s report on its own traffic, with no sample sizes and no baseline for the 7%. Its chart data appears only as graphics, so beyond the 60% stated in one chart’s title we quote none of it. We found no second, independent measurement of breakpoint placement or of the tool layer. Only the system-prompt layer has a second vendor, and Anthropic’s over 80% comes from its own internal evaluations. OpenAI’s customer figures are testimonials that bundle several changes, and their methods aren’t disclosed. Strawberry Browser, for example, says cache hit rates on its own evaluations rose from 83% to 91% within a week, and its inference cost fell 36% [12].
Caches expire. Anthropic’s default lifetime is 5 minutes, and OpenAI’s is 30 minutes after the most recent write or reuse [7][8]. A developer who steps away for a meeting comes back to a cold cache, whatever the layout. A cache write also costs more than plain uncached input: 1.25 times the base price on both providers’ default lifetimes [7][8]. A prefix that changes every turn pays that premium and never earns it back. With caching, it costs more than without. OpenAI’s explicit-only mode exists for this case: content after the last breakpoint is processed at the uncached rate, with no cache-write charge [8]. A prefix shorter than the minimum, 1,024 tokens on GPT-5.6 and later, can’t be cached at all [8].
The mechanics also move fast. Minimum sizes, lifetimes, discounts, and which models keep the cache on an effort change all differ by vendor. Re-read your provider’s docs before you copy a number from here.
Conclusion
A long agent session gets expensive because every turn resends a request whose front half hasn’t changed. The order of the fixes matters. Send less first. Then mark the stable front half so the provider can reuse it. Then keep that front half identical by moving anything variable behind the boundary. The last step is what makes the first two pay off, because a breakpoint only protects text that stays the same. Cursor reports a 20% lower rate of cold cache misses from its breakpoints and the relocation together, and 7% lower token costs from all its changes combined, each measured against its own base [1].
Start with one request. Capture a real one from your own harness and write down how often each layer changes. Look above the cache boundary for anything that differs between turns, such as timestamps, per-user text, or reordered tools. Move it behind the boundary. Then rerun a task you’ve already done and compare the cost per finished task, with every token bucket recorded. If you want a second pair of eyes on it, we audit how a harness assembles its requests and measure what each layer costs.
References
[1] J. Katz, C. O’Keefe, and C. Yee, “Improved token efficiency for longer agent runs,” Cursor Blog, Sep 23, 2026. https://cursor.com/blog/improved-token-efficiency
[2] Anthropic, “Pricing,” Claude API Documentation, 2026. https://platform.claude.com/docs/en/about-claude/pricing
[3] T. Shihipar, “The new rules of context engineering for Claude 5 generation models,” Claude Blog, Jul 24, 2026. https://claude.com/blog/the-new-rules-of-context-engineering-for-claude-5-generation-models
[4] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “Context Engineering for Claude 5: The Six New Rules (and How to Find the Rules You Can Delete),” Dotzlaw Consulting, Aug 27, 2026. /insights/claude-code-19-context-engineering-claude-5-rules/
[5] G. Dotzlaw, K. Dotzlaw, and R. Dotzlaw, “MCP Tool Design: The Two Ways Your Agent’s Tools Fail (Bloat vs. Confusion),” Dotzlaw Consulting, Sep 2, 2026. /insights/ai-31-mcp-tool-design/
[6] T. Shihipar, “Lessons from building Claude Code: Prompt caching is everything,” Claude Blog, Apr 30, 2026. https://claude.com/blog/lessons-from-building-claude-code-prompt-caching-is-everything
[7] Anthropic, “Prompt caching,” Claude API Documentation, 2026. https://platform.claude.com/docs/en/build-with-claude/prompt-caching
[8] OpenAI, “Prompt caching,” OpenAI API Documentation, 2026. https://developers.openai.com/api/docs/guides/prompt-caching
[9] OpenAI, “A model guide for the GPT-6 family,” OpenAI News, Oct 2, 2026. https://openai.com/index/practical-guide-building-gpt-6/
[10] S. Kini and S. Gupta, “How Postman runs Agent Mode for 40 million developers on Amazon Bedrock,” AWS Machine Learning Blog, Oct 9, 2026. https://aws.amazon.com/blogs/machine-learning/how-postman-runs-agent-mode-for-40-million-developers-on-amazon-bedrock/
[11] Anthropic, “Claude Haiku 5.5 migration guide,” Claude API Documentation, 2026. https://platform.claude.com/docs/en/models/haiku-5-5/migration-guide
[12] OpenAI, “Better prompt caching for GPT-6,” OpenAI News, Sep 22, 2026. https://openai.com/index/better-prompt-caching-for-gpt-6/
[13] G. Dotzlaw, “AI Harness Cleanup: A Map-First Audit, and the Fix That Held for 8 Days,” Dotzlaw Consulting, Sep 10, 2026. /insights/ai-39-harness-cleanup-audit/
[14] E. Rocha de Andrade, J. Liu, M. Jeblick, R. Biswas, and I. Hulseman, “Building Reliable Data Analytics Agents: Lessons from the KDD Cup,” NVIDIA Technical Blog, Oct 8, 2026. https://developer.nvidia.com/blog/building-reliable-data-analytics-agents-lessons-from-the-kdd-cup/
[15] Anthropic (Claude channel), “Using Claude Opus 5.5 as your daily driver,” YouTube, Sep 23, 2026. https://www.youtube.com/watch?v=jKRl_CSVxyI
[16] Anthropic, “Create custom subagents,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/sub-agents
[17] C. Medin, “AI Coding Rate Limits are RIDICULOUS Now - Here’s How You Keep Scaling Anyway,” YouTube, Sep 24, 2026. https://www.youtube.com/watch?v=NZq88JAJSag
[18] B. Wyman, D. Hairfield, and K. Martin, “Supercharge regulated workloads with Claude Code and Amazon Bedrock,” AWS Machine Learning Blog, Oct 5, 2026. https://aws.amazon.com/blogs/machine-learning/supercharge-regulated-workloads-with-claude-code-and-amazon-bedrock/
[19] Anthropic, “Model configuration,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/model-config
[20] Anthropic, “How Claude Code uses prompt caching,” Claude Code Documentation, 2026. https://code.claude.com/docs/en/prompt-caching
[21] S. Runkle and E. Yurtsev, “How to Build a Model Router in the Harness,” LangChain Blog, Oct 1, 2026. https://www.langchain.com/blog/how-to-build-a-model-router-in-the-harness
[22] BottleCap AI, “ThinkingCap-Qwen3.8-27B: the same answers, 37% less thinking,” BottleCap AI Blog, Sep 22, 2026. https://www.bottlecapai.com/post/thinkingcap-qwen3-8-27b/
[23] N. B. Jones, “Opus 5.5 vs The Rest: Is this the new industry standard?,” YouTube, Sep 30, 2026. https://www.youtube.com/watch?v=osZZjdMZVvA
[24] Anthropic, “Introducing Claude Opus 5.5,” Anthropic News, Sep 22, 2026. https://www.anthropic.com/news/claude-opus-5-5
Building production AI, or modernizing a legacy system?
That is the kind of work we do at Dotzlaw Consulting. Book a free 20-minute intro call and tell us what you are trying to build, or what is slowing you down.