Auriko

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.

@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!

@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.

Congrats! A trading desk for LLM calls is a framing I haven’t seen before and it clicks immediately, model costs do behave like a market. My question: when Auriko routes a call to a cheaper model to save money, how do I protect quality? Can I set a floor per task type? Saving 40% on inference means nothing if my customer-facing outputs get worse and I find out from a complaint.

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.

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"

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?

@zxy_action1 that continuous re-evaluation makes sense. one more - for a brand new user with zero history, what does auriko default to on the first request? does it start price-optimized until it has enough signal to classify usage pattern, or is there some other cold-start heuristic (like guessing from the client/integration used)?

@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 a provider with deeper cache discount instead of chasing a cheaper provider on headline token price.

@zxy_action1 that makes sense as a per-user classification. does it ever re-evaluate mid-session though? like if a heavy user's session goes quiet for a while and the cache would've gone cold anyway, does Auriko notice and switch back to price-optimizing, or is the "prefer cache-sticky routing" decision fixed once it's made for that user

@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.

@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.

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

@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.

@galdayan This is a sharp and very deep question! Yes, the evaluation happens on every request (including mid-session). Cost is computed as the expected cost of the full session, not just the current request. If a cache goes cold, that changes the cost expectation for subsequent requests, and our model accounts for that. For example, if the routing engine chooses provider A for some session, and if cache is warm -- our routing engine will likely stick with that provider. But if the cache goes cold, the equation changes. But regardless of cache-state, we always estimate subsequent cache hit likelihood and conversation length, and compute expected cost for the remaining session.

As someone routing agent traffic across providers, the cost-arbitrage-as-trading-desk framing lands — but the failure mode I'd test first is a venue going bad mid-run. When the cheapest provider starts erroring or its latency spikes, does Auriko fail over inside the same request (retry to the next-best path transparently), or does the caller eat the error and only re-route on the next call? And does the 30% cost-reduction number account for retry spend, since a cheap-but-flaky path can net out more expensive once you add the retries?

@hazy0 Yes. Auriko is designed for that failure mode, not just cheapest-route selection. For retryable failures before a usable response is returned, like errors or rate limits, Auriko falls back to the next high score eligible path. The 30% cost-reduction number is from real-world usage experiments - retry behavior and provider errors are included. A cheap-but-flaky path is not really cheap. The fallback chain is also logged transparently!

Appreciate the specifics — "a cheap-but-flaky path is not really cheap" is exactly the right way to price it. On the transparent fallback log: does it break out per-attempt latency and cost so I can attribute how much of a request's spend went to retries vs the winning path, and can I cap fallback hops per request to bound tail latency when every eligible path is degrading at once?

the per-workflow API key idea for calibration makes sense, hadn't thought about separating traffic patterns that way. do the routing weights get set once per key or can you adjust them on the fly if a workflow's priorities shift mid-project