Strands harness: what its lower-cost agent benchmarks actually show

Strands Agents introduced Strands harness on September 21: a ready-made runtime around an AI model, with tools, memory and context management already assembled. Its launch claim is lower token cost across a set of agent benchmarks. For builders, the more useful question is whether those defaults can reduce both implementation work and the cost of a successfully completed task.

What is an agent harness?

A model proposes actions; a harness handles the surrounding process: supplying tools, executing calls, retaining useful context and deciding how the run continues. Changing this software can change results even when the underlying model stays the same.

The project documentation describes Python and TypeScript entry points, with Amazon Bedrock as the default and alternatives including Anthropic, OpenAI, Google and local Ollama models. Built-ins cover shell, files, web access, sessions, memory and helper agents. The repository is Apache-2.0 licensed; the assembled harness sits alongside the lower-level SDK for teams that want more control.

This is infrastructure for building agents. Choosing a model, supplying credentials and defining what the application may access remain part of the integration.

What does “28% lower cost” refer to?

The announcement compares harnesses across six benchmarks. It reports 28% lower token cost overall with comparable or better accuracy in that evaluation. These are the project’s own measurements, not an independent test conducted for this article.

The chart’s footnotes matter: the plotted cost is an average per task, and the evaluation includes a cheaper DeepSeek harness that scores lower. The result does not mean Strands is the least expensive choice in every comparison.

A separate Terminal Bench 2.1 figure keeps the model fixed at Claude Fable 5. It reports $56.29 across 89 trials for Strands, against $248.05 for Claude Code; displayed accuracy rounds to 69.7% and 61.8%, respectively. Those dollar figures are totals for the trial set, not prices for one request.

Our interpretation: these comparisons make the surrounding software worth testing alongside the model. They do not establish how a private repository, a different tool set or another workload will behave.

From a terminal prototype to application code

The official clip demonstrates exporting a configured agent into application code. It is the original project recording, not a workflow we ran.

The configuration reference exposes model selection, tool lists, MCP connections, context management and session storage. Built-in tools can be restricted or disabled; interventions can gate calls behind an approval or policy. Those controls are important when a prototype gains access to actual files and services.

A desktop prototype using the same harness

The announcement also shows a desktop app built by engineer Gautam Sirdeshmukh that runs the harness remotely. The clip is an example of an application built around the runtime, not a claim that a finished desktop product is generally available.

How we would evaluate it

A useful first task for this publication would be to compare three public announcements and produce a source-linked research note. Give every candidate the same inputs and acceptance criteria: correct dates, supported claims and explicit unresolved questions.

Track the cost of accepted results, including retries and human correction. Also record missing citations, incomplete tasks and time to completion. Repeat with a deliberately long source to see whether context handling loses a qualification that changes the story.

For the initial trial, we would restrict the agent to reading sources and writing into a temporary workspace. Publishing and sending messages would remain separate decisions. This article includes no independent runtime benchmark: Strands has made an interesting, testable infrastructure claim, and the next useful evidence is how it performs on a clearly defined workload.