I auto tune my prompts to a locked model version based on production data used as evals with holdback data. I think the use case for this would be one off interactive prompts? For now I just run those all against an Opus 4.8 MAX and I'm sure I could downtune, although for interactive my opening prompt isn't always reflective of my overall goals for the multi turn session.
I'm just trying to figure out why on the fly routing would beat testing and tuning and locking models and versions for each class of call, with evals and auto tunes running to explore more possible models for commonly run classes of prompt over time . . .
g00k 34 minutes ago [-]
Man, I'm not so sure if I'd use something like this because the way I prompt already changes based upon what model I am using. I'm not convinced it would route to the right model based on my diction or whatever.
adchurch 28 minutes ago [-]
Yeah that's a really interesting point, tbh I think the more relevant variable here is the harness you're using rather than the specific model? i.e. GPT 5.5 in the Claude harness behaves a lot more like Claude than Codex if that makes sense.
Hard to quantify this ofc but that's what I've felt vibes wise from using this for the last month.
alansaber 28 minutes ago [-]
Yep this was always the reason to avoid "auto" mode in cursor.
stpedgwdgfhgdd 1 hours ago [-]
The thing I do not get with these routers is that you will have more cache misses (5min ttl). And if there is one thing i’ve learned; using the cache is crucial.
How does this router translate to $$$ when developing?
adchurch 42 minutes ago [-]
You're right and that's why we built the router to be cache aware! Once it starts using one model, the threshold to switch to another model will be higher because the additional cost of the cache miss needs to be worth the cost savings or quality increase.
This is the key thing that other routers we've seen miss: they're stateless so for a coding agent use case you end up spending more money due to all the cache misses.
alansaber 29 minutes ago [-]
That is interesting, sounds like in practice you only end up routing between 2 models
adchurch 27 minutes ago [-]
I'd say that a typical main agent loop has 1-3 models (obviously very situationally dependent), but when you have subagents those can get routed independently since they have a fresh context window, so there are a lot more degrees of freedom there.
31 minutes ago [-]
spqw 39 minutes ago [-]
This + making sure common requests are saved as reusable skills and scripts would probably save a large part of my token usage
As prices increase we will see more of these tools to optimise and make the best use of token budget
adchurch 24 minutes ago [-]
100%, from what we've seen, for a lot of big companies that 1. don't have subsidized usage and 2. are pushing AI adoption hard, figuring out token costs is P0 or P1 for their eng leadership
k9294 18 minutes ago [-]
What about request caching? If you swap to a cheaper model mid execution it might cost more that to make multiple requests to the already cached provider?
I would rather just use OpenCode - leverage AI models, even can host locally or paid ones with ease.
adchurch 19 minutes ago [-]
We integrate with OpenCode too! OpenCode provides the harness, then the router selects the right model for the task.
We haven't yet set up local model routing though, that's really interesting - have you had any success using local models for coding tasks? Tbh I haven't heard many success stories from using local models yet
alansaber 30 minutes ago [-]
"We reward the routing model when it selects an LLM that achieves the task successfully" sounds pretty oversimplified
adchurch 15 minutes ago [-]
Indeed it is :) I skipped over talking about all the RL machinery, network design, reward function design, state representations, etc. because really the intuition is that we tell the model when it accomplishes its goal, and then it learns over time how to get better at making the right decisions in order to accomplish its goal.
Happy to talk about this in some more depth if there's anything specific you're curious about!
gautam_io 27 minutes ago [-]
This is cool!
Will this use my Claude Pro/Max subscription? Or will it always use the API billing "pay as you go"?
adchurch 26 minutes ago [-]
Yep it uses the Claude sub if possible and falls back to API billing only if you don't have a Claude sub or it's out of usage! Same deal for Codex
mkagenius 12 minutes ago [-]
We have created Murmur[1] which kind of works with your existing subscription (having API key is not mandatory). You can just tag @copilot @codex from claude code to delegate work to them. (it can also do it on its own too btw)
Cool.. but I still don't get how this is going to save money. It seems to me that it might actually burn more money just because the whole system now seems to be coming from different LLMs.
Also, small LLMs are prone to stop before completion, throw errors and produce loops. Is this factored in the design of the tool? I am not sure.
edit: spellcheck
adchurch 39 minutes ago [-]
It saves money because some agent sessions can be entirely handled by a smaller model (also relevant: subagents use fresh context windows so a subagent with a simple task can be routed to a smaller model even if the main agent needs a frontier model).
Totally right about small LLMs btw, that's why we trained this on real agent sessions where we forced it to use different models. If the routing model sees small models can't handle a certain type of task then they won't be assigned. (Also as a fallback we have some guardrails that will have a bigger model come in to "rescue" a smaller model if it gets stuck)
debarshri 40 minutes ago [-]
It is funny. We are building something similar.
adchurch 32 minutes ago [-]
Oh cool, feel free to reach out to me at andrew@workweave.ai if you ever want to share notes! We've learned a lot in the process of building this so far :)
arendtio 55 minutes ago [-]
What is the difference from Cursors 'auto' mode?
adchurch 38 minutes ago [-]
Fun fact: Cursor's "auto" mode is just Composer (or at least it was last time I checked). So it's different in the sense that it actually does route to more than 1 model
emilio_srg2 32 minutes ago [-]
but this means you work with API pricing rather than subscription pricing. Isn’t it better to use claude or codex CLI etc directly in terms of cost?
adchurch 30 minutes ago [-]
If you have a Claude/Codex subscription then we use that (and account for the subsidized price accordingly when making routing decisions) instead of API billing. So you get the best of both worlds: subsidized usage for frontier models + save by using open/smaller models when it's genuinely better.
In practice, lots of ppl are using this to make their Claude sub limits go further!
emilio_srg2 20 minutes ago [-]
I see but didn’t they severely limited the usage allowed with `claude -p`
adchurch 18 minutes ago [-]
But we're not routing via `claude -p`, if you have sub usage available + it's the right choice to route to a Claude model, then the router is approximately a transparent passthrough. So it gets billed like normal `claude` usage rather than `claude -p`.
slopinthebag 24 minutes ago [-]
> At Weave, we write ~all our code with AI
This is probably not a very effective way of marketing imo. At least, it turns me completely off.
ai_slop_hater 47 minutes ago [-]
Isn't this more expensive than always using the same model, since, as I understand, by routing to different models you give up on cache?
adchurch 34 minutes ago [-]
If you statelessly route each new request: yes it does end up being more expensive!
So our routing is cache-aware. It will have a much higher threshold to switch from one model to another if there's already some cache for the first model. Experimentally this solves the problem (like I said we've saved 40% ourselves vs. what we would have otherwise paid).
iluvcommunism 10 minutes ago [-]
This is basically what I need, a router. I’m tired of changing intelligence & speed levels manually.
gmziven 49 minutes ago [-]
[flagged]
Rendered at 18:16:23 GMT+0000 (Coordinated Universal Time) with Vercel.
I'm just trying to figure out why on the fly routing would beat testing and tuning and locking models and versions for each class of call, with evals and auto tunes running to explore more possible models for commonly run classes of prompt over time . . .
Hard to quantify this ofc but that's what I've felt vibes wise from using this for the last month.
How does this router translate to $$$ when developing?
This is the key thing that other routers we've seen miss: they're stateless so for a coding agent use case you end up spending more money due to all the cache misses.
As prices increase we will see more of these tools to optimise and make the best use of token budget
We haven't yet set up local model routing though, that's really interesting - have you had any success using local models for coding tasks? Tbh I haven't heard many success stories from using local models yet
Happy to talk about this in some more depth if there's anything specific you're curious about!
Will this use my Claude Pro/Max subscription? Or will it always use the API billing "pay as you go"?
1. https://github.com/instavm/murmur - Murmur
Also, small LLMs are prone to stop before completion, throw errors and produce loops. Is this factored in the design of the tool? I am not sure.
edit: spellcheck
Totally right about small LLMs btw, that's why we trained this on real agent sessions where we forced it to use different models. If the routing model sees small models can't handle a certain type of task then they won't be assigned. (Also as a fallback we have some guardrails that will have a bigger model come in to "rescue" a smaller model if it gets stuck)
In practice, lots of ppl are using this to make their Claude sub limits go further!
This is probably not a very effective way of marketing imo. At least, it turns me completely off.
So our routing is cache-aware. It will have a much higher threshold to switch from one model to another if there's already some cache for the first model. Experimentally this solves the problem (like I said we've saved 40% ourselves vs. what we would have otherwise paid).