Rohit Agarwal, Andrew Liu and Kevin W. are building Tokenless, an LLM router that starts each request on several models, watches their early work and keeps the model that appears most likely to finish successfully. Kevin W. publicly announced Tokenless on LinkedIn in July.
The San Francisco founders are making a precise bet about AI costs: developers often pay frontier-model prices before knowing how difficult a request will be. Tokenless inserts itself between an application and model providers, then tries to make that decision after generation has begun. Tokenless exposes OpenAI- and Anthropic-compatible endpoints, allowing developers to redirect existing API calls instead of rebuilding their applications around a new interface.
Agarwal brings the clearest research connection to that problem. He is a Princeton computer science PhD student advised by Elad Hazan who works on mathematics for AI, agent alignment and inference pipelines. Agarwal previously completed an electrical engineering and computer science degree at UC Berkeley, where Liu and Kevin W. also studied. His published work includes an inference pipeline that combines off-the-shelf models for competition mathematics, an academic version of the same underlying question Tokenless is commercializing: how to assemble available models into a system that performs better for a given cost.
In his LinkedIn post, Kevin W. said Tokenless would be part of Y Combinator's Summer 2026 batch. The Tokenless website separately describes Tokenless as backed by YC. YC says its standard terms commit $500,000 to each accepted company, split between $125,000 for 7% and $375,000 on an uncapped most-favored-nation safe.
Letting models begin before choosing one
Most LLM routers inspect a prompt, estimate its difficulty and send it to a model before generation starts. The open-source RouteLLM framework, for example, is a cost-and-quality routing framework for serving and evaluating LLM routers.
Tokenless says it makes the choice later. Tokenless fans a request out to several models, observes their partial responses or reasoning traces, selects one when it appears to be on track and cancels the rest. Tokenless calls the approach automatic model switching, although the mechanism resembles a short speculative race among models.
That distinction gives the founders access to information that a prompt-only router lacks. Two requests that look similar at the start can diverge once models attempt them. A weaker model may quickly find a workable path on one task and stall on another. Tokenless aims to detect that difference while there is still time to stop the expensive run.
The economics depend on how quickly Tokenless can choose. Every parallel attempt consumes inference resources, even when Tokenless does not pass the discarded work through to the customer's bill. The savings from selecting a cheaper model must cover the cost of those canceled attempts, the routing infrastructure and any added latency. Tokenless also becomes another system in the request path, where outages, provider changes and incorrect selections can affect production applications.
Those trade-offs explain why the compatibility layer matters. Developers can create an account and test Tokenless with limited integration work before deciding whether the savings justify another dependency.
The benchmark claims are moving with the models
Tokenless's homepage says its router can maintain frontier-level quality while cutting inference bills in half. Tokenless reports that a configuration called PRO solved 72% of TerminalBench 2.1 tasks at $0.32 per task, the same solve rate it listed for Opus 4.8 at $2.41 per task. On LiveCodeBench, Tokenless reported an 89% solve rate for PRO, compared with 88.9% for Opus 4.8.
Those are Tokenless's own benchmark results. Tokenless has also displayed a different comparison spanning tau3-Banking, Terminal-Bench 2.1 and DeepSWE 1.1, with newer model labels and an average 40.2% solve rate for Tokenless Pro. The changing tables show how quickly a routing product's reference set can age as providers release models and adjust prices.
Public coding and agent benchmarks provide a controlled comparison, but customer traffic will determine whether the pitch holds. Prompt distributions, cache hit rates, response lengths, latency limits and retry behavior can move the bill substantially. A router trained around coding agents may also behave differently on support, extraction or conversational workloads. Tokenless's calculator illustrates the sales argument with a hypothetical customer spending $40,000 per month on LLMs. Under editable routing assumptions, Tokenless estimates a $26,000 bill, a 34% blended savings rate and 42% of requests rerouted. Tokenless explicitly says the result depends on the customer's traffic and published model prices.
A valuable position between applications and model providers
Tokenless is entering a model-routing market that has already drawn large infrastructure investments. OpenRouter announced a $113 million Series B on May 28 after expanding from model access into quality-aware routing, failover and enterprise controls. Portkey raised a $15 million Series A on February 19 for its AI gateway and control plane, before Palo Alto Networks completed its acquisition of Portkey on May 29.
The attraction is straightforward. A routing layer sees which models an application uses, how much each request costs and where failures occur. That position can expand into observability, budgets, security policies, fallbacks and procurement. Tokenless is starting with the narrower promise of choosing models after watching them work.
Tokenless also uses Ramp's AI Index in its calculator, applying an 11.0% monthly AI-spend trend for June 2025 to June 2026 to illustrate how unmanaged model costs can compound. The exact savings case will depend on workload mix, provider prices and how quickly Tokenless can stop losing runs.
That gives Tokenless a defined initial customer: developers running enough agent traffic for small routing improvements to produce material savings. Agarwal, Liu and Kevin W. now have to prove that observing a model's first steps yields a dependable signal before the parallel race consumes the money it was designed to save.