Strands Harness Says It Costs 28% Less. The Savings Are Three Defaults You Cannot Configure
AWS published specific numbers for how its agent harness manages context. Those numbers do not appear anywhere in the configuration reference.
AWS released Strands harness on September 21, 2026 with a claim pointed straight at Claude Code and Codex: 28% lower token cost on the same Claude and GPT models across six benchmarks, at equal or better accuracy. With Fable 5, it claims 77% less cost than Claude Code and a higher Terminal Bench 2.1 score.
The interesting sentence in the announcement is not any of those. It is the credit line. AWS attributes the token efficiency and the accuracy to its default context management, and then names the behavior with unusual precision: tool results over roughly 1,500 tokens get truncated, compaction triggers when the context window passes 85%, and context recovery runs inside the loop if there is an overflow.
Three specific thresholds. Now go read the configuration reference, which promises every option the harness factory accepts, in one table.
None of the three is there.
What the configuration surface actually gives you
The table lists context_manager in Python, contextManager in TypeScript. It takes "auto", which is the default, or "agentic", or off. That is the entire public surface for the behavior that AWS credits for its headline number.
The dedicated page on managing context and caching adds description but no knobs. It explains that with context management on, the harness keeps relevant history in the window and summarizes older turns as the conversation grows, and appends a context offloader that moves bulky tool results to storage and replaces them with a short preview plus a reference the agent can follow to pull the full content back when it needs it. Both "auto" and "agentic" keep the offloader on. Turning context management off disables offloading too, and then, in the docs' own phrasing, you own the size of the context.
So the choice you are offered is: take the policy, take a slightly different policy, or take none of it. The 1,500-token line and the 85% trigger are implementation details of the first two.
I want to be fair about what that means, because "you cannot configure it" sounds like a complaint and I am not sure it is one.
The case for hiding the numbers
Every team that has built a long-running agent has written a version of this logic, badly, at two in the morning. You notice your context filling. You add truncation. You pick a number out of the air, usually a round one. You discover the number was wrong for tool results that matter. You add an exception. Six weeks later the exception has three exceptions.
Hard-coding a tuned threshold and refusing to expose it is a defensible product decision. It means the vendor owns the number, can move it when the models change, and does not have to support every bad value a user picks. It is the same reason a database will not let you set an arbitrary page size.
There is a real cost, though, and it is specific. If your workload has tool results that are consistently just over the truncation line and genuinely load-bearing, you have no dial. Your options are to switch context management off entirely and rebuild all of it, or to restructure your tools so their results come back smaller. The second is probably the right answer anyway. That does not make it free.
The docs do leave a back door. The configuration reference says any keyword the factory does not name is forwarded to the underlying Agent constructor, and explicitly that passing memory_manager overrides memory. The context-and-caching page shows the SDK-level alternative, a SlidingWindowConversationManager with an explicit window_size and should_truncate_results. So you can reach past the harness into the SDK and set your own policy. You just cannot tune the tuned one. You replace it.
About that 28%
The number is credible in direction and unverified in magnitude, and the reason is stated in the post itself.
AWS ran the comparison. AWS chose the six benchmarks, ran competitors' harnesses, and reports the results, with the research paper described as a follow-up rather than something you can read alongside the claim. Testing was distributed benchmarking on EC2 with Harbor.
To the team's credit, the post does not hide the awkward parts. It says Deepseek Harness proved the most token-efficient overall, while typically reporting the lowest accuracy. It notes that two other open-source harnesses performed similarly well on cost and accuracy against Claude Code, which is a strange thing to volunteer if you are trying to sell your own harness as uniquely efficient. That kind of self-undercutting detail usually indicates the numbers are real.
Real and independent are different things. Until the paper lands, treat 28% as the result AWS got running its competitors' software on its own infrastructure against its own benchmark selection. That is not an accusation. It is what vendor benchmarking is, always, from everyone.
And the practical implication cuts in an interesting direction. If the saving comes from truncation, compaction, and in-loop recovery rather than from anything about Strands itself, then the saving is portable. You do not need to adopt this harness to get most of it. You need to implement those three behaviors in whatever you already run.
Put this into practice
The lowest-friction version of this is an afternoon, and you do not have to migrate anything.
Try it against a task you already have a token bill for. Install and run it against something you have run before, so you have a comparison:
pip install strands-harness
Then:
from strands_harness import create_harness
agent = create_harness(model="anthropic/claude-sonnet-5")
agent("<a task you have run before and know the token cost of>")
TypeScript is npm install @strands-agents/harness and createHarness({ model: 'anthropic/claude-sonnet-5' }). One caution on defaults: the configuration reference lists the default model as bedrock/global.anthropic.claude-opus-4-8, so with no model argument you are on Bedrock and need AWS credentials with permission to invoke it. Naming the provider explicitly avoids a confusing first failure.
Run the same task with context management off, and compare. This is the measurement that tells you whether the defaults are worth anything on your workload rather than on AWS's benchmark suite:
agent = create_harness(model="anthropic/claude-sonnet-5", context_manager=False)
If the gap is small, your tasks are short enough that none of this matters and you can stop reading. If the gap is large, you have just measured the size of the prize for implementing truncation and compaction wherever you actually work.
Set a session id before you care about it. Sessions are on by default and persist to ./.agent/sessions with a generated id. Pass your own and later runs rehydrate the same conversation:
agent = create_harness(session={"id": "api-design"})
This also matters for the offloader, because offloaded artifacts live under the session directory when a session is active, and go to a temporary directory that does not outlive the process when one is not. Run without a session and your offloaded tool results evaporate when the process exits.
Narrow the built-in tools before you deploy anything. The defaults are shell, read, write, edit, web_fetch, web_search, programmatic_tool_caller, and subagent. That is a lot of reach for an agent whose job might be summarizing tickets. builtin_tools=[] turns them all off, or pass the list you want.
Read the sandbox seam before you trust it. The shell and file tools route through a sandbox seam that also accepts Docker and SSH backends, but the documented default is a local sandbox on the host. The separate Strands Shell security page is refreshingly blunt about what that means, calling itself a mediation layer rather than a hardened sandbox, noting it runs in the same process as your code rather than in a VM, and recommending you add container or microVM isolation when the workload is adversarial. The docs also flag a gotcha worth catching now: the TOML config defaults bind mode to copy, the safe choice, but the Python and Node constructors default to direct. Pass mode explicitly in code.
Honest limitations
The headline numbers are single-source. Six benchmarks, one vendor running all of them, paper pending. If your decision depends on the exact percentage rather than the direction, wait for the paper or run your own comparison, which the section above is designed to let you do in an afternoon.
The thresholds are not yours. 1,500 tokens and 85% are stated in a blog post, absent from the configuration surface, and can therefore change in a release without a configuration deprecation, because there is no configuration to deprecate. If your architecture depends on the exact truncation point, you are depending on something the vendor has not promised.
"Fully assembled" means a lot of surface. Shell, filesystem, and web tools are on by default, a generalist subagent is wired up, background tasks default to an agentic policy on everything, and skills load from a directory if one exists. Convenient. Also more capability than most single-purpose agents need, in the same week that Transluce published evidence of agents reaching for exploits while doing ordinary data-retrieval work. Narrow it deliberately.
A general-purpose harness is not a coding-agent replacement. AWS says so directly: it is built to be a general-purpose agent rather than a coding agent. The Terminal Bench comparison is the harness's own strongest ground. Do not read it as a claim that you should uninstall Claude Code.
It is young. The repo's tagged release history is per-package, the harness CLI tag as of this writing is harness-cli/v0.1.2 from September 23, and the Apache-2.0 license file sits at the nonstandard path LICENSE.APACHE with the default LICENSE path empty, which will confuse automated license scanners in a corporate pipeline even though the README links it correctly.
What I would actually do
If you maintain an agent that runs long tasks and you have never measured what your context strategy costs you, run the two-command comparison above this week. Not to migrate. To get the number.
Because the useful thing AWS published here is not a harness. It is a claim, specific enough to test, that most of the money in a long-running agent is lost to context you did not manage, and that three unremarkable behaviors recover a quarter of it. You can check that against your own bill without adopting anything.
If the number comes back large, you learned where your spend goes. If it comes back small, you saved yourself a migration. Either way the measurement is yours, which is more than the benchmark can say.
Sources: Introducing Strands harness (September 21, 2026) · Configuration reference · Manage context and caching · Shell and file tools · Strands Shell security model · strands-agents/harness-sdk
Medium metadata
Suggested tags: AI Agents, Agentic AI, AWS, Software Engineering, LLM
Suggested subtitle: AWS published specific numbers for how its agent harness manages context. Those numbers do not appear anywhere in the configuration reference.
Canonical: import from the fervorai.dev URL.