> ## Documentation Index
> Fetch the complete documentation index at: https://docs.layerx1.com/llms.txt
> Use this file to discover all available pages before exploring further.

# Moving an existing app over.

> You already have code calling OpenAI, Anthropic, or an aggregator. Here is exactly what changes — usually two lines — and the handful of things worth checking before you cut traffic over.

## What actually changes

| From                            | Change the base URL to       | Change the key to | Change the model to                           |
| ------------------------------- | ---------------------------- | ----------------- | --------------------------------------------- |
| OpenAI                          | `https://api.layerx1.com/v1` | your `lx1_` key   | an `lx1-*` id (optional at first — see below) |
| Anthropic                       | `https://api.layerx1.com`    | your `lx1_` key   | an `lx1-*` id (optional at first)             |
| An OpenAI-compatible aggregator | `https://api.layerx1.com/v1` | your `lx1_` key   | an `lx1-*` id                                 |

That is the whole migration for most codebases. Your SDK, your request shapes, your
streaming code, your retry logic and your tool definitions all stay exactly as they are.

<CodeGroup>
  ```python From OpenAI theme={null}
   from openai import OpenAI

   client = OpenAI(
  +    base_url="https://api.layerx1.com/v1",
  +    api_key=os.environ["LAYERX1_API_KEY"],
   )
  ```

  ```python From Anthropic theme={null}
   from anthropic import Anthropic

   client = Anthropic(
  +    base_url="https://api.layerx1.com",
  +    api_key=os.environ["LAYERX1_API_KEY"],
   )
  ```

  ```ts TypeScript theme={null}
   import OpenAI from "openai";

   const client = new OpenAI({
  +  baseURL: "https://api.layerx1.com/v1",
  +  apiKey: process.env.LAYERX1_API_KEY,
   });
  ```
</CodeGroup>

## You can leave the model ids alone at first

A finite list of stock ids that SDKs commonly ship hard-coded — `gpt-4o`,
`claude-sonnet-4-5`, `o3`, `codex` and others — resolve to catalog models, so an app you
have not fully audited keeps working the moment you flip the base URL.

Treat that as a bridge, not a destination. Move to `lx1-*` ids before you depend on
specific behavior: the compatibility mapping points at whichever model is the right landing
spot today, and it can move. See [Model routing](/guides/model-routing).

```sh title="Find what you're actually sending" theme={null}
grep -rn 'gpt-4o\|claude-\|o3-\|gpt-5' src/ | grep -v node_modules
```

## Check these five things

<Steps>
  <Step title="Model capabilities">
    Vision, documents, tools and structured output are per-model. Read
    `capabilities` and `supported_parameters` off
    [`GET /v1/models`](/api/models-endpoint) for the ids you plan to use — a capability the
    model cannot guarantee is a `422`, not a silent downgrade.
  </Step>

  <Step title="Output ceilings on reasoning models">
    Hidden reasoning counts against `max_tokens`. A ceiling tuned for a non-reasoning model
    can be consumed entirely by thinking. See [Reasoning](/guides/reasoning).
  </Step>

  <Step title="Rate limits and concurrency">
    Published per plan on [Plans & limits](/plans). If you are moving a fleet, size against
    the **concurrency** figure, not just requests/min — that is the axis parallel agents
    hit first.
  </Step>

  <Step title="Your retry logic">
    `429` carries `retry-after`; `5xx` is transient and worth retrying with backoff; other
    `4xx` never are. If you hand-rolled an HTTP client, check it honors `retry-after` — the
    official SDKs already do. See [Errors](/errors).
  </Step>

  <Step title="Response headers">
    Usage and limit state ride on `x1-*` and `x-ratelimit-*` headers. If you had dashboards
    reading a previous provider's headers, repoint them. See [Headers](/headers).
  </Step>
</Steps>

## Things that behave differently

* **One meter, not per-model billing.** Every plan includes the whole catalog and draws
  from a single pool measured in list-price dollars, so "which model" is a cost decision
  rather than an access decision. [Plans & limits](/plans)
* **Saturation waits instead of failing.** A request that would have been shed under load
  takes a place in line, so allow headroom in client timeouts. [Reliability](/reliability)
* **Model ids are not versioned in the URL.** Models are added, retired and repriced
  without an API version bump. Pin ids, and read the catalog at runtime if you need to know
  what exists.
* **Prompt caching depends on the model.** Where a model publishes a cached input rate,
  repeated context counts at that rate; where it does not, it counts at the ordinary input
  rate. [Prompt caching](/guides/prompt-caching)

## Cut over safely

<Steps>
  <Step title="Run both in parallel">
    Point a copy of your service at the gateway with a separate key, replay real traffic
    shapes through it, and diff the outputs you care about.
  </Step>

  <Step title="Start on a low-stakes path">
    Move background jobs, summarization, or an internal tool first. Keep the user-facing
    path on the old provider until the numbers agree.
  </Step>

  <Step title="Watch the allowance headers">
    `x1-allowance-remaining` is the live figure the monthly cap is enforced against. Alert
    on it before it reaches zero, because at zero it is a hard stop, not a throttle.
  </Step>

  <Step title="Then flip the base URL">
    One environment variable, no code change — which also makes the rollback one
    environment variable.
  </Step>
</Steps>

## Coding agents

If what you are migrating is a coding agent rather than an app, skip all of the above:

```sh theme={null}
npx layerx1
```

One command configures Claude Code, Codex, Cursor, Aider, Continue, Cline or Windsurf, and
`npx layerx1 unset` reverses it from timestamped backups. See the [CLI](/cli).