What does it actually mean when an agent harness is said to be “75% cheaper”? That phrase made me stop while reading a VentureBeat article about TrueForge. Not because I wanted to question the number. But because a number like this only becomes interesting once it is clear which question it answers.

Is the harness cheaper—or the system as a whole?

The cost of an agent is not a fixed property of its harness. It emerges from an entire configuration: the model and its price, prompts, tool schemas, the number of tool calls, context growth, compaction, retries, and runtime.

So when we say that an agent is cheaper, we may mean two different things:

  1. Which overall system completes a task most economically?
  2. How much does the harness itself contribute to that efficiency?

The questions sound similar. Methodologically, however, they require different comparisons.

What do I hold constant, and what do I change?

If I want to examine the harness, I should keep the model as constant as possible:

Claude Opus + Claude Managed Agents
vs.
Claude Opus + TrueForge

This is exactly the comparison in the benchmark published by TrueFoundry. At the same average success rate, the TrueForge configuration costs $8.60 rather than $11.80 per run—around 27% less.

The more spectacular 75% figure comes from a different comparison: TrueForge now runs with the much cheaper GLM-5.2, while Claude Managed Agents continues to use Opus. This changes both the harness and the model at the same time.

The 75% figure is therefore not wrong. It simply does not isolate the efficiency of the harness; it describes the economics of a different overall configuration. To be fair, both TrueFoundry and VentureBeat make the two configurations transparent in the text. In the shortened headline, however, they tend to merge into a single claim. Clickbait?! ;)

Which comparison is the right one?

That simply depends on the decision I want to make.

As a user, I may care most about which setup completes my tasks reliably and cheaply. After all, overall performance is always a function of all the components involved. In that case, I want to optimize the harness and model together. Comparing the GLM-5.2 configuration makes sense for this product decision.

If, on the other hand, I want to learn something about agent architecture, the same-model comparison is more valuable. It removes one major confounding factor and makes it more plausible that differences in the agent loop, context management, or tool use matter. That also makes total sense, because the same model demonstrably performs differently with different harnesses.

A product decision asks for the best package. A technical causal claim asks about the contribution of one component. Neither question is more important—but they must not be thrown into the same pot.

The interesting investigation starts after the bare number

In my view, the more interesting discussion therefore begins behind the cost headline. Where exactly does a harness save its so-called trajectory budget?

  • Does it require less prompt and tool-schema overhead?
  • Does it plan more targeted tool calls?
  • Does it keep context smaller through offloading and compaction?
  • Does it need fewer retries?
  • Or is it cheaper only because the agent gives up earlier?

TrueFoundry attributes the savings in part to more compact instructions, fewer tool calls, and leaner context management. The benchmark kit is public, so this explanation can be examined and, in principle, reproduced.

Fewer tokens or tool calls are not automatically better, however. An agent that skips essential steps may produce a cheap trajectory, but not a successful one. The more useful guiding metric for me would therefore be:

Trajectory Cost per Verified Successful Outcome

Efficiency has to remain tied to a verified success. If a supposedly efficient agent needs five attempts because it produces the wrong result four times, it is more expensive in the end—and, measured by cost per verified successful outcome, less efficient.