Add EU Sovereign Routers + Models / Filter by Model Training

[dfigos-2000]

Hi,
I was wonder if its possible to request the addition of the following Routers/Model providers?

• https://abacus.ai/ Not EU but I heard good opinions
• https://greenpt.com/
• https://www.eurouter.ai/
  And many other EU based providers that can exist.
  Also, it could be good to advertise to each model, whether is API based, web auth, free tier, etc, that they can be training their models with users requests or not. This can be done maybe putting a new filter in Providers tab -> a coloured ball that says that the model IS or NOT training their models.
  This could be useful in environments where data sovereignty is important, for example, when dealing with intellectual property and stuff like that.

Thanks!

[diegosouzapw]

Hey @dfigos-2000! The second half of your ask is the more valuable one, and it is already half-built in the codebase — which changes what needs doing.

The training flag partly exists. trainsOnPrompts?: boolean is defined at open-sse/config/freeModelCatalog.ts:35, populated in freeModelCatalog.data.ts (13 of 444 entries carry it today, all kilo-gateway), carried through the Radar feed (src/lib/radar/feedSchema.ts:183) and already rendered as a badge on the Radar page (src/app/(dashboard)/dashboard/radar/RadarCatalogTable.tsx:322-327).

So the concept shipped — but scoped to the free-model catalog on the Radar page, and as a badge, not a filter. A paid or API-key provider has nowhere to carry the flag at all. That is precisely the gap you hit.

Opened #12938 to close it, with the tri-state design your use case demands:

• true | false | unknown, defaulting to unknown — and unknown renders as unknown, never as "safe". For IP-sensitive traffic, an unsourced "does not train" claim is worse than no claim, because you would act on it.
• Every non-unknown value carries a source URL (ToS/DPA), so it is auditable and re-checkable when the upstream quietly changes terms.
• Filterable in the Providers tab, reusing the plumbing from feat(providers): custom notes, performance tags & tag-based filtering for providers/models #12127 and feat(api): add filters to GET /v1/models and /api/models #12476 rather than growing a parallel filter.

Your coloured-ball idea is right for the display; the hard part is the data behind it staying honest, so that is where the issue puts its weight.

On the providers themselves — greenpt.com, eurouter.ai and abacus.ai are ordinary provider additions and belong on their own track, not blocked by the above. If you want them prioritized, open one request per provider with the API docs URL and whether it is OpenAI-compatible; that is what determines whether it is a registry entry or a full executor + translator. I check docs/reference/REMOVED_PROVIDERS.md before adding any of them.

One correction worth stating plainly: EU-hosted and "does not train on your prompts" are independent properties. A provider can be in-region and still train, or be US-hosted with a contractual no-training term. The filter has to encode the actual term, not the jurisdiction — otherwise it gives false comfort on exactly the traffic you are trying to protect.

[dfigos-2000]

Thanks for the reply @diegosouzapw. Quoting you:

Your coloured-ball idea is right for the display; the hard part is the data behind it staying honest, so that is where the issue puts its weight.

Here there is something I do not understand or do not have knowledge about. There are providers, which can be also model gateways that can, in someway, store their models in their servers and they do not train any model using the user's data, according with regulations and stuff like that. However, I'm not sure if this applies 100% to model gateways that connects with other model providers. This I something that should be studied.

Indeed, the user should acknowledge that the fact that a model/provider is tagged/filtered as Model-Training/No-Model-Training does not fully mean that they will 100%/0% train models with the requests and data that were provided, and that they are filtered according with what the website says. So... is more or less a faith-jump ("Salto de fe" in Spanish). So... they can be filtered but maybe it would be useful to add that the statement is dependant of the terms and conditions that the provider/model/router has, and that the user is invited to read them. In order to filter them for a fast deployment for a next OmniRoute version, a fast AI can consult fast and diagonally whether the listed models/providers trains with user's data and filter them beforehand.

One correction worth stating plainly: EU-hosted and "does not train on your prompts" are independent properties. A provider can be in-region and still train, or be US-hosted with a contractual no-training term. The filter has to encode the actual term, not the jurisdiction — otherwise it gives false comfort on exactly the traffic you are trying to protect.

I understand this idea/meaning separation and I thank you for noticing that. I meant that in the future (it depends in how this project will grow and the users that are using it, which I expect and hope that more and more they will use), maybe EU users that are concern about their data could be sent to out-region provider/models, which can be problematic for them. So I know that EU-based model/providers does not mean that they will not train with the data, rather than the data will be managed and stored inside EU servers which are compliant with GDPR guidelines. So... maybe also could be useful to tag a provider if they are GDPR compliant.

About the providers I suggested, I will do what you suggested.

[dfigos-2000]

I was checking Abacus and I could not found any Docs! So it can be put in standby. Maybe another user will provide more info, if this provider is useful to have :)

[diegosouzapw]

@dfigos-2000 — sensible call, and thanks for saying so instead of leaving it open. No docs means no way to write a registry entry that is not guesswork, so standby is the right state for Abacus.

The other two are moving. Both now have their own tracking issue, and yours was the input that made them specific rather than a wish:

• feat(providers): add GreenPT as an OpenAI-compatible provider (passthrough) #12986 — GreenPT
• feat(providers): add EURouter as an OpenAI-compatible gateway (147 models, passthrough) #12985 — EURouter

The training-flag half of your original request is #12938, which is the part I think actually matters most here. If you come across the ToS or DPA clause for either provider stating whether they train on submitted prompts, post the link in #12938 — that issue requires a source URL for every non-unknown value, so a link is worth more to it than an opinion.