We're building an AI gateway in Stockholm and launching here soon. One thing keeps surprising us. Developers say they don't care about data residency, then their B2B customers ask about it in every procurement call and suddenly they do. So we made EU data residency the default instead of an enterprise add-on. Curious what this community thinks. When you pick AI infrastructure, does the region ever factor in, or is it purely latency, price, and model access until a customer forces the issue?
The "one sub-processor covers every model" detail is the actual unlock here - anyone who's tried to get a GDPR-conscious AI stack signed off by legal knows the real bottleneck isn't picking a good model, it's getting a dozen separate DPAs approved for a dozen separate providers. Collapsing that into one sub-processor while still giving access to 30+ providers is solving the boring-but-critical part nobody else seems to prioritize.
Curious how the per-team spend caps and audit trails hold up once an
agent is calling multiple models in a single task autonomously - does
a spend cap trigger mid-chain and fail gracefully, or does it need to
be checked before each individual model call? That failure mode seems
important for anything running unattended in production.
Looked at OpenRouter for the same "one key, many models" idea, but it
doesn't solve the EU data residency or single-sub-processor angle at
all. For anyone building in Europe who actually needs to answer "where
does this data go" to a legal or compliance team, that's the whole
ballgame, not just a nice-to-have.
Hey Product Hunt! Felix here, one of the founding members of Opper.
We're launching Opper, Europe's answer to OpenRouter: one API key to 300+ models across 30+ inference providers.
One integration to find the right model for any task, run it, and switch the moment something better ships. OpenAI, Anthropic, Google, Meta, xAI, Mistral, DeepSeek, plus the leading open-weight labs.
The reason we built it: there is no single best model. The lead changes every week, and wiring up a new provider every time it changes means new contracts, new SDKs, new billing. With Opper that's one integration, no new contract per model or provider.
Being European isn't just where we're incorporated, it's the product. Around half of our 30+ providers run inference in Europe, including sovereign hosts like Evroc, Berget, Geodd, and many more.
EU data residency, audit trails, and PII controls are built in, not bolted on. If you've ever needed the best models AND a straight answer on where your data runs, that's us.
On the control side: per-team spend caps and full cost visibility. Think Stripe for AI spend.
Where we are today: 50,000+ developers, powering AI for 10M+ end users, €3M raised from the investors behind Lovable.
You might already know us without knowing the name: we're the team behind the viral Car Wash Test, where we asked 53 models whether to walk or drive 50 meters to a car wash and only 5 said drive: opper.ai/blog/car-wash-test
That's now a thing you can do yourself with AI Roundtable: put any question to 200+ models and watch them answer and debate at askroundtable.ai.
I'll be in the comments all day. Would love to hear what would make you switch gateways, or what's kept you from using one at all.
how do the spend caps behave mid-chain when an agent calls several models back to back - does it fail gracefully or need pre-checking before each call?
@ulykbek11 Spend caps are enforced once per request, at the gateway on the way in, not per model call. So when an agent chains several models back-to-back (or falls back primary→fallback₁→fallback₂), the cap is checked once up front and never re-checked between calls. You don't need to pre-check before each call, and nothing gets killed mid-chain: if you're over a cap, the next request gets a clean 402 before any model runs. Two things worth knowing:
Metering is eventually-consistent (spend is debited after each call and batched before it hits the ledger), so a long chain or a parallel burst can overshoot the cap slightly before the block kicks in on the following request. For "stop runaway spend" that's exactly what you want; if you need a hard per-call ceiling, gate on balance yourself between calls.
Failed fallback hops are free — you only pay for the model that actually delivers tokens, not the ones that erred and fell over. And if you're already over the cap before the call, you never reach the fallback at all; you get the 402 up front.
@ulykbek11 @felix94123 that eventually-consistent metering answer is a lot more honest than most gateways would give, "gate on balance yourself if you need a hard ceiling" is a real caveat, not marketing. separate question given the EU-residency pitch: does the metering/billing pipeline itself (the batched spend ledger, not the prompts) ever transit outside the EU, or is that boundary held for billing metadata too
Congrats on the launch! The EU-hosted angle is smart, that's usually an afterthought for most teams. Does it route to EU inference automatically, or do you choose that per request?
Thanks @irahimiam! You can either set it as a fixed rule in your route settings or choose EU as a region when setting the model in the platform. You can also filter in our public model list and copy the API ID directly: https://opper.ai/models?region=EU
Congratulations on the launch! I'm new to gateways and have questions about the setup. First, how does my data stay in the EU if a request goes to a US-hosted model like Claude or GPT? Or the EU residency is only for the models you host in Europe? And second, if I mostly use one EU model, what does routing give me over just calling that model directly? Thank you!
Thanks@alieksia ! For your data to stay fully within the EU, you have to choose a model with EU hosting availability. We offer this out of the box for almost all models, even for leading ones like Claude Opus 4.8 with several providers, so you can even have a fallback. Fallbacks is also why you would want a router, imagine you use Claude Opus 4.8 on AWS Bedrock and they have an outage, then your app / access is also down. By choosing another provider, e.g. Azure as a fallback, you ensure that you have continued access to Opus 4.8. And outages / ratelimits have been very common in the past. There are many more reasons, like having the ability to switch to other models for specific tasks so you don't pay $$ premium opus tokens for a basic task that 10x cheaper open-source models can easily handle.
Very cool. So basically Opper can guarantee that my data never leaves the EU if I use models hosted in the EU?
Thanks @tom_dickson1 and yes that's exactly right. You can even set this as a fixed routing rule so you or anyone in your team can't switch the region by accident. Happens more than one would think :)
@felix94123 nice! I have been using Evroc and Nebius for EU sovereign tokens but they are flaky. All of a sudden Nebius API for some model returns error codes. So it makes sense to aggregate these token providers which has far worse API uptime then what we are used to with AWS/GCP etc. They are also slow with getting the latest Kimi models. Evroc is always 3 months behind on the latest Kimi releases it feels like.
@tom_dickson1 yea having fallbacks even for sovereign hosted models is still crucial, we have 15+ EU hosting providers so you can have multiple fall back options on the same model, still in the EU not risking any downtime if one provider has an outage. And out of all these, one will be the first to add the latest model, which you then have immediate access to, instead of waiting.
the single EU sub-processor covering everything is the detail that actually matters for GDPR compliance. most AI gateway solutions technically run in Europe but still have US-based sub-processors in the chain, which creates the same data transfer headache you were trying to avoid. the drop-in compatibility with existing SDKs is smart too, switching costs are the main reason teams stay on non-compliant infrastructure longer than they should. curious how latency compares to going direct to anthropic or openai for european users?
Congrats on the launch @felix94123 — the single-EU-sub-processor + drop-in SDK combo is a genuinely sharp wedge against OpenRouter for anyone stuck in a procurement conversation. 👌
Two things I'd love to understand as someone building agents on top of gateways:
When an agent is mid tool-call loop and a provider errors, how does the fallback behave across providers whose function-calling and streaming semantics differ? Does the tool-call schema get normalized so the loop survives an Anthropic→Azure hop, or can a partial streamed response get lost on the switch?
And beyond the one-line Claude Code setup — is model selection programmable per task (route by task metadata / an MCP tool the agent calls), or always an explicit model + fallback list you configure up front? Curious if there's any automatic quality-aware routing vs. cost-only.
Thanks! for more info RE caps and audit trails please check our docs and control plane detail page
https://docs.opper.ai/
https://opper.ai/ai-control-plane