adam_rida

i typically run many coding agents side by side and i noticed i never read the wall of tool calls and text and tasks they do, i just want to know if 1) it’s still going 2) what is it currently doing and 3) what was its last message if it stopped. i built a lightweight cli tool for that.

while the agent works, you get a row of ‘instruments’ (model, mode, nb of messages …) and one that shows the current action. you can always prompt your agent directly from HUD, no need to open it in full. its also possible to jump back and forth between HUD and the main coding agent with /hud

on how it works: it uses the official CLIs headless through JSON event streams and the /hud handback for claude code consumes 0 tokens (UserPromptSubmit hook, ~150ms), 0 runtime dependencies.

i think that’s exactly the core of the question. There is meaningful decorrelation across models in some domains, like language for instance. but i agree that it’s much less obvious for reasoning.

I don’t think more models is necessarily better, and one of our research questions is also: when does adding another reasoning path actually add useful information, and when is a single strong path better than an ensemble?

thanks! adjusting it now

good catch, on it too now!

exactly, if you ensemble heavily small uncorrelated models (while each being expert on its task) you can get really interesting resutls.

on agentic and coding what's make the problem even deeper is the granularity. how and when to use each model and at which layer of abstraction (session, goal, task, turn/tool calling). this is also something we are working on actively!

removing it now

there are and this what you optimize for. ensemble learning has a long literature on this. you want models that have the most diverse pool of capabilities so they complement each other. in verifiable tasks or classification this is straightfroward but a bit tricker in open ended text gen or CoT. this is one of our core research question

thanks to everyone for taking the time to try Echo and share feedback, this is precisely why i wanted to launch early.

i am going to try to address a couple of topics that came up often:

- i'll keep publishing stronger evals, including more difficult coding and agentic benchmarks, to map out more precisely the differences with sota

- the public eval dashboard will keep expanding and be updated (very open to more benchmark suggestions as well!)

- some people found issues in the eval dashboard ui and the sign up flow, should be now all fixed in prod

some important precisions as well:

- NO credit card is required to try Echo

- each acount includes 10$ of free credits to try on both the API and the chat

on the approach itself: the idea i'm exploring is more broader than model routing, i'm looking at how to allocate inference efficiently across open-weight models, deciding not only which models to use, but also how much computation a request deserves and how intermediate work should be combined.

ensembling by itself is not new. since random forests and probably even before in statistics/classic ml we knew that bringing multiple models together can outperform individual ones. the interesting problem for Echo is how to model and leverage this without paying the full ensemble cost at each request.

while there are conceptual similarities with systems like Fusion or Fugu, the architecture and optimization objective are different.

thanks again for all the thoughtful feedback.

looking at it now

looking at it now