# How LightHouse scales

> How LightHouse™ and the engine add capacity under load, how rate limits apply across that capacity, and what to plan for in a large rollout.

LightHouse™ and the Atlantic Agentic Engine scale separately. Atlantic runs LightHouse, which adds capacity for portal reads, the API and MCP as demand rises. The engine runs the client’s agents, calls its models, and runs and scales in the client’s own cloud account.

## LightHouse capacity

The services that answer the API and MCP run as several copies. When load rises, LightHouse starts additional copies automatically. When load falls and remains low, each service returns to its baseline number of copies. No request from the client and no change to the tenant is required.

Services that hold a long-lived connection to one copy, such as the connection from the client’s content reader, run at a fixed size. Those connections are not moved while in use.

Atlantic is alerted when a service remains at its upper bound, and monitors the capacity of the shared database.

## Rate limits across copies

Rate limits are set per credential and per tenant and are counted in one shared store. Every copy of a service draws on the same allowance. A limit is the same whichever copy answers a request, and adding copies does not raise or divide an allowance. The limits and the headers that report them are described on [Rate limits](/api/rate-limits/).

Each tenant has its own allowance. Traffic from one tenant does not count against another tenant’s allowance.

## Engine capacity

The client’s agents run in its engine, in the client’s own account. Retrieval, tool calls and every model call through the [gateway](/concepts/gateway/) take place there. The engine scales within the selected [deployment profile](/concepts/deployment-profiles/), on the client’s own cloud compute. Each client’s agents and model calls run on that client’s infrastructure, and one client’s load does not reach another client’s deployment.

LightHouse receives the deployment’s telemetry and serves the client’s users and tools. It does not run the client’s agents. Agent load falls on the client account’s resources, and LightHouse records it.

## Planning a large rollout

In a large rollout, the limiting factor is usually the client’s model provider quotas: the requests and tokens a minute that the client’s cloud account may send to each model on Amazon Bedrock, Azure OpenAI or Vertex AI. The provider sets these quotas for the account. Increases can take time and should be requested early.

The [model router](/router/) reduces demand on those quotas. For each call it selects the cheapest model that meets the quality bar for the task. Routine work often moves to smaller models with more quota available, and the quota of the most capable models remains available for the work that requires them. The gateway paces calls to the limits stated in the gateway policy, and LightHouse shows how close each model is to its limit.

Clients under a non-disclosure agreement can read the planning checklist and the figures in the client documentation. Our certified forward-deployed engineers plan and load-test the rollout with the client before go-live.

Source: https://docs.atlanticagenticlabs.com/concepts/scaling/
