Does this mean you have to retrain routing rules every time a new model gets released? I imagine since the price/token (or rather the amount of work that can be done per token) does not monotonically increase with new models, that the routing logic has to change all the time
Launch HN: Tokenless (YC S26) – Automatic model switching to save money
21–30 of 69 posts
Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money
#22System Prompt Jailbreak (Playground)
> You are a coding assistant powered by Tokenless, a router that dynamically picks the best LLM for each task. Help with programming questions, code review, debugging, and software design. Be concise and lead with concrete code or commands. Use fenced code blocks with the correct language tag.
Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money
#23Is the model picked through the router only for the first user turn or is there multi-turn routing (or planned to be added) ?
Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money
#24Is the model picked through the router only for the first user turn or is there multi-turn routing (or planned to be added) ?
It automatically works with multi-turn routing. You can try it yourself in Claude Code or Codex
Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money
#25Interesting approach. The multi-model progress monitoring idea is clever, most routing I've seen is either static rules or a cheap classifier that picks once upfront. Querying in parallel and deciding mid-turn feels different.
One thing I'm curious about: how do you handle the latency hit from spinning up multiple models on the harder turns? Does the user-facing latency still feel competitive with just going straight to Claude, or is there a noticeable pause while the router decides?
Also, any plans to expose the routing decisions (or at least the model chosen per turn) so people can debug when it picks poorly? That seems useful for the feedback loop you're asking for.
Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money
#26Does this mean you have to retrain routing rules every time a new model gets released? I imagine since the price/token (or rather the amount of work that can be done per token) does not monotonically increase with new models, that the routing logic has to change all the time
test
Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money
#27So this only switches models if the cache is cold, because otherwise the economics of switching don't work. But most agentic work involves long strings of successive tool calls that benefit from a hot cache. Hot cache calls reduce input cost by 90%. This can basically only deliver cost savings in turns where the AI delivers a result to the user, the user waits at least 5 minutes (or the length of the cache), and then…
> So this only switches models if the cache is cold Not exactly. It can also make sense if the cache is hot to switch models. For example, we might currently be on Deepseek and the next task is SO HARD that it doesn't make sense to not use frontier (1 turn to crack versus 100 turns for Deepseek to crack). Likewise, the router may judge that it's likely that the next few set of tool-calls will be ridiculously easy, an…
Seems like it might be more advantageous to just adjust reasoning effort to retain cache. Maybe in some exceptional cases where there will be a ton more inference to solve the problem, but going significantly dumber in that case seems counterintuitive.
I can really only see the utility of things like spawning subagents to a lower tier model from another provider, and that's something harnesses can already handle (ie. give model specs for certain delegation roles).
Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money
#28Model routing seems like a piece of the Ai stack that will quickly distill into industry if it is even that useful. I remain unconvinced that you need on the fly choice making beyond provider downtime. More likely you want to evaluate some and then settle on the model-agent-task pairings that work for you
Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money
#29Earlier quoted context omitted.
> So this only switches models if the cache is cold Not exactly. It can also make sense if the cache is hot to switch models. For example, we might currently be on Deepseek and the next task is SO HARD that it doesn't make sense to not use frontier (1 turn to crack versus 100 turns for Deepseek to crack). Likewise, the router may judge that it's likely that the next few set of tool-calls will be ridiculously easy, an…
Seems like it might be more advantageous to just adjust reasoning effort to retain cache. Maybe in some exceptional cases where there will be a ton more inference to solve the problem, but going significantly dumber in that case seems counterintuitive. I can really only see the utility of things like spawning subagents to a lower tier model from another provider, and that's something harnesses can already handle (ie.…
caching is per model, it does not transfer between them
Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money
#30[deleted]