Keeping a request inside the EU

Some work cannot leave the European Union. If that is your situation, a sentence on our website is not much use to you — you need it to be a property of the request. It is.

Asking for it

One header. Everything else stays an ordinary OpenAI-compatible call:

curl https://app.elephantpool.ai/api/gateway/v1/chat/completions \
  -H "Authorization: Bearer $ELEPHANTPOOL_API_KEY" \
  -H "X-ElephantPool-Require: region:eu" \
  -H "Content-Type: application/json" \
  -d '{"model":"qwen3.8-27b","messages":[{"role":"user","content":"Hello"}]}'

A header rather than a body field because every OpenAI client library lets you set default headers, and almost none will pass an unknown body field through its own type checks. If you hand-roll the JSON, "require": "region:eu" works too.

The requirement is a prefix:value tag. region:eu is the one most people want; country:be narrows to a single country, and gpu:nvidia pins to a vendor when a kernel you depend on needs it.

What happens then

The scheduler hands that job only to a machine whose own tags cover what you asked for. Not "prefers" — only. There is no fallback to a nearer-but-not-quite host when the queue is busy, because a fallback would make the whole thing decorative.

If nothing in the fleet can satisfy it, you get an immediate 503 naming the requirement, rather than a request that sits in the queue until the clock runs out and reports a timeout. A wrong diagnosis two minutes later is worse than a right one straight away.

How a machine's location is established

From the address it connects from, resolved on our side against a local country database.

The machine is never asked. That is the part that matters: a host able to declare its own region:eu would make the guarantee worth nothing, so mahout does not send a country and there is no field for one. The tag is derived server-side or it does not exist.

It fails closed. No database, an address we cannot resolve, a country we do not recognise — all produce no region tag, and a machine without a region tag never receives work that requires one. An unproven claim is worth less than no claim.

We also do not keep the address. An IP is personal data, and we say we do not keep what we do not need — which has to apply to hosts as well as customers. What is stored is the country and a salted hash that only ever gets compared to itself, so a machine that moves is noticed and re-tagged. The lookup is a local file, not a third-party service: sending every host's address to a geolocation API would leak exactly what we promise not to collect.

What this does and does not prove

• It does prove that the machine which produced your tokens presented an address allocated to an EU or EEA country when it connected, and that the scheduler refused to route your job anywhere else.
• It does not prove the physical location of the hardware. Address-based geolocation is evidence, not attestation, and a determined host could route traffic through an EU network.

Hardware attestation — a signed statement from the machine's own security processor — would close that gap, and it is on the roadmap rather than in the product. Until it ships we describe this as address-based placement, which is what it is.

Two things are already stronger than the location claim, and matter more to most compliance questions: the control plane runs in the EU on hardware this company owns, with no US parent and therefore no CLOUD Act obligation reaching it; and prompts are not retained anywhere, which makes where they were briefly processed a much smaller question. See security and privacy.

Where hosts see this

Every machine's page in the dashboard shows its placement, read from the same tags the scheduler matches on — never from a prettier field that might disagree with routing. A machine whose location has not been established says so, and explains that it still takes ordinary work.