Launching today
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/llm-cost-arbitrage
Auriko
Agnes AI
@ridhwikvinod lol looks like you are a pro on OTC trading! Don't worry about the performance - the cost is optimized without compromising the quality of models!
Auriko
@ridhwikvinod Great question, and we agree. Cost savings are only useful if quality stays predictable.
Quality control starts with explicit model constraints. In Auriko, the model catalog uses truthful model identities, and users can specify the exact model they want, including quantization where relevant. Routing then stays within those boundaries. We also evaluate models before adding them to the Auriko catalog.
Optimization is about choosing the best provider/path for a model. Under the hood, Auriko computes a composite routing score using live signals that represent expected cost, TTFT, latency, throughput, and reliability. You can use the default strategy, choose different strategies for different workflows (we recommend using different api keys for different workflows to maximize our calibration engine's and improve your cost savings), or specify your own routing weights. For example, if throughput matters most for a use case, you can increase the throughput weight.
treating LLM providers as trading venues is a genuinely smart framing from people who understand arbitrage. token price differences between providers are real and most teams just pick one model and stick with it out of inertia. the cache behavior optimization is the part i'd want to dig into more, prompt caching can drop costs dramatically on repetitive agent workloads but only if you're structuring requests to actually hit the cache. does auriko handle that automatically or does it require some setup on how you're sending requests?
Auriko
@shubham4real Love this question! Auriko handles the provider side automatically, but we still recommend following prompt-caching best practices since we do not see or log user's prompt (we have a Zero-Data-Retention policy!)
When you route through Auriko, we account for each provider’s caching behavior before sending the request: whether the model supports caching, how cache pricing works, and which route is likely to be cheaper for that workload. For supported providers, Auriko can also apply the right cache hints automatically, like Anthropic cache_control, OpenAI prompt_cache_key / retention, or session affinity where that helps reuse. We also normalize cached-token and savings reporting in the response. The part we still recommend users do is keep reusable context stable: system prompts, tool schemas, few-shot examples, long instructions, repeated RAG blocks, etc.
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"
Auriko
@galdayan Yes! The router accounts for cache state. We also calibrate routing against each user’s usage pattern. For example, if you are a heavy coding-agent user with rapid-fire requests, large context, and long conversation sessions, that pattern becomes an input signal to the routing engine. In that case, Auriko may prefer on a router with deeper cache discount instead of chasing a cheaper router on headline token price.
the cost angle makes sense but I'd worry about behavioral drift - even at the same nominal price point, different providers running "the same model" can have different quantization, latency profiles, or subtle output differences. if you're routing a request to whichever venue is cheapest at that moment, how do you keep output consistency for something like a customer facing agent where behavior needs to stay predictable
Auriko
@omri_ben_shoham1 Very valid concern, and we are very aware of this concern. Cost optimization only works if quality stays predictable.
We gate the Auriko model catalog and make sure each model is represented truthfully, including quantization. Instead of optimizing for wide inference provider coverage, Auriko optimize for inference provider's quality and credibility. Users can specify the exact model they want, and optimization does not mean quietly swapping to a lower-quality variant. We also evaluate models before adding them to the catalog.
Optimization is about choosing the best provider/path for that model. Under the hood, Auriko computes a composite routing score from live signals across expected cost, TTFT, latency, throughput, and reliability. You can use the default strategy, choose different strategies for different workflows, or specify your own routing weights. We also recommend using separate API keys for different workflows, so our calibration engine can learn each traffic pattern more cleanly and improve cost savings. For example, if throughput matters most for a use case, you can increase the throughput weight.
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.
Auriko
@crystalmei 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.
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?
Auriko
@longway1 Thanks for the question Kevin! Our data engine actively tracks model performance - latency, throughput, reliability, etc. The routing engine computes a composite score for each available route.
Users can choose preset routing strategies depending on what matters most for a workflow, like cost, TTFT, or throughput. Power users can also set custom routing weights for more fine-grained control.