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.- 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
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: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.
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.
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.
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
Request Lifecycle
What happens to a request from the moment it hits Lectr to the moment the
response comes back.
Architecture
The system design — hot path, cold path, caches, and workers.