Cline Monitoring with OpenTelemetry: Tokens and Cost

SigNoz announced support for monitoring Cline, an open-source AI coding agent for VS Code, using OpenTelemetry to track token spend and cost by model and developer. The integration, requiring Cline v4.1.16 or later and environment variable configuration, emits metrics such as cline.tokens.input.total and cline.cache.read.tokens.total under the service name 'cline' for visualization in SigNoz's Logs and Metrics Explorers.

What is Cline Monitoring? Cline https://cline.bot is an open-source AI coding agent for VS Code that plans and executes multi-step work: it reads files, edits code, runs shell commands, and calls MCP servers on your behalf. Cline's own account page shows what you spent in total. What it does not show is where the spend went: which model, which repository, which developer, and how much of every request was context resent rather than new work. Cline ships an OpenTelemetry https://opentelemetry.io/ exporter inside the VS Code extension, so this needs no plugin or wrapper. It emits events and metrics under the service name cline . With Cline monitoring in SigNoz you can see token spend and cost broken down by model and by developer, how effective the prompt cache is, which tools the agent reaches for and which fail, request latency and time to first token, and every provider API error with its message. Prerequisites - SigNoz setup choose one : SigNoz Cloud account https://signoz.io/teams/ with an active ingestion key- Self-hosted SigNoz instance - VS Code with the Cline extension https://marketplace.visualstudio.com/items?itemName=saoudrizwan.claude-dev installed v4.1.16 or later - A model provider configured in Cline Monitor Cline with OpenTelemetry Cline reads its exporter configuration from CLINE OTEL environment variables at extension activation, so the whole setup is environment variables plus a restart. No Cline account tier is required. Step 1: Export the configuration in a shell. Required. The default bundle emits no task events or metrics at all. export CLINE BUNDLE OVERRIDE=legacy export CLINE OTEL TELEMETRY ENABLED=true export CLINE OTEL METRICS EXPORTER=otlp export CLINE OTEL LOGS EXPORTER=otlp export CLINE OTEL EXPORTER OTLP PROTOCOL=http/protobuf export CLINE OTEL EXPORTER OTLP ENDPOINT="https://ingest.<region .signoz.cloud:443" export CLINE OTEL EXPORTER OTLP HEADERS="signoz-ingestion-key=<your-ingestion-key " Verify these values: <region : Your SigNoz Cloud region https://signoz.io/docs/ingestion/signoz-cloud/overview/ endpoint . <your-ingestion-key : Your SigNoz ingestion key https://signoz.io/docs/ingestion/signoz-cloud/keys/ . Step 2: Launch VS Code from that same shell. code The extension host inherits the environment of the VS Code process, so launching from Finder, the Dock, or a Start menu shortcut picks up nothing. To make the configuration permanent, put the exports in your shell profile and always start VS Code from a terminal, or set them through your MDM or workspace tooling. Step 3: Send a prompt in Cline that uses a tool, such as asking it to read a file and edit it. Cline reads the configuration once at activation, so any change to these variables needs a full restart of VS Code rather than a window reload. View Cline Logs in SigNoz Cline exports events over the OpenTelemetry logs protocol rather than as traces. Allow a few seconds after your first prompt, then open the Logs Explorer https://signoz.io/docs/userguide/logs query builder/ and filter on service.name = 'cline' . Opening a record shows its attributes. A task.tokens event carries the token counts and the computed cost for one model request. View Cline Metrics in SigNoz Alongside the events, Cline publishes a cline. metric family under the same service name. Open the Metrics Explorer https://signoz.io/docs/metrics-management/metrics-explorer/ , search for cline , and group by model to split any of them per model. | Metric | Type | What it measures | |---|---|---| cline.tokens.input.total , cline.tokens.output.total | Counter | Cumulative prompt and completion tokens | cline.tokens.input.per response , cline.tokens.output.per response | Histogram | Token distribution per model response | cline.cache.read.tokens.total , cline.cache.write.tokens.total | Counter | Prompt-cache reads and writes | cline.cache.read.tokens.per event , cline.cache.write.tokens.per event | Histogram | Cache volume per request | cline.cost.total | Counter | Cumulative cost in USD | cline.cost.per event | Histogram | Cost distribution per request | cline.api.duration.seconds | Histogram | Full model request duration | cline.api.ttft.seconds | Histogram | Time to first token | cline.tool.calls.total , cline.tool.calls.per task | Counter, Histogram | Tool invocations, and how many a task takes | cline.turns.total , cline.turns.per task | Counter, Histogram | Model round trips, and how many a task takes | cline.ai output.accepted.lines added.total , lines changed.total , lines deleted.total | Counter | Lines of accepted agent output | Every metric carries model , provider , extension variant , and ulid , so the same per-model and per-task breakdowns available on the events work here too. Each histogram arrives in SigNoz as five series .bucket , .count , .sum , .min , .max , so search for cline.api.ttft.seconds.bucket rather than the base name when building a percentile panel. Attributes Worth Knowing The event name arrives as the log body , not as an attribute, so queries filter with body = 'task.tokens' rather than on a name field. Four more details decide whether your queries are correct. Every event produced by one task shares it. Cline emits no traces, so there is no trace or span ID to group on and ulid is the task correlation key. ulid is the only way to reconstruct a task. Cache reads are counted separately from input. cacheReadTokens is not included in tokensIn . Adding the two together double counts the context. The model key is not consistent. task.tokens and task.conversation turn use model , while task.tool used uses modelId . A filter written for the token events silently drops every tool event. Absent values arrive as the string "undefined" . requestId , errorStatus , and isNativeToolCall use the literal text rather than being omitted, so exclude that string explicitly when filtering. The events worth building on are task.tokens tokensIn , tokensOut , cacheReadTokens , cacheWriteTokens , totalCost , model , provider , task.tool used tool , success , autoApproved , task.conversation turn mode , source , and task.provider api error errorType , errorClass , errorMessage , failurePhase . Track Token Usage and Cost Cost is the reason most teams instrument a coding agent, and Cline reports it per model request on the task.tokens event. Two things about that number are worth knowing before you build on it. Cost is computed on the client. Cline multiplies token counts by its own per-model price table rather than reading a figure back from the provider. That means totalCost reads 0 for a model that is free to you, including Cline's own bundled provider, and the zero is arithmetically correct rather than a broken export. Configure a directly priced provider under Settings API Provider to get meaningful cost. Most of your input tokens are resent context. Cline replays the system prompt and workspace context on every turn, so a one-word prompt can carry eight thousand input tokens. Read cacheReadTokens next to tokensIn : a cache-read figure close to the input total means the provider cache is absorbing that repetition, and a low one means you are paying full price for it every turn. Both aggregate cleanly straight from the events, so a token or cost panel is accurate from the very first task: service.name = 'cline' AND body = 'task.tokens' Cline Monitoring Dashboard The Cline dashboard https://signoz.io/docs/dashboards/dashboard-templates/cline-dashboard/ turns these events and metrics into token spend by model, cost over time, prompt-cache effectiveness, tool mix and failures, latency, and provider API errors. Troubleshooting Cline Monitoring Every export fails with UNAUTHENTICATED The protocol is set to grpc . Cline passes your headers to the gRPC exporter in a field the OpenTelemetry SDK does not read for gRPC, so the ingestion key never leaves the machine. Set CLINE OTEL EXPORTER OTLP PROTOCOL=http/protobuf and restart VS Code. Telemetry is enabled but nothing arrives Confirm the value is exactly true . CLINE OTEL TELEMETRY ENABLED=1 does not work on this path, even though 1 is accepted elsewhere in the extension, because the runtime configuration compares against the string true . Then confirm VS Code inherited the environment. Launching from the Dock or Finder gives the extension host an environment without your exports. Start VS Code with code from the shell where you set them. Lifecycle events arrive but no task, token, or tool events CLINE BUNDLE OVERRIDE=legacy is missing. Lifecycle events such as user.extension activated are emitted on a path that both bundles share, so a partially working export is the expected symptom. Set the variable and restart VS Code. The diagnostic log always says count=0 Ignore it. With TEL DEBUG DIAGNOSTICS=true , every successful export prints count=0 regardless of how many records it carried. Verify in SigNoz instead of trusting that number. Exports intermittently return Unauthorized A share of batches can be rejected under sustained load with a key that succeeds on the requests either side of them. Records in a rejected batch are lost, so treat a missing event as possibly dropped rather than never emitted. Nothing is emitted from the Cline CLI This cannot be fixed by configuration. The OpenTelemetry exporter exists only in the VS Code extension, and the Cline CLI contains no OTLP support at all. Use the extension to collect telemetry. Setup OpenTelemetry Collector Optional What is the OpenTelemetry Collector? Think of the OTel Collector as a middleman between your app and SigNoz. Instead of your application sending data directly to SigNoz, it sends everything to the Collector first, which then forwards it along. Why use it? Cleaning up data - Filter out noisy events you don't care about, or remove sensitive info before it leaves your machines. Keeping your app lightweight - Let the Collector handle batching, retries, and compression instead of your application code. Adding context automatically - The Collector can tag your data with useful info like which team or environment it came from. Future flexibility - Want to send data to multiple backends later? The Collector makes that easy without changing your setup. See Switch from direct export to Collector https://signoz.io/docs/opentelemetry-collection-agents/opentelemetry-collector/switch-to-collector/ for step-by-step instructions to convert your setup. For more details, see Why use the OpenTelemetry Collector? https://signoz.io/docs/opentelemetry-collection-agents/opentelemetry-collector/why-to-use-collector/ and the Collector configuration guide https://signoz.io/docs/opentelemetry-collection-agents/opentelemetry-collector/configuration/ . Related integrations Instrument the other AI coding agents your team runs, using the same OpenTelemetry pipeline: Monitor Claude Code with OpenTelemetry https://signoz.io/docs/claude-code-monitoring/ Monitor OpenAI Codex with OpenTelemetry https://signoz.io/docs/codex-monitoring/ Cursor IDE observability with OpenTelemetry https://signoz.io/docs/cursor-observability/ OpenCode observability with OpenTelemetry https://signoz.io/docs/opencode-observability/ Browse all LLM observability integrations https://signoz.io/docs/llm-observability/ to instrument the rest of your stack.