Auriko - Trading desk for LLM calls

Auriko treats LLM providers as trading venues and arbitrages the spread. Built by ex-quant traders, Auriko’s cost-arbitrage engine calibrates to each user’s request patterns and selects optimized inference paths based on token price, cache behavior, latency, reliability, and request quality. Auriko benchmarks show average 30% cost reduction against industry peers and direct providers. See the source:

Add a comment

Replies

Best
In a previous life, I traded options as a quant trader. When I started building with AI agents, I needed to switch models quickly across inference providers. A trader’s OCD for finding the lowest price kept pushing me to figure out which provider was cheapest. That sent us down the rabbit hole of comparing inference costs. We realized cost is not just the headline input/output token price. A huge part of our spend came from cache pricing, cache-hit efficiency, and routing choices. We ended up building a system to optimize all of that. And we turned it into auriko.ai.

Is Auriko mainly about monitoring and comparing LLM calls after the fact, or does it help decide where a call should go before it is sent? For developer teams, that distinction matters a lot, especially if they’re juggling quality, latency, and spend across different AI workflows.

 Great question! Definitely pre-request.

When a request hits Auriko, we build the available routing candidate set, apply hard constraints like capabilities, budget, data policy, parameter support, and availability. The routing engine scores every available candidate i across cost, latency, throughput, and success rate, then picks the best one based on your strategy

The request performance data feeds back into routing: we use it to generate provider health and performance signals, then use those signals to calibrate future routing decisions. So the main value is real-time routing, with observability data used to make the router smarter over time.

The prompt caching focus sounds valuable. A lot of teams know caching exists but do not optimize around it.

 Exactly. Caching is easy to know about but hard to price correctly, because every provider handles prompt caching differently, and cost is also a function of the user’s request pattern.

If we had a crystal ball and knew the exact content and timing of a user’s future requests, as well as each provider’s exact caching mechanism, we could compute the cost of the same workload across providers and pick the cheapest path. In reality, the problem is much harder because the information is incomplete. The user’s request pattern has to be estimated, and each provider’s prompt caching mechanism has to be probed and modeled correctly. That is where Auriko’s quant-trading-inspired infrastructure comes in, and how we are able to drive around 30% cost reduction.

Auriko’s core competence is our quant-trading-grade data pipeline, signal generation engine, and inference cost modeling. We track each inference provider’s prompt-caching mechanics, estimate users’ request patterns, and model inference cost with both provider and user signals in mind.

Our data pipeline also generates real-time signals on provider health, latency, and throughput.

The quality bar for production AI apps is high, so cache aware routing needs good observability.

Love the “trading desk for LLM calls” framing. Cost optimization across providers is becoming a real pain point as AI apps scale.

How do you balance cost savings with output quality and latency, especially for production workloads?

Michael... this is jaw-dropping. I am beyond impressed by such a novel yet robust approach to token-spend reduction. My budget loves this!

(my brain, however...? it immediately wants to set about reverse-engineering this mf to tune it towards revenue generation... 😈)

Great work!!

 Glad you like it!

I like that the focus is not just more models, but using the right route for each request.

This looks super useful for teams watching their AI bill climb every month. Congrats!

 Thanks!

Congrats on the PH launch! Modeling request patterns sounds helpful.

12
Next
Last