Auriko - Trading desk for LLM calls
by•
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: https://www.auriko.ai/reports/ll...
Replies
Triforce Todos
Congrats on the launch!
For teams running agents that have really strict latency requirements, can you set a hard ceiling on response time and let Auriko optimize cost within that constraint, or is it more of a balance between the two?
Can developer set their own priorities, like preferring lower latency over lower cost, or is the routing fully automatic?
someone on my team has been comparing different inference providers manually to keep costs under control. I'll definitely share Auriko with them because it could save a lot of effort.
How do you measure quality when routing across models? Do you use developer feedback, user behavior, retries, or some kind of evaluation layer?
Congrats on the launch! , Doesn't cheapest-per-request routing fight with caching though? If you hop providers to save on one call you lose the warm cache you built at the last one, and the next 20 calls cost more. Curious if the router accounts for that or just prices each call on its own.
ReplyMind
Big congrats 🙌 Auriko feels practical and fresh, excited to test how it streamlines collaboration.
The 30% cost reduction number, is that on top of what you'd already save by using OpenRouter or similar, or is that the comparison baseline?
quant background makes sense for this, arbitrage is fundamentally about finding mispriced spreads and providers pricing caching differently is exactly that. the tension I'd want to understand: prompt caching usually rewards staying on the same provider for a session so the cache stays warm, but a router optimizing per-request could bounce a session across providers chasing the best price each time and never let any single cache warm up. does the routing engine account for cache-state as its own signal, like "this provider already has a warm cache for this context, don't move away from it even if a competitor is nominally cheaper this instant"