How do you export YAGNI Code telemetry to Datadog?

Why would you point telemetry at Datadog?

Every YAGNI Code session has a meter: what it did, what it cost, and how long each step took. Exported over OpenTelemetry, that meter becomes queryable in the observability tool your team already pays for. You can answer what last week’s migration work actually cost, which runs burned the budget, and whether the slow step was the model or the tooling, from the same place you watch the rest of your stack.

The export carries the same three signals Claude Code’s telemetry does, with the same metric and event names under a yagni_code prefix. A team that already built Claude Code dashboards in Datadog keeps them and swaps the prefix.

Datadog is the most common destination, and this lesson walks the direct-SaaS path: no agent on your machines, just the workspace setting and a Datadog API key.

How does the workspace setup work?

A workspace admin opens Settings → YAGNI Code → Telemetry export in the YAGNI web app and turns the export on. Then:

1. Pick the Datadog (direct SaaS) preset and choose your Datadog site.
2. Paste your Datadog API key into the dd-api-key header row. The endpoint and protocol fill themselves in from the site you picked, such as https://otlp.datadoghq.com with http/protobuf for US1, and a second header, dd-otlp-source, is added so Datadog routes the traces into LLM Observability as well as APM.
3. Save. The workspace is done.

From the next launch, every YAGNI Code session on every machine in the workspace exports there. There is nothing per developer to configure, and nothing visible in the terminal: the export rides alongside the session without changing how it runs. Runs started with yagni go, stage children, and subagents export too, so the bill in Datadog matches the bill in YAGNI.

If you run the Datadog Agent on your machines already, pick the Datadog (Agent) preset instead and point at the agent’s local OTLP port; it forwards with its own key and needs no API key pasted here.

How do you confirm it is working?

After upgrading, run:

yagni doctor

The otel export (optional) line reports the state: which endpoint is configured, which source it came from (workspace settings, your own environment variables, or a repo config file), and then the result of a real test. The doctor sends one small span, one metric point, and one log record and prints what Datadog answered for each. A 403 means the API key is wrong, a 404 means the site or path is wrong, and a connection error means the intake is unreachable from that machine. The probe records are named yagni_code.doctor.probe, so you can find them in Datadog as proof the pipe works before any real session runs.

Then run one short session and look in three places:

• APM → Traces, filtered to service yagni-code: one trace per prompt, with the model call and each tool call as child spans.
• LLM Observability: the same traces, presented as agent runs with token and cost breakdowns. Datadog can take a few minutes to show them there.
• Log Explorer, with the query service:yagni-code: the event stream, one record per prompt, model request, tool result, and permission decision.

Metrics arrive under the yagni_code namespace in Metrics Explorer, for example yagni_code.token.usage and yagni_code.cost.usage.

What rides on the export?

Traces. Each prompt the agent handles becomes a trace: an interaction span, the model call with its token counts, cost, and the tier that served it, and every tool call, including calls into MCP servers, with their durations. The spans carry both Claude Code’s flat attribute names and the OpenTelemetry GenAI conventions, so LLM-observability views read them natively.

Metrics. The eight counters Claude Code emits, under yagni_code: session count, token usage by type and model, cost by model, lines of code added and removed, commits, pull requests, code-edit permission decisions, and active time split between the developer and the agent.

Log events. One record per user prompt, assistant response, model request, model error, tool result, permission decision, and permission mode change, each with event.name, a timestamp, a sequence number, and a prompt.id that ties every event from one prompt together.

Every signal carries the session id, the workspace id as organization.id, the terminal type, and any custom keys you set in OTEL_RESOURCE_ATTRIBUTES. Cost attribution per run and per developer comes straight from those attributes, so the bill and the dashboard agree without any manual joining.

What if a developer already has OpenTelemetry configured?

Machines that already carry the standard OpenTelemetry environment variables, such as the per-signal OTEL_EXPORTER_OTLP_TRACES_ENDPOINT, OTEL_EXPORTER_OTLP_METRICS_ENDPOINT, and OTEL_EXPORTER_OTLP_LOGS_ENDPOINT a Claude Code setup uses, keep working with no changes: personal environment config takes precedence over workspace settings, so a developer pointing at a team collector or a local vendor keeps their own setup. Workspace settings fill in for everyone else.

The precedence order, most specific first: a personal kill switch (YAGNI_OTEL_DISABLED), then the environment variables, then workspace settings, then a repo’s committed config. A developer can always see which source is live with yagni doctor.

Where do you go next?

With MCP servers connected and the meter flowing into Datadog, YAGNI Code is fully instrumented. The rest of the Academy covers the org-level story: how Teams carry whole lanes of work and how the Playbook learns your rules.