> Using harnesses that are “less chatty” (more token efficient), or tuning existing harnesses to generate less token overhead.

agree, this works, undervalued!

look at minimal agents that protect the context window:

  - pi (https://github.com/earendil-works/pi)
  - smol (https://github.com/smol-env/smol)

some thoughts on the other tips (for coding):

1) stronger models are more token efficient for open ended tasks because at the limit …

  - stronger models can solve tasks that the weaker models can not solve
  - stronger models make fewer mistakes, compose things better (cli, abstractions, …)
  - navigate the code base better
  - are better at removing and simplifying the code base again

that of course is difficult to benchmark, so most attention goes to simple benchmarks that show cheaper models can get similar results on 'closed' tasks with easy to 'eval' results

2) dynamic request and task routing sounds great/obvious but is very very hard

  - to benefit from caching you don't want to switch model or inference endpoint
  - to _know_ a certain request can be routed to a weaker/cheaper model needs good context and a strong model to get right and often is still unknowable because the active coding session can go many ways and turn from trivial to challenging in a few turns, always in motion is the future, if you get it wrong you are back in the problem space of #1

using cheaper models and auto-routing do work well for 'closed' tasks where you have something repeatable and can evaluate whether a certain quality threshold is reached that you are comfortable with

for open ended coding sessions it is not so easy

that said: cheaper does not have to mean weaker, you want to look at the pareto frontier and stay up to date on new good models

there are many models like deepseek v4 flash and luna that are both cheaper and way better than most other models