Claude Code

Software.com automatically tracks AI coding metrics from Claude Code. Get insight into adoption, activity, and the impact of Claude Code on your team’s productivity.

Connection Methods

We support Claude.ai Enterprise, Claude.ai Team subscriptions, Claude Developer Platform (API) accounts, and self-hosted deployments. You can connect one or more of the following:

• Claude.ai Enterprise – For organizations on a Claude.ai Enterprise plan. Connect using an Analytics API key.
• Claude.ai Team – Team members log in with their Claude.ai subscriptions, including Pro, Max, and Team.
• Claude Developer Platform – Claude Code is managed through an organization with shared API billing on platform.claude.com. Usage analytics are tracked via Claude Code’s Analytics API .
• Self-Hosted Claude Code – Claude Code is hosted on your own infrastructure (e.g. Amazon Bedrock, Google Vertex AI, or Microsoft Foundry).

Method 1: Claude.ai Enterprise

For organizations on a Claude.ai Enterprise plan, connect using an Analytics API key to pull usage data directly from Anthropic’s Analytics API.

Method 2: Claude.ai Team

We use OpenTelemetry  to track usage from Claude.ai subscriptions (Pro, Max, and Team).

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/json",
    "OTEL_EXPORTER_OTLP_METRICS_ENDPOINT": "https://app.software.com/api/v1/otel/claude/metrics",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer your_token",
    "OTEL_METRIC_EXPORT_INTERVAL": "3600000"
  }
}

When developers log into Claude with their subscription via their Terminal they will see a notification: “Managed settings require approval”. Users must accept these settings to use Claude. This will update the ~/.claude/settings.json file in each user’s home directory.

Other important notes:

• You must be an Owner to update managed settings.
• If you have your own OpenTelemetry collector or have already set up a .claude/settings.json in the repo with OpenTelemetry configured, managed settings will supersede it. Keep this in mind if you or your team have an existing repo-level OpenTelemetry configuration.
• This setting only tracks Claude CLI usage. It tracks terminal usage, but not activity in Claude Code editor extensions or the desktop app.
• For more detail on how to configure your settings file, see Claude Code settings .

Method 3: Claude Developer Platform

To connect your Claude Developer Platform (API) account:

This integration uses the Admin API. You must use an Admin API key (keys start with sk-ant-admin...), which is different from standard Claude API keys. Standard API keys cannot access the usage report or organization users endpoints. Only organization members with the admin role can create Admin API keys.

Method 4: Self-Hosted Claude Code

If Claude Code is hosted on your own infrastructure — such as Amazon Bedrock, Google Vertex AI, or Microsoft Foundry — you can send usage analytics to Software.com through OpenTelemetry .

You have two options depending on whether your organization already runs an OpenTelemetry Collector:

• No existing telemetry backend – Point Claude Code directly at the Software.com collector using administrator configuration.
• Existing telemetry backend – Add Software.com as an additional exporter in your OTel Collector using a fan-out pipeline. This lets you send telemetry to multiple backends simultaneously without changing your existing setup.

No existing telemetry backend

If your organization does not already have an OpenTelemetry backend, you can point Claude Code directly at Software.com.

{
  "env": {
    "CLAUDE_CODE_ENABLE_TELEMETRY": "1",
    "OTEL_METRICS_EXPORTER": "otlp",
    "OTEL_EXPORTER_OTLP_PROTOCOL": "http/json",
    "OTEL_EXPORTER_OTLP_METRICS_ENDPOINT": "https://app.software.com/api/v1/otel/claude/metrics",
    "OTEL_EXPORTER_OTLP_HEADERS": "Authorization=Bearer token",
    "OTEL_METRIC_EXPORT_INTERVAL": "3600000"
  }
}

The managed settings file location depends on the OS:

Environment variables in the managed settings file have high precedence and cannot be overridden by users. For more detail, see Claude Code settings .

Existing telemetry backend

If your organization already runs an OpenTelemetry Collector — for example, the AWS Distro for OpenTelemetry (ADOT)  exporting to CloudWatch, Google Cloud’s OpenTelemetry Collector  exporting to Cloud Monitoring, or Azure Monitor OpenTelemetry  exporting to Azure Monitor — you can add Software.com as an additional exporter. This fan-out approach receives telemetry events and exports to multiple backends simultaneously with no changes to your existing pipeline.

exporters:
  # ... your existing exporters ...
 
  # Software.com Collector — metrics only
  otlphttp/software:
    metrics_endpoint: "https://app.software.com/api/v1/otel/claude/metrics"
    compression: none
    encoding: json
    headers:
      Authorization: "Bearer <your-software-api-key>"
    retry_on_failure:
      enabled: true
      initial_interval: 5s
      max_interval: 30s
      max_elapsed_time: 300s
    tls:
      insecure: false

service:
  pipelines:
    metrics:
      receivers: [otlp]
      processors: [batch]
      exporters: [awsemf, otlphttp/software]

Restart your collector and metrics will flow to both your existing backend and Software.com simultaneously.

How the fan-out collector works

The fan-out architecture uses an OpenTelemetry Collector as a local sidecar or agent that sits between Claude Code and your observability backends. Instead of configuring Claude Code to send telemetry to each destination individually, a single collector receives all telemetry once and exports it to multiple backends in parallel.

Architecture overview

The data flow works as follows:

1. Claude Code emits telemetry. When CLAUDE_CODE_ENABLE_TELEMETRY is enabled, Claude Code produces OpenTelemetry metrics (lines added, commits, pull requests, tokens, and related usage data) and sends them to a local OTLP endpoint.
2. The OTel Collector receives telemetry. A collector process — e.g. as an ECS sidecar, GKE sidecar container, or AKS sidecar container — listens on the OTLP endpoint.
3. The collector fans out to multiple exporters. Each exporter in the service.pipelines.metrics section receives an independent copy of the metrics. Exporters operate in parallel and fail independently — if one destination is unavailable, the others continue to receive data without interruption.
4. Software.com receives metrics via OTLP/HTTP. The otlphttp/software exporter sends metrics to Software.com’s collector endpoint. Software.com processes these metrics to surface adoption, activity, and impact dashboards for your team.

Why this approach

• Single point of configuration. Claude Code only needs to know about one endpoint — the local collector. All routing decisions live in the collector config.
• No SDK changes. The fan-out happens at the infrastructure layer, not in Claude Code itself. You don’t need to configure multiple exporters in Claude Code’s settings.json.
• Failure isolation. Each exporter fails independently. If Software.com’s endpoint is temporarily unreachable, your existing pipeline (e.g. AWS CloudWatch, Google Cloud Monitoring, Azure Monitor, OpenSearch) continues uninterrupted. The retry_on_failure block on the Software.com exporter handles transient failures with exponential backoff.
• Minimal overhead. The collector batches and compresses telemetry before exporting. Adding a second exporter to an existing pipeline is two config blocks — the exporter definition and a reference in the pipeline.

Collector deployment options

The collector process needs to run somewhere accessible to Claude Code. For AWS, the ECS sidecar is the default recommendation for most enterprise customers running Claude Code via Bedrock. It uses an IAM task role for auth (no credentials to manage). For Google Cloud, the equivalent is a GKE sidecar container with Workload Identity for auth. For Azure, use an AKS sidecar container with Workload Identity (or Managed Identity on VMs). In all cases your otelcol-config.yaml stays identical — you just add the otlphttp/software exporter block.

VPC and network configuration

If your OTel Collector runs in a private subnet inside a VPC, it needs an outbound route to reach the Software.com endpoint (https://app.software.com/api/v1/otel/claude/metrics). Your cloud-native exporters can stay on internal routes — AWS services via VPC Endpoints , Google Cloud services via Private Google Access , Azure services via Private Endpoints  — but the Software.com exporter requires public internet egress.

If your network has a NAT Gateway (AWS), Cloud NAT (Google Cloud), or NAT Gateway (Azure), no additional configuration is needed. The otlphttp/software exporter will route through it automatically.

If your network does not have outbound NAT (common in locked-down environments that exclusively use VPC Endpoints, Private Google Access, or Azure Private Endpoints), you can route the Software.com exporter through your organization’s HTTP proxy. Most enterprise environments already run a forward proxy for controlled internet egress.

To configure the collector to use a proxy, set the HTTP_PROXY and HTTPS_PROXY environment variables on the collector process. The OTLP/HTTP exporter respects these standard environment variables and routes outbound requests through the proxy automatically.

AWS — ECS task definition:

{
  "containerDefinitions": [
    {
      "name": "otel-collector",
      "image": "amazon/aws-otel-collector:latest",
      "environment": [
        { "name": "HTTPS_PROXY", "value": "http://your-proxy.internal:3128" },
        { "name": "NO_PROXY", "value": "localhost,169.254.169.254,monitoring.us-west-2.amazonaws.com,logs.us-west-2.amazonaws.com,xray.us-west-2.amazonaws.com" }
      ]
    }
  ]
}

Google Cloud — GKE pod spec:

containers:
  - name: otel-collector
    image: otel/opentelemetry-collector-contrib:latest
    env:
      - name: HTTPS_PROXY
        value: "http://your-proxy.internal:3128"
      - name: NO_PROXY
        value: "localhost,169.254.169.254,metadata.google.internal,monitoring.googleapis.com,logging.googleapis.com,cloudtrace.googleapis.com"

Azure — AKS pod spec:

containers:
  - name: otel-collector
    image: otel/opentelemetry-collector-contrib:latest
    env:
      - name: HTTPS_PROXY
        value: "http://your-proxy.internal:3128"
      - name: NO_PROXY
        value: "localhost,169.254.169.254,monitor.azure.com,management.azure.com,login.microsoftonline.com"

The NO_PROXY variable is important — it ensures that traffic to your cloud provider’s service endpoints and instance metadata service bypasses the proxy and continues to use internal routes. Only the Software.com exporter traffic flows through the proxy. Adjust the NO_PROXY list to include any other internal endpoints your collector communicates with.

Data collected

Claude.ai Enterprise

We pull organization-level usage analytics from the Anthropic Analytics API.

Claude.ai Team and Self-Hosted Claude

We receive metrics every hour, such as lines added, commits, pull requests, tokens, and related usage. For full details on what Claude Code sends, see Monitoring usage  in Claude Code’s OpenTelemetry documentation.

We do not collect logs (for example, prompts). Only aggregated metrics are sent.

For self-hosted deployments using the fan-out collector, Software.com receives only the metrics pipeline. Traces and logs remain in your own observability backend and are never sent to Software.com.

Claude Developer Platform

We pull from two Anthropic API endpoints:

We use the organization users response to match Claude users to Git users. For full parameter and response details, see Claude Code Analytics API  and Administration API .