Live data from Hacker News

Launch HN: Tokenless (YC S26) – Automatic model switching to save money

usetokenless.com

61–70 of 70 posts

Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money

#61
Deja-vù: 15 years ago I was working for AWS, and at some point (2010-2011) tens of startups came out to provide cost optimization, cloud switching, etc.

If memory serves well, I think none of them survived or had meaningful exits. I might be wrong. The main reason could be that this is a feature that gets commoditized really quickly.

Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money

#62
post #2

So 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…

[dead]

Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money

#65
post #59

How is this different from OpenRouter? I also developed something similar for my agent harness. It's based on model predictors and an exponential moving average: https://github.com/rush86999/atom/blob/main/docs/architectur...

There is no difference. It is just another metoo copy of OpenRouter, but "Backed by Y Combinator™"

Seems everybody is building routers. The data captured is the valuable part but it's a chicken and egg problem. I don't see a outsider succeeding here without critical user mass.

Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money

#66
Disclosure: I build a competing gateway.

We ended up doing roughly the session-lock you're describing — pin a conversation to whichever provider is already warm, reconsider only on a cold prefix — and what surprised me is that eviction was rarely the thing that broke it.

Any request that changed the prefix at all did: a tool definition added mid-session, a system prompt carrying a timestamp, retrieval that reorders context. Those all still look like a warm session to the router and are a full re-price in practice.

So the lock ended up being less "stay until eviction" and more "stay until something upstream invalidates the prefix" — and most of our savings came from stopping our own code from invalidating it, not from the routing decision.

Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money

#67
The benchmark number gets the click, but what decides adoption is whether someone can look at yesterday's traffic and see which turns went cheap and what that cost them in quality. Nobody hands routing to a gateway they can't audit after a bad output. Do you expose the per-turn decision, and can a team pin certain calls to a specific model when they need to? Worth saying plainly what querying multiple models at once does to latency, too.

Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money

#68
feeding an existing conversion with output and reasoning from model x to model y will have many side effects, most likely a degradation of perfomance and alignment. should be done at least within the same family and generation of models... I'm not a huge fan of routers

Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money

#69
We built something similar internally after AI spend on support-ticket triage kept beating estimates. Routing itself wasn't the hard part, it was that our dashboard only tracked immediate task completion, and had no idea a cheaper model had quietly produced a worse answer that the customer reopened a week later. We ended up tagging every response with which model handled it and joining that against reopen rate a month out, and the gap on the cheap tier was bigger than we expected going in. Curious if Tokenless has thought about exposing a delayed quality signal like that, not just pass/fail at the time of the call.

Re: Launch HN: Tokenless (YC S26) – Automatic model switching to save money

#70
I ran some tests last quarter with a similar multi-model routing setup focused on code completion tasks. Using an open-source Claude alternative combined with Claude-instruct for fallback, I saw about a 45% cost reduction compared to consistently hitting the Claude Code API alone, with latency penalties under 300ms for the fallback requests. The key was tuning the confidence threshold so that around 70% of calls got handled by the cheaper local models without sacrificing accuracy much.

One interesting data point was that for smaller completions (~50 tokens or less), open-source models like OpenHands outperformed cloud-hosted Claude alternatives in terms of 95th percentile latency—likely because no network involved. But for bigger, multi-file refactoring queries, fallback to frontier models was unavoidable to hit the 90+% pass rate. The dynamic routing balanced those two extremes to keep API spend down while still scaling.

That said, the caching layer remains a bottleneck. Changes in the input context or tool states quickly cold the cache, forcing more queries to the expensive model. For workflows with lots of sequential tool calls (e.g., automated code lint + formatting + test generation), the raw switch cost was around 15-20% overhead compared to fixed-model baselines until cache warm-up happened. This matches the experiences others have reported.

Post reply on HN