Skip to main content
Using an agent? Install the Latitude skills and let it handle the setup below. latitude-setup instruments your app or agent harness, verifies traces arrive, creates a temporary account if you don’t have one yet (no signup), and ends by building your first Artifact.

​
Overview

Cloudflare AI Gateway proxies requests to your LLM providers and can export an OpenTelemetry span for every request it handles. Those spans follow the OpenTelemetry GenAI semantic conventions, so Latitude ingests them directly over OTLP — no SDK or code change in your application. No Latitude account yet? Your agent can create a temporary one and do this whole setup with the latitude-setup skill, no signup. You configure the exporter once in the AI Gateway dashboard, pointing it at Latitude’s OTLP endpoint. Every model call routed through the gateway then shows up in Latitude with its model, token usage, cost, and prompt/response messages.

​
Requirements

  • A Latitude API key, or none yet: your agent can create a temporary account with the latitude-setup skill, no signup
  • A Latitude project slug
  • A Cloudflare AI Gateway with OpenTelemetry export available in its settings

​
Setup

1

Open your gateway's OpenTelemetry settings

In the Cloudflare dashboard, go to AI → AI Gateway, select your gateway, and open Settings → OpenTelemetry.
2

Add a Latitude destination

Click Add Otel Destination and fill in the dialog:Then add two Custom Headers:Replace <LATITUDE_API_KEY> with a Latitude API key (Settings → API Keys) and <PROJECT_SLUG> with your project’s slug.
To keep the API key out of the destination config, store the full Bearer <LATITUDE_API_KEY> value in Cloudflare Secrets Store and reference it from the Authorization header — Cloudflare injects the secret as the entire header value, so it must include the Bearer prefix.
3

Send a request

Route a request through your gateway. The trace appears in Latitude within a few seconds.

​
What gets captured

Latitude resolves the standard GenAI attributes AI Gateway emits:
  • Provider — gen_ai.provider.name
  • Model — gen_ai.request.model
  • Token usage — gen_ai.usage.input_tokens, gen_ai.usage.output_tokens
  • Cost — gen_ai.usage.cost
  • Messages — gen_ai.input.messages / gen_ai.output.messages. AI Gateway puts the raw request body and the upstream provider’s native response in these fields; Latitude unwraps them into a normal conversation view.
AI Gateway reports gen_ai.operation.name as chat for every request, including embeddings. Latitude reclassifies embedding requests to embeddings automatically, so they’re counted and displayed correctly.

​
Linking gateway spans to your app traces

If your application already emits OpenTelemetry traces, you can stitch the gateway span into them by passing trace context on the request:
  • cf-aig-otel-trace-id — a 32-character hex trace ID
  • cf-aig-otel-parent-span-id — a 16-character hex parent span ID
The gateway span is then created as a child of the span you identify.

​
Seeing your traces

Once connected, traces appear automatically in Latitude:
  1. Open your project in the Latitude dashboard
  2. Send a request through your AI Gateway
  3. The request appears with its model, messages, latency, token usage, and cost

​
See what was captured

Once a real run has landed, your agent builds your first Artifact: a single HTML page, in the Latitude look, with everything the telemetry captured from that session: model calls, tool calls, tokens, cost, timing, and the conversation as the model saw it. It is the fastest way to check the integration end to end and to see what Latitude will have to work with. The latitude-setup skill does this as its last step from its bundled first-artifact.html template, filling the page with the values the latitude CLI returns for the trace, and adds a Claim your workspace button when the account is temporary. If you set things up by hand, the same template and instructions live in the skills repo. Prompt, if you need to ask for it: