Regions

Lararouter runs in three regions. Each one is a separate host with its own storage, and data written in a region stays in that region.

Regions are isolated, not replicated

This is the part worth internalizing before you pick one, because it isn't a routing preference. It determines where everything lives:

• API keys authenticate against exactly one region. A US key sent to the EU host returns 401 key_region_mismatch.
• Usage and budgets are counted per region. A $500/month cap in the US does not know about spend in the EU.
• Audit logs never leave the region that recorded them. A request ID from eu returns 404 on us.
• Batches and their files are regional. A file uploaded to eu can only be used by a batch created in eu, and results are written back to the same region.

If you operate in two regions, you operate two projects. Aggregating them is your application's job, and GET /v1/usage/entities in each region gives you the halves to add together.

Choosing one

Pick for data residency. Because everything runs as a batch, round-trip time is irrelevant to the workload. You are not serving a live request, and a few hundred milliseconds means nothing against a completion window measured in hours.

What does matter is where prompts, completions, and audit records are stored. Choose the region your obligations point at, and where your data already lives.

curl https://REGION.api.lararouter.com/v1/regions \
  -H "Authorization: Bearer $LARAROUTER_API_KEY"

{
  "object": "list",
  "data": [
    { "id": "us", "name": "United States", "host": "us.api.lararouter.com", "status": "operational" },
    { "id": "eu", "name": "European Union", "host": "eu.api.lararouter.com", "status": "operational" },
    { "id": "in", "name": "India", "host": "in.api.lararouter.com", "status": "operational" }
  ]
}

GET /v1/regions is authenticated but works from any region, so it's a safe way to discover hosts and check status without hardcoding a list. See the utility reference.

Confirming which region answered

Every response carries the region that served it. If you're running a multi-region deployment and something looks wrong, this is the first header to check.

GET /v1/me HTTP/1.1
Host: REGION.api.lararouter.com
Authorization: Bearer $LARAROUTER_API_KEY

HTTP/1.1 200 OK
X-Lararouter-Region: REGION

Model availability differs

Not every model is deployed in every region. Ask the region you're actually calling:

curl https://REGION.api.lararouter.com/v1/models \
  -H "Authorization: Bearer $LARAROUTER_API_KEY"

Requesting a model that isn't deployed where you're calling returns 404 with error.code = model_not_available_in_region, and the error names the regions that do have it:

{
  "error": {
    "type": "invalid_request_error",
    "code": "model_not_available_in_region",
    "message": "Model 'command-r-35b' is not available in region 'in'.",
    "available_in": ["us", "eu"]
  }
}

Configuring the host once

Put the base URL in configuration rather than scattering it through your codebase. Moving regions then means changing one environment variable.

// config/services.php
'lararouter' => [
    'url' => env('LARAROUTER_URL', 'https://REGION.api.lararouter.com/v1'),
],

# .env
LARAROUTER_URL=https://REGION.api.lararouter.com/v1