Why Harness Optimization Beats Model Switching for Cutting LLM Costs

Key takeaways

• Writer launched Palmyra X6 on 13 August 2026, post-trained on Z.ai's open-source GLM-5.2, and estimates the model plus harness upgrades will cut customer costs by as much as 50% on basic tasks.
• A paper from Writer researchers found that small harness efficiency changes reduced costs by an average of 40% across the models tested, in many cases more reliably than model choice did.
• Harness gains compound across every model you run, present and future. A model swap is a one-off gain that resets on the next migration.
• Most founder cost models track dollars per million tokens and quietly ignore tokens per completed task, which is exactly where the harness lives.
• Model the two levers separately before you renegotiate a single contract.

What is a harness, in plain terms?

The harness is everything wrapped around the model call: the system prompt, the tool schemas you attach, how you chunk context, how many times you loop, whether you cache, and how you decide a task is finished. The model is the engine. The harness is the gearbox, and most teams have never looked at it.

That matters because the harness is where token volume is decided. Your provider sets the price per token. Your harness sets how many tokens each finished job consumes. Multiply the two and you get your real cost of goods sold, not the number on the pricing page.

Why does the harness beat the model as a cost lever?

Writer's researchers put it bluntly: "The harness is the one component whose efficiency multiplies across every model an organization runs, present and future."

That is the whole argument in one sentence. If you cut your tokens per task by 40%, that saving survives your next three model migrations. If you cut your price per token by 40% by switching provider, the saving evaporates the moment the next model looks better on a benchmark and you migrate again.

There is a second, less comfortable reason. Writer CEO May Habib told TechCrunch that the labs "have a financial incentive to drive up token use" and that CIOs are increasingly sceptical of them. You do not have to accept that framing to notice the structural point: nobody upstream of you is optimizing your tokens per task. That work is yours.

How do you put a number on it?

Split your unit economics into two multipliers and measure them separately.

Price per token is public. Tokens per completed task is not, and almost nobody instruments it. Start there: log input and output tokens per finished job, not per API call, for one week. Then run the same jobs with a trimmed system prompt, fewer tool definitions in context, and caching enabled, and log again.

For example, say a support-resolution task averages 30,000 tokens end to end at a blended $9 per million. That is $0.27 per resolution. Cut tokens per task by 40% and you are at $0.16, without touching your provider, your contract, or your model. Those figures are illustrative, but the structure of the calculation is not.

What does this change about provider comparison?

It does not make provider comparison pointless. It makes it second. Compare providers after you know your tokens per task, because the cheapest provider for a bloated harness is often not the cheapest provider for a lean one, and a model that is 20% more expensive per token but finishes in half the steps is cheaper in practice.

Note also what Writer actually built: a post-training variation on an open-weight model, deployed alongside third-party models imported through Azure or Bedrock. Model-agnostic architecture plus a tuned harness is the combination doing the work here, not one heroic model choice.

The short version: price per token is the number you negotiate, tokens per task is the number you control, and only one of them compounds.

If you want to see how a change in tokens per request moves your margin per user, you can model both sides at calcaas.com.