9 comments

[ 0.27 ms ] story [ 16.2 ms ] thread
Brick is a cheap & smart spatial router that plugged into claude code redirects the query to the best model in your pool. You can use it to save tokens, use other providers in claude code without changing models by hand or making your plans way longer in code time
How does it deal with prompt caching? Do you have any resource for this, I'd like to check it out.

I've heard changing models messes up caching and costs more.

If you switch models, you have no cache. There is no way to change this as they depend on sending the tokens through the weights and saving the computation results. Different model, different tokens, different weights, different calculation.
Actually yes because context is kept on kV cache
you cannot transfer KV cache from one model to another
You transfer context from the kv cache of model A to the kv cache of model B
you cannot do this with direct byte copy, you have to reprocess all input to rebuild the cache in model B, it's exactly like waiting hours to send a new message to an existing session and your cache has expired

tl;dr - you will not get the 90% discount the first time you change models and send a message

this is why I am saying you cannot "transfer" kv cache, it's just like changing models in your favorite harness and that requires reprocessing the input from scratch to build a kv cache for the model

For sure that’s absolutely true because you’re switching context from a kV cache to another one. We introduced 2 algorythms for solving this : 1) sticky : switches model only when convenient 2) smartsqueeze : fast advanced compression for reingesting context