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

# AI Gateway

> What an AI gateway is, why it exists, and where Lectr fits.

## The problem it solves

When a team first integrates an AI provider, the setup is simple — one API key,
one endpoint, one bill at the end of the month. It works fine until it doesn't.

The bill arrives and nobody knows which feature caused the spike. A model starts
responding slower and nobody notices until users complain. A new team member
accidentally sends production traffic to the wrong model. The AI spend grows
faster than the product, and there's no visibility into why.

The root cause is always the same: **AI requests are invisible.**

They go out, they come back, and nothing in between captures what happened.
No record of which feature made the request, how long it took, what it cost,
or whether it succeeded. The information exists — it passes through your code
on every request — but without something in the path capturing it, it disappears.

An AI gateway is that something.

***

## What an AI gateway does

An AI gateway sits between your application and your AI providers. Every request
goes through it on the way out and on the way back.

```
Your app → AI Gateway → OpenAI / Anthropic / Groq / Gemini
```

At its most basic, a gateway is a proxy — it forwards requests and returns
responses without your application knowing or caring. The value is in what it
does while the request is passing through:

* **Captures metadata** — model, latency, tokens, cost, errors — without reading content
* **Enforces policies** — routing rules, rate limits, budget caps
* **Provides observability** — real-time visibility into every request across every provider
* **Normalises providers** — one endpoint regardless of which AI provider you use

The application changes one line. The gateway handles everything else.

***

## Where Lectr fits

Lectr is an AI gateway built around a specific philosophy: **earn the right to
control AI traffic by first proving you can observe it perfectly.**

This shapes how Lectr is built and in what order features ship:

<Steps>
  <Step title="See it">
    Complete visibility into every AI request — cost, latency, tokens, errors —
    broken down by feature, model, and provider. Real time. No code changes
    beyond the baseURL.
  </Step>

  <Step title="Understand it">
    Pattern recognition on top of your data. Anomaly detection, cost trends,
    model recommendations based on actual usage. Lectr tells you what to do, not
    just what happened.
  </Step>

  <Step title="Control it">
    Routing rules, budget policies, fallback logic. Act on what you understand —
    automatically. The proxy that started as a visibility tool becomes an
    intelligent control layer.
  </Step>

  <Step title="Define it">
    Your entire AI system declared as code. Versioned, plannable, auditable. AI
    infrastructure that behaves exactly as intended.
  </Step>
</Steps>

Teams start with visibility and move toward control as they build trust in the system.
The integration is the same at every stage — one URL change.

***

## What makes Lectr different

**It's invisible by design.**

The best proxy is the one you don't notice. Lectr adds negligible latency,
never modifies your responses, and never reads your prompts. If you can feel
it in your request path, something is wrong.

**It's multi-provider from day one.**

OpenAI, Anthropic, Groq, and Gemini through one endpoint. One dashboard for
your entire AI spend regardless of how many providers you use. Provider
detection is automatic — you change nothing except the baseURL.

**It's honest about what it knows.**

Streaming token counts are labelled as measured, not presented as exact.
Cost estimates carry their uncertainty. Anomaly alerts include the baseline
and deviation so you can judge for yourself. Lectr doesn't hide the limits
of what it knows.

**It's built for developers.**

Integration takes under 2 minutes. No SDK to install, no agent to run, no
infrastructure to manage. Works with any OpenAI-compatible client. The org
key goes in an environment variable and that's the entire setup.

***

## What Lectr is not

**Not an LLM provider.** Lectr does not host models. It proxies your requests
to the providers you already use.

**Not a prompt management tool.** Lectr never reads, stores, or processes prompt
content. It captures metadata only.

**Not an evaluation framework.** Running evals against model outputs is a
different problem — tools like Braintrust solve it. Lectr solves the observability
and control problem that happens in production.

**Not a replacement for your SDK.** You keep using the OpenAI SDK, the Anthropic
SDK, or whichever client you prefer. Lectr just changes where it sends requests.

***

## Next

<CardGroup cols={2}>
  <Card title="Request Lifecycle" icon="arrows-spin" href="/concepts/request-lifecycle">
    What happens to a request from the moment it hits Lectr to the moment the
    response comes back.
  </Card>

  <Card title="Architecture" icon="diagram-project" href="/concepts/architecture">
    The system design — hot path, cold path, caches, and workers.
  </Card>
</CardGroup>
