> ## Documentation Index > Fetch the complete documentation index at: https://to11.ai/docs/llms.txt > Use this file to discover all available pages before exploring further. # Instrumentation > Get your application's LLM calls into to11 — automatically through the gateway, or by sending OpenTelemetry spans directly. Instrumentation is how your application's activity becomes data in to11. Every LLM call is recorded as an OpenTelemetry-native trace — model, tokens, latency, finish reason, and the prompt and completion text (captured by default) — following the [OpenTelemetry GenAI semantic conventions](https://opentelemetry.io/docs/specs/semconv/gen-ai/). Because the data is standard OTel, any compatible viewer can read it, and your traces are never locked to a proprietary format. There are two ways to get that data in. Most applications use the first; the second exists for everything the gateway never sees. Either way, every call your application makes ends up on the record — cranked to eleven. ```text theme={null} automatic Your app ──SDK──▶ Gateway ──────────┐ ├──▶ GenAI spans ──▶ to11 Your app ──OTel SDK──▶ Collector ───┘ direct ``` ## Through the gateway Point your existing LLM SDK at the gateway and authenticate to to11 with your to11 API key. Every request is then routed, secured, and traced automatically, and each call produces a GenAI span — with no tracing code, no OpenTelemetry SDK, and no extra dependencies. The gateway emits the spans for you. This is the recommended path and covers most applications. It works with the OpenAI, Anthropic, and Vercel AI SDKs; see [Integrations](/docs/integrations/overview) to connect yours. ## Send spans directly If you already emit OpenTelemetry spans, or you want to capture work the gateway never sees — retrieval steps, tool execution, custom pipeline stages — send OTLP spans straight to the to11 collector. The spans land in the same store as gateway traces and correlate with them under a shared trace ID. This path needs your own OTel SDK, but it is the only way to record activity that does not pass through the gateway. See [Direct ingestion](/docs/instrument/direct-ingestion) for the full walkthrough. ## Which path? The two paths are not exclusive — many applications send LLM calls through the gateway and use direct ingestion for the surrounding work. | If you... | Use | | ------------------------------------------------------------------- | -------------------------------------------------------------------- | | Call LLMs through a standard SDK and want zero tracing code | Through the gateway | | Want routing, fallback, and credential management alongside tracing | Through the gateway | | Make calls the gateway can't proxy, or already run an OTel SDK | Direct ingestion | | Need spans for retrieval, tool calls, or non-LLM pipeline steps | Direct ingestion | | Want LLM calls and surrounding work in one trace | Both, correlated by [trace context](/docs/instrument/distributed-tracing) | ## What gets captured | Signal | Where it comes from | | ------------------------- | ------------------------------------------------------------------------------------------------- | | GenAI spans | Every gateway call, or spans you send directly | | Span attributes | Model, tokens, latency, finish reason — see [Span attributes](/docs/instrument/span-attributes) | | Distributed traces | Multi-call and multi-agent workflows — see [Distributed tracing](/docs/instrument/distributed-tracing) | | Prompt/completion content | Captured by default, configurable — see [Content capture](/docs/instrument/content-capture) | ## Next steps Point the OpenAI, Anthropic, or Vercel AI SDK at the gateway. How telemetry is modeled, exported, and named. Send custom OTLP spans straight to the collector. Every attribute the gateway records, by lifecycle stage.