Liquid Inference: An LLM Router That Makes Providers Bid on Every Prompt

When Inference Cost Becomes a Bidding War

As large model applications scale into production, inference cost has become an unavoidable pain point for businesses and developers alike. The same model can carry wildly different price tags depending on the cloud provider or deployment setup — and manually comparing prices or switching providers is simply not practical. Liquid Inference offers a direct solution: turn the whole thing into a real-time auction.

Launched on Product Hunt, the product positions itself as an "LLM router." Its core mechanism works like this: when you send a prompt, multiple inference providers dynamically bid against each other, and whoever can deliver the lowest marginal cost wins the request. Users don't need to care about who's handling things under the hood — just send the request, and the system automatically routes traffic to the most cost-effective provider at that moment.

This model of "making the supply side compete for every request" essentially transforms traditionally fixed-price API calls into a live, market-rate exchange. For Agent applications with high call volumes, even shaving a few percentage points off each request adds up to something substantial over time.

Real-Time Bidding (RTB) was first deployed at scale in programmatic advertising: every time a user opens a webpage, an ad slot runs a full auction in milliseconds, with the highest bidder winning the impression. Liquid Inference transplants a similar mechanism into the LLM inference market — with one key difference: ad auctions seek the highest bidder, while inference auctions seek the lowest-cost provider. The logic is exactly reversed. This kind of "reverse auction" has precedent in cloud computing too. AWS Spot Instances let users bid on idle compute capacity at prices below on-demand rates. The logic in the LLM inference market is analogous — providers have excess capacity at different times and are willing to offload it at a discount. The router's value lies in capturing those price-gap windows in real time.

Built for the Agent Era

Liquid Inference places strong emphasis on compatibility. The official support list covers the most widely used Agent coding tools today — Claude Code, Codex, OpenCode, Cursor, Pi, Cline, and more — essentially spanning the smart coding ecosystem developers rely on daily.

This matters. As call volumes from coding Agents grow rapidly, inference bills often become a team's hidden largest expense. By inserting itself into the routing layer between tools and models, Liquid Inference lets developers plug their existing inference traffic into this bidding system without changing their toolchain at all.

The product also claims full multimodal support and access to hundreds of open- and closed-weight models. In other words, it can route to open-source model deployments (such as various Llama and Qwen variants) as well as closed commercial APIs. Broad coverage is essential — there's no room to maneuver on price if the supply side isn't deep enough.

Routing Strategy: Preset Rules and Automatic Algorithms

On the routing control side, Liquid Inference offers two modes. The first lets users build their own routing rule presets, defining under what conditions traffic should follow which path — for example, routing latency-sensitive tasks to certain providers and cost-sensitive batch jobs to the lowest bidder.

The second option is the official Auto routing algorithm, which hands decision-making to the system to weigh price, availability, and other factors holistically. For users who don't want to deal with configuration, this lowers the barrier to entry; for teams with precise requirements, preset rules preserve fine-grained control.

This "rules + auto" dual-track design is a common pattern in routing products. The real differentiation ultimately comes down to whether the bidding mechanism consistently delivers competitive pricing and how well the auto algorithm performs under real-world load.

LLM routers are a category of infrastructure tooling that emerged over the past two years as the multi-model ecosystem matured. The core idea is to insert a decision layer between the caller and the models, dynamically selecting the most appropriate model or provider based on task type, cost, latency, quality, and other dimensions. Comparable products include OpenRouter (which aggregates multiple APIs under unified billing) and LiteLLM (an open-source multi-model SDK wrapper). Competition in this space typically centers on three things: breadth of model coverage, quality of routing decisions, and the additional latency introduced. Liquid Inference uses "bidding" as the core mechanism for routing decisions. Compared to rule-based or capability-matching approaches, its advantage is real-time price optimization — but the tradeoff is heavy dependence on the scale of the supply-side ecosystem. The more providers participate and the larger the price differentials, the more valuable the system becomes.

Growth Design and Early Incentives

From a cold-start perspective, Liquid Inference uses a fairly classic growth playbook. New users can sign up for free with an email address, and the first 500 users receive $20 in free inference credits to experience the bidding router firsthand.

The referral mechanism is also clearly structured: fees generated by referred users earn 20% back as free inference credits, with 10% for second-level referrals. This kind of tiered rebate is common in early-stage developer tools, designed to leverage community word-of-mouth to rapidly expand the user base.

The product's Maker is Brett Harrison. On its launch day, it received 74 upvotes and 4 comments on Product Hunt, ranking 13th for the day under the API, Software Engineering, and Artificial Intelligence categories. Overall traction is solid but not a breakout hit — though the inference cost optimization space it targets addresses a very real need.

Questions Worth Watching

Bidding-based routing sounds elegant, but several details need validation in practice. The first is model consistency — the same request executed by different providers may yield differences in output quality, style, and stability, which poses a challenge for production environments that demand predictability.

The second is latency. The bidding decision itself introduces an additional layer, and engineering will need to demonstrate how the system keeps costs down without meaningfully slowing response times. Additionally, routing data through a third-party layer raises privacy and compliance concerns that enterprise users will scrutinize.

As an early-stage product that just launched, Liquid Inference has a clear concept and broad compatibility, making it worth experimenting with for developers and teams making high-frequency LLM calls. But whether it can actually spin up the "supply-side bidding" flywheel depends on the scale of providers it onboards, how durable its price advantages are, and its overall performance under real workloads.

Model consistency issues are particularly complex in LLM routing scenarios. Even with the same open-source weights (e.g., Llama 3.1 70B), differences between providers in quantization precision (FP16, INT8, INT4), inference frameworks (vLLM, TGI, TensorRT-LLM), and default sampling parameters can all lead to different output distributions. For generative tasks, this variance may be hard to notice. But for production scenarios requiring structured outputs (such as JSON-formatted responses) or high determinism, behavioral drift from the same prompt running in different execution environments becomes a real engineering problem. This is precisely why some enterprises, even under cost pressure, still prefer to lock in a single vendor — predictability is sometimes more valuable than price.