Frequently asked questions
Most pages on this site make a claim. This one answers ten questions a buyer normally has to send us email to get. Where the answer is "not yet", it says "not yet" — a page that overstated would be worth less than no page, because every other page here is written to be checkable.
Where are prompts and completions processed?
On the endpoint the router selects, which is a named region, and the response tells you which one: the llmeu block on every completion carries inference_region, endpoint_id and sovereignty_class. A residency value in your policy constrains that set before selection; it is applied as a filter, not as a preference, and catalogue_unknown is never routable. Two limits on that sentence. First, region rows are configuration data, not evidence of running machines or confirmed operator contracts — the residency doc says this in its own words, and we repeat it here rather than only there. Second, on this deployment there is no GPU: the default backend is the mock, whose region is dev-mock, and the mock does not represent a place. See "What happens if there is no GPU?" below. The API that does this is a Node process, not part of this static site — llmeu.com itself answers pages, it does not process requests.
apps/api/src/inference.mjs:457 (the llmeu response block), packages/router/src/engine.mjs:467 (residency is applied before scoring), packages/inference/src/mock.mjs:7 (MOCK_REGION = dev-mock), packages/shared/src/catalog-schema.mjs:64 (the routable classes)
Are prompts and completions kept?
No. Prompt and completion bodies are not written to the database. Each call stores metadata — model requested and used, version, endpoint, region, sovereignty class, the router's reason, token counts, latency, cost, status — and the row's prompt_stored is 0. The two body columns exist in the schema and are null. The enforcement is code, not policy prose: a request whose effective retention is anything other than zero is refused, with 403 retention_exceeds_policy if it asks for more than your policy permits and 501 retention_not_implemented if it is permitted but unimplemented. Policies can store 24h, 7d or 30d as choices; storing the choice does not enable storing the body. If a trace ever shows prompt_stored other than 0, that is the one-page answer to "what did you keep" — and you can check it yourself with jq, as the evidence page shows.
packages/shared/src/db/schema.sql:295 (prompt_stored and the two body columns), apps/api/src/inference.mjs:83 (IMPLEMENTED_RETENTION = zero), apps/api/src/inference.mjs:89 (403 retention_exceeds_policy), apps/api/src/inference.mjs:97 (501 retention_not_implemented), docs/product/decisions.md:62 (ADR-003)
Do you train on customer data?
No — nothing in this product is in a position to. There is no training or fine-tuning code path in the API, the web process, the router or the shared packages. The API orchestrates a request to a backend and meters it; there is no dataset ingestion, no corpus store and no fine-tune job. Prompt and completion bodies are not written to the database, so there is not even a stored corpus to train on. That is a statement about our code, not about every model's upstream training data. Models that were trained on other people's data, or that disclose their training data, are described on their own cards, with sources, and some of those cards say the training data is not published.
apps/api/src/inference.mjs (the whole request path: orchestrate, meter, never persist), packages/shared/src/db/schema.sql (no dataset or corpus table), packages/content/models.mjs:196 (a card that says the training data is not published)
What happens when no endpoint satisfies my residency policy?
The request fails. It is not downgraded to a nearby region, and it is not sent anywhere else: 409 no_endpoint_for_policy, with the reason in the error body and the excluded endpoints named on the trace. Residency is applied before scoring, and failover only ever moves inside the set the router already filtered — which is why a retry cannot quietly escape the rule you set. The code says it in one sentence: "No endpoint satisfies residency {x}. Residency is never relaxed silently." What to do about it: name a region or class your policy does allow, widen the policy deliberately (a decision, with a changelog entry), or accept that no route exists for that model under that rule. A 409 is the product working as designed; the failure mode it prevents is a request that "succeeded" somewhere you did not allow.
packages/shared/src/errors.mjs:59 (no_endpoint_for_policy), packages/router/src/engine.mjs:370 (the failure, before scoring), packages/router/src/engine.mjs:507 (failover cannot leave the filtered set), apps/api/src/inference.mjs:137 (retention is checked before routing)
Is this GDPR-compliant or certified?
We do not make that claim, and we will not — not "AI Act compliant", not "certified", not "Official EU". LLM EU is a private company. It is not an EU institution and not a conformity assessment body. "Verified" on this site means documented, not legally certified: it is a disclosure checklist, scored by whether a card states its residency, provider, version, retention, subprocessors and licence, with links. What we can state is what the code does, and where the gaps are: zero retention enforced in code; API keys stored as scrypt hashes with the secret shown once; every customer query scoped by organization id; per-IP, per-key and per-org rate limits; request bodies capped and validated. What is not done: no independent penetration test; no third-party audit; the privacy notice and terms are summaries; the DPA is an unreviewed, unsigned template; the subprocessor inventory is incomplete. The security page and the legal index list those gaps in their own sections; this answer points at them rather than paraphrasing them into something softer.
docs/product/decisions.md:115 (ADR-006 — no compliance stamp, in any string), apps/web/server/pages/docs.mjs:537 (SECURITY_COPY: the control and gap list), apps/web/server/pages/docs.mjs:643 (LEGAL_READINESS: per-document readiness)
Is the API OpenAI-compatible, and what does a customer change?
The base URL, and nothing else. /v1/chat/completions accepts the official request shape and returns the official response shape — choices, usage, streaming as SSE — so the official SDKs work after you point them at us. Extra body fields are ignored rather than rejected, so a newer SDK cannot break an older route. What is added is optional and additive: a namespaced llmeu object in the request (residency, task, retention, data_class, policy_id, max_usd_per_1m, allow_partners) and an llmeu block in the response carrying trace_id, model_used, model_version, provider, endpoint_id, inference_region, sovereignty_class, route_reason, policy_id, retention and cost estimates. Not offered, deliberately: /v1/completions (501), n > 1 (400), embeddings unless an embedding model is actually hosted. The llmeu block may gain fields; removing one would be a breaking change and would appear in the changelog.
docs/product/decisions.md:78 (ADR-004), apps/api/src/app.mjs:554 (the response the client reads), apps/api/src/app.mjs:255 (501 on /v1/completions), apps/web/server/pages/docs.mjs:403 (the written compatibility contract)
What happens if there is no GPU?
The MockBackend answers, and it says so in its own output: the completion names the model and the region, states that no real weights ran, and says how to turn on first-party inference (VLLM_BASE_URL, then the gpu_enabled flag). Its region is dev-mock, which is not a place, and on a mock call there is no charge. GET /readyz reports which backends are up, and readiness is not satisfied by an endpoint row that says up — a managed runtime must actually report healthy, because the whole point of that probe is to catch a node whose weights are still loading. The backend registry refuses to substitute the mock for an endpoint whose runtime is vllm; it throws instead. The honest summary is uncomfortable and worth stating plainly: this deployment has no GPU, so a call here is a demonstration of the pipeline, not a model run. A mock success is a success on the wire; it is never presented as a real model run.
packages/inference/src/mock.mjs:49 (the answer that names the mock), apps/api/src/app.mjs:157 (readiness includes managed backends), docs/product/decisions.md:131 (ADR-007 — the registry refuses to fake a GPU runtime)
What does a model card marked catalogue_only mean?
It means we catalogue the model and do not serve it. The card is reference information — provider, licence, context window, where the provider says it runs, sources for every figure — and no LLM EU endpoint answers for it. Ask the API for it and you get 404 hosted_unavailable, with the note "catalogue only — not hosted on LLM EU yet"; a page for it quotes no price, because a price for something nobody can call is a claim with nothing behind it. Requests to that model go to its provider directly, under that provider's own terms, and the model card says exactly that. The opposite badge is not a stronger promise either: a model we host is hosted in a named region with a named sovereignty class, and that is the claim you can check on the trace. Neither badge is a compliance statement.
packages/router/src/engine.mjs:325 (the router rejects the kind), apps/api/src/app.mjs:235 (404 hosted_unavailable with the note), apps/web/server/pages/docs.mjs:446 (pricing skips catalogue_only)
How do pricing and credit work today?
Prices are per million tokens in and out, stored per endpoint and shown on the pricing page and the model cards, in EUR, derived from one published USD rate; the ledger itself stores USD micros and writes the rate onto every row, so a past invoice can be reconstructed exactly. Every completion returns cost_estimate_usd and cost_estimate_eur, and a trace records the cost in both. Policy limits — a per-million cap and a daily cap — are checked before routing, so an over-budget request is refused rather than run. Card payments are not enabled on this deployment, and nothing adds credit automatically: there is no invoice run and no operator credit path yet. The console shows what has been spent and what remains. If a stripe_enabled flag is turned on, the credit handler accepts a posted amount without verifying that a payment happened — which is why the flag must stay off until payment verification is implemented and tested, and why we say that here instead of offering a checkout button.
docs/product/decisions.md:148 (ADR-008 — micros stored, EUR displayed), apps/api/src/inference.mjs:457 (per-request cost estimates), apps/web/server/pages/docs.mjs:463 (the pricing page states payments are off), apps/web/server/pages/docs.mjs:559 (the credit handler does not verify payment)
Can we self-host?
Not through anything we ship today. There is no self-hosted distribution: no container image, no installer, no on-premise licence, no support contract for running this in your own estate, and this repository is not offered as a supported deployment. The console's team surface exists, but organization roles are not complete role-based access control, and that is documented rather than implied away. What the catalogue does carry is a residency class called on_prem_customer — "the model runs inside infrastructure the customer controls" — and it is a classification of an endpoint's ownership and operation, not an offer from us. Many of the models in the catalogue publish open weights, and their licences (some non-commercial, some research-only) are on the cards with a link, so you can evaluate running them yourself; that is a decision about someone else's weights and someone else's licence, not a self-hosting product from LLM EU. For an on-premise conversation, the enterprise page is the right door, and it is honest that the arrangement does not exist yet.
packages/router/src/engine.mjs:12 (on_prem_customer appears only in residency mappings), packages/shared/src/catalog-schema.mjs:84 (its definition), apps/web/server/pages/docs.mjs:517 (incomplete RBAC, stated), packages/content/models.mjs:695 (an open-weight licence on a card)
If an answer here is wrong, it is a defect and we treat it as one. Where the code and this page disagree, the code wins — and the evidence page, the security page and the legal index are the places we keep the rest of the uncomfortable detail rather than repeating it ten times.
Questions this page does not answer: mail@llmeu.com
Evidence and verification · Security · Legal · Accessibility