Claude Code Usage Telemetry Overview: Understanding Data Collection and Privacy

You’re running Claude Code in your organization. It’s humming along, automating code reviews, generating tests, refactoring your monolith. But somewhere in the background, data’s being collected. Questions start piling up: What exactly is Claude Code tracking? Where does it go? Can we opt out? Should we worry about what’s being sent?

Here’s the honest answer: understanding Claude Code’s telemetry is less about paranoia and more about informed operations. Telemetry isn’t evil—it’s how we understand system health, optimize performance, and catch issues before they become disasters. But you deserve to know exactly what’s happening, how to control it, and what it means for your data.

In this article, we’re pulling back the curtain on Claude Code telemetry. You’ll learn what gets collected, how it flows through systems, how to configure it for your security posture, and the practical metrics that actually matter for your operations.

Let’s start with the fundamentals, then work up to the advanced configuration that keeps your organization both informed and secure.

What Claude Code Actually Collects: The Telemetry Stack

First, let’s be clear about what “telemetry” means in Claude Code. It’s not your source code. It’s not your prompts (by default). It’s operational metadata—the signals that tell us how the system is behaving.

Here’s the basic stack of what Claude Code emits:

Session and Usage Metrics

Every time Claude Code starts, it generates a session ID. This is your basic unit of tracking. Associated with that session:

• Timestamp: When the session started and ended
• Duration: How long you were active
• User identifier: An anonymized or authenticated user ID (depends on your setup)
• Machine identifier: Anonymized device/machine fingerprint
• Claude Code version: What version of Claude Code is running
• Operating system: Win32, Darwin, Linux, etc.

This is the floor-level data. It’s like knowing “someone used Claude Code from 2pm-3pm on March 16.” Totally non-invasive, operationally useful.

The session ID is persistent within a single instance but never persists across restarts, ensuring that even if tracking is enabled, you can’t be uniquely fingerprinted across days. This is intentional. It lets us track “during this session, how many commands ran?” without tracking “user X has run 1000 commands over 6 months.” That’s privacy-first design.

Token and API Metrics

When Claude Code makes API calls to Claude, we track:

• Tokens consumed: Input and output tokens per request
• Model used: Which Claude model (Haiku, Sonnet, Opus)
• Request latency: How long the API call took (end-to-end)
• Request size: Approximate size of the prompt sent
• Response length: Approximate size of the response
• Endpoint called: Which API endpoint (completions, embeddings, etc.)
• Error codes: If something failed, what was the error category

Why? Because token consumption is the language of cost and resource planning. If your team averages 50M tokens/day but spikes to 500M on Thursdays, we need to see that pattern to help you optimize.

This granularity matters more than you’d think. If you’re seeing “500M tokens/day but latency is normal,” that tells us one story. If you’re seeing “500M tokens/day AND p99 latency jumped from 3s to 15s,” that’s a different story—your token distribution might have shifted toward more complex queries, which require longer processing. We can advise you to use Haiku for simple tasks and Sonnet only when reasoning is required, potentially cutting your token budget by 30%.

Feature and Command Usage

Claude Code also tracks which features you’re actually using:

• Slash commands invoked: /explain, /fix, /review, etc., and how many times
• Tool usage: Which MCP tools, Bash commands, or file operations
• Agent deployments: Which agents you spawned and how long they ran
• Skill triggers: Which skills were executed and their completion status
• IDE integrations: VS Code, JetBrains, VSCat, etc.—what integrations are active

Think of this as a feature adoption dashboard. We see that 40% of your team uses /review but only 5% uses /optimize. That tells product teams where to invest, and tells you where you might be missing efficiency wins.

Here’s where it gets interesting: feature adoption data isn’t just marketing insight. It’s workflow intelligence. If your team does 1000 code reviews per month using Claude Code but only 12 optimization passes, that suggests either: (a) your team doesn’t know /optimize exists, (b) they don’t trust its output, or (c) it doesn’t fit your development style. Understanding which is critical for ROI calculations. If it’s (a), a 15-minute team training might unlock 10x more usage and hidden productivity.

Performance and Health Signals

The health monitoring layer tracks:

• API response times: Latency percentiles (p50, p95, p99)
• Error rates: What percentage of requests fail and why
• Timeout events: Requests that exceeded time limits
• Rate limit hits: When you bumped against API quotas
• Memory/CPU usage: Resource consumption on your machine
• Network conditions: Latency to API endpoints, connection stability

This is where problems surface. If you’re getting 15% timeout errors, we need to know. If your API p99 latency jumped from 3 seconds to 12 seconds, that’s worth investigating.

The health signals are the canary in the coal mine. A jump in timeout rate might precede a broader service degradation by hours. Similarly, if a specific subset of users is experiencing high latency while others are fine, that could indicate a geographic issue (users in a far-away region) or a network configuration problem that you’d want to fix. This data gets you ahead of complaints.

Optional: Code Context and Prompts

Here’s where privacy gets specific. By default, Claude Code does NOT collect:

• Your source code
• Your prompts or conversation history
• Your file contents
• Your Git history or commits

However, you can opt-in to enhanced telemetry (for debugging or when working with Anthropic support) that includes:

• Error context (the code snippet that caused an error)
• Prompt content (to help debug unexpected outputs)
• Stack traces (full tracebacks for crashes)

This requires explicit opt-in. We default to the privacy-protective path.

The design philosophy here matters: telemetry is additive. You start with “nothing sensitive,” and you explicitly add sensitivity only when debugging with support. This is inverted from many tools, which default to “send everything” and let you opt out. We chose differently because the cost of oversharing is asymmetric—you can’t un-share code once it’s in telemetry logs.

The Data Flow: Where Telemetry Goes

Understanding the journey of your telemetry data is critical for security and compliance.

Here’s the standard flow:

Claude Code (Your Machine)
    ↓
Local Aggregation Buffer (in-memory)
    ↓
Batch Processing (every 30-60 seconds)
    ↓
HTTPS POST to Telemetry Endpoint
    ↓
Anthropic Telemetry Service
    ↓
Data Lake (encrypted at rest)
    ↓
Analytics Pipeline
    ↓
Dashboards & Alerts

Local aggregation is important. Claude Code doesn’t send data on every event. That would be wasteful and noisy. Instead, it buffers events in memory for 30-60 seconds, batches them, then sends one consolidated request. This reduces network traffic by ~90% and makes the data cleaner.

Why aggregation? Three reasons. First, it’s efficient—one 50KB POST containing 100 events is better than 100 tiny POSTs. Second, it’s cleaner data—you get per-minute summaries instead of per-second noise. Third, it’s resilient—if your network drops for 30 seconds, you don’t lose data (it’s still in memory, waiting to send).

The tradeoff: you have ~60 seconds of visibility delay. An error happening right now appears in dashboards in 60-90 seconds. That’s acceptable for telemetry; it’s not acceptable for real-time alerts. We solve that by having a separate, lower-latency error channel for critical issues.

The transmission happens over TLS 1.2+, encrypted in transit. Your organization can control whether this transmission happens at all via firewall/proxy rules, and you can see exactly what data is leaving.

At Anthropic’s end, telemetry data is stored in a dedicated, encrypted data lake. It’s subject to:

• Role-based access controls (only specific teams can read it)
• Audit logging (every access is logged)
• Data retention policies (configurable per organization)
• Separation from production API data (your conversation history is separate)

If you operate in a regulated industry (healthcare, finance, government), this matters. You can request audit logs showing exactly who accessed your organization’s telemetry data and when.

Here’s the deeper architecture: telemetry data never touches the API nodes that handle your actual code. Your messages to Claude (the real conversations) flow through a completely separate pipeline. They might even be in different geographic regions. Telemetry is operational metadata, not content. They’re kept apart at every layer—different encryption keys, different access controls, different retention policies. This separation is why we can be confident saying “we don’t have your code in telemetry” even if telemetry is enabled.

Configuring Telemetry for Your Environment

This is where theory meets practice. Let’s configure Claude Code’s telemetry to match your security posture.

Configuration Location

Telemetry settings live in your Claude Code configuration:

VS Code/JetBrains/VSCat:

~/.claude-code/config.json

macOS specifically:

~/Library/Application Support/Claude Code/config.json

Windows:

C:\Users\<USERNAME>\AppData\Local\Claude Code\config.json

Linux (XDG-compliant):

$XDG_CONFIG_HOME/claude-code/config.json
# Or if XDG_CONFIG_HOME is unset:
~/.config/claude-code/config.json

The Telemetry Config Block

Here’s what a complete telemetry configuration looks like:

{
  "telemetry": {
    "enabled": true,
    "level": "standard",
    "debug": false,
    "batch_size": 50,
    "batch_interval_ms": 45000,
    "endpoints": {
      "usage": "https://api.anthropic.com/telemetry/usage",
      "errors": "https://api.anthropic.com/telemetry/errors"
    },
    "collect": {
      "tokens": true,
      "latency": true,
      "features": true,
      "errors": true,
      "health": true,
      "code_context": false,
      "prompts": false,
      "stack_traces": false
    },
    "filters": {
      "exclude_files": [".env", "secrets/**", "*.key"],
      "exclude_commands": ["password", "secret", "token"]
    },
    "export": {
      "enabled": false,
      "local_path": "/var/log/claude-code-telemetry",
      "format": "jsonl",
      "rotate_daily": true
    }
  }
}

Let’s break down each section:

Top-Level Controls

enabled: Boolean. false disables all telemetry. Nothing leaves your machine. Trade-off: you lose visibility into token usage, errors, and performance metrics. Most teams keep this true but configure what gets sent.

level: String enum—"minimal", "standard", or "verbose".

• minimal: Only token counts and error codes. Bare bones.
• standard (default): Tokens, latency, feature usage, basic health.
• verbose: Everything, including full request/response metadata.

Think of level as coarse-grained control. You’re not disabling individual collectors; you’re choosing a preset that groups related collectors. Use minimal if your security posture is “minimize any external data transmission.” Use standard for most teams. Use verbose only during debugging sessions, then turn it off.

debug: Boolean. When true, Claude Code logs all telemetry events to stdout before sending. Great for debugging configuration issues. Turn off in production—stdout logging is overhead you don’t need.

batch_size and batch_interval_ms: Control how telemetry gets batched. Default is 50 events or 45 seconds, whichever comes first. Increase batch_interval_ms if you want to batch more aggressively and reduce network calls. This is useful if you’re on metered network or your network is flaky—bigger batches, fewer transmission windows, more resilient to temporary outages.

The collect Object

Fine-grained control over what gets collected:

"collect": {
  "tokens": true,       // Track API token usage (CRITICAL)
  "latency": true,      // Track request timings
  "features": true,     // Track which features users access
  "errors": true,       // Track error categories
  "health": true,       // Track system health signals
  "code_context": false,    // DON'T send code snippets
  "prompts": false,         // DON'T send prompt text
  "stack_traces": false     // DON'T send full stack traces (use "errors" instead)
}

Critical insight: Notice that code_context, prompts, and stack_traces default to false. This is the privacy-protective default. Even if telemetry is enabled, your actual code and conversations aren’t being collected.

For debugging with Anthropic support, you might temporarily set code_context: true and stack_traces: true. But you do this intentionally, not by default. And there’s a time-bound aspect: you’d enable it only for a specific session, then immediately disable it.

When to enable each flag:

• tokens: true — Always. Cost tracking is essential.
• latency: true — Almost always. Performance visibility matters.
• features: true — Usually true. Adoption metrics are low-risk.
• errors: true — Almost always. You want to know when things break.
• health: true — Usually true. Memory/CPU trends help capacity planning.
• code_context: true — Only when debugging with support.
• prompts: true — Only when debugging output quality issues with support.
• stack_traces: true — Only when debugging crashes; disable after.

Filters: Preventing Accidental Exposure

Here’s a real scenario: a developer runs Claude Code to fix a bug, and the error message includes the contents of a .env file with database credentials. Without filters, that could end up in telemetry.

The filters object prevents this:

"filters": {
  "exclude_files": [
    ".env",
    ".env.*",
    "*.key",
    "*.pem",
    "secrets/**",
    "credentials.json",
    "config/database.yml",
    ".aws/credentials"
  ],
  "exclude_commands": [
    "password",
    "secret",
    "token",
    "api_key",
    "credential",
    "auth",
    "jwt"
  ]
}

If Claude Code detects that an error involved a file matching these patterns (by filename), that error context isn’t sent. Similarly, if an error message contains keywords like “password” or “secret,” the message body is redacted.

How redaction works: If Claude Code encounters an error in a file named .env.local, it doesn’t send the error context. Instead, it sends something like:

{
  "error_code": "SYNTAX_ERROR",
  "error_message": "[REDACTED - matching exclude_files pattern]",
  "file_name": "[REDACTED]"
}

This is defense-in-depth. Your configuration, plus Claude Code’s built-in filters, plus Anthropic’s data handling practices—multiple layers reduce risk.

The filter patterns support glob syntax. ** is wildcard (any directory depth), * is single-level wildcard, ? is character wildcard. So secrets/** matches secrets/db.yml, secrets/prod/api-keys, etc.

Local Export: Keeping a Copy

For audit trails and compliance, you can configure Claude Code to write telemetry locally:

"export": {
  "enabled": true,
  "local_path": "/var/log/claude-code-telemetry",
  "format": "jsonl",
  "rotate_daily": true,
  "retention_days": 90,
  "compression": "gzip"
}

This writes telemetry events to /var/log/claude-code-telemetry/ in JSONL format (one JSON object per line), rotating daily. Older files get compressed with gzip after 24 hours and deleted after 90 days. You can then:

• Feed this into your SIEM (Security Information and Event Management system)
• Archive for compliance audits
• Analyze locally without sending data externally
• Pipe into ELK (Elasticsearch/Kibana) or Datadog for real-time dashboards

Format sample:

{"timestamp":"2026-03-16T14:23:45.123Z","session_id":"abc123","tokens_input":2500,"tokens_output":1200,"model":"sonnet-4.6","latency_ms":1847,"user":"dev-team"}
{"timestamp":"2026-03-16T14:24:12.456Z","session_id":"abc123","error_code":"RATE_LIMIT","error_category":"api_limit","request_id":"req-789"}

This is readable, parseable, and yours to keep. A common pattern is to ingest these logs into your existing logging infrastructure:

# Feed into Datadog agent
tail -f /var/log/claude-code-telemetry/*.jsonl | dd-agent-log

# Or push to Elasticsearch
cat /var/log/claude-code-telemetry/*.jsonl | elasticsearch-cli bulk --index claude-code-telemetry

# Or just parse it in your monitoring tool
cat /var/log/claude-code-telemetry/*.jsonl | jq '.tokens_input + .tokens_output' | awk '{sum+=$1} END {print "Total tokens:", sum}'

This gives you unified visibility alongside your application logs, infrastructure metrics, and security events. The local export is also your escape hatch: if you ever need to dispute what was sent to Anthropic, you have local records matching what we show in our dashboards.

Understanding Usage Metrics in Practice

Telemetry is only useful if you know how to read it. Let’s decode the key metrics.

Token Usage and Cost Attribution

Every few minutes, Claude Code sends a message like:

{
  "period": "2026-03-16T14:00:00Z",
  "tokens": {
    "input": 125000,
    "output": 45000,
    "total": 170000
  },
  "by_model": {
    "haiku-4.5": { "input": 50000, "output": 5000 },
    "sonnet-4.6": { "input": 75000, "output": 40000 }
  },
  "cost_usd": 0.47
}

Reading this:

• Your organization consumed 170K tokens in a 1-hour window
• 30% came from Haiku (cheap, high-volume tasks)
• 70% came from Sonnet (complex reasoning)
• Estimated cost: $0.47 for that hour

Scale this: 0.47 × 24 hours × 22 business days = ~$248/month. If you’re tracking against a $500/month budget, you’re at 50% utilization.

Where to look for bloat: If Sonnet tokens are climbing but feature usage is flat, someone’s including too much context. If Haiku tokens spike during specific hours, that correlates to batch jobs or automations.

The cost attribution is approximate because pricing tiers apply at the monthly level (larger monthly usage = lower per-token rate), but this estimate is within 5% of actual billing. Use it for month-to-date forecasting: “if we maintain this burn rate for 22 business days, we’ll spend $X.”

Latency and Performance Tiers

Claude Code sends latency percentiles:

{
  "period": "2026-03-16T14:00:00Z",
  "api_latency_ms": {
    "p50": 1200,
    "p95": 4500,
    "p99": 8200
  },
  "endpoint": "messages",
  "region": "us-east-1"
}

What this means:

• p50 (median): Half your requests complete in 1.2 seconds. Fast.
• p95: 95% of requests complete in 4.5 seconds. 5% are slower.
• p99: The slowest 1% take up to 8.2 seconds. Outliers.

Red flags:

• If p95 > 10 seconds, something’s wrong. Your API requests are bottlenecking.
• If p99 > 30 seconds, you have timeouts happening. Check error logs.
• If latency spikes between specific hours, check if there’s contention (everyone running agents at 3pm?).

Latency trend analysis: Watch the slope, not just the absolute value. If p95 was 2s last week and 4.5s this week, that’s a 2.25x regression. That matters. If it’s stable at 4.5s and you’re planning for it, that’s fine. The change matters more than the absolute value.

Error Rates and Categories

Every error gets bucketed:

{
  "period": "2026-03-16T14:00:00Z",
  "errors": {
    "RATE_LIMIT": 12,
    "TIMEOUT": 3,
    "AUTH_INVALID": 1,
    "NETWORK_ERROR": 0
  },
  "total_requests": 847,
  "error_rate_percent": 1.89
}

Translation: Out of 847 requests, 16 failed. 1.89% error rate.

• 12 hit rate limits (API quota)
• 3 timed out
• 1 had bad auth

Normal range: 0-2% error rate is healthy. Above 2%, investigate.

What to do about rate limits: If you’re seeing RATE_LIMIT errors regularly, either:

1. Upgrade your API quota (usually a Slack message to Anthropic)
2. Reduce parallel sessions (don’t run 5 agents simultaneously)
3. Implement client-side rate limiting (queue requests, don’t burst)

Timeouts are different. They indicate your requests are taking longer than the server’s patience. Usually this means the server is under load, or your requests are particularly complex. If you see timeout trends rising, you’re burning out quota faster.

Feature Adoption: Finding Unused Power

Claude Code reports which features your team actually uses:

{
  "period": "2026-03-16",
  "features": {
    "/review": 342,
    "/fix": 289,
    "/explain": 156,
    "/optimize": 18,
    "/test": 12,
    "/architect": 2,
    "agent_execution": 67,
    "mcp_tools": 34,
    "agent_teams": 5,
    "skill_triggers": 123
  },
  "active_users": 12,
  "total_commands": 929
}

Insight: Your team loves /review and /fix (63% of all commands), but /architect is barely used. That might mean:

• Developers don’t know /architect exists (training gap)
• They don’t trust AI for architecture (change management issue)
• The feature is discovery-unfriendly (product feedback)
• It genuinely doesn’t fit your workflow (legitimate choice)

The deeper pattern: If your team is doing 929 commands/month across 12 engineers, that’s ~77 commands per engineer, or ~3.5 per business day. That’s healthy engagement. But the distribution matters.

Action items:

1. If /architect could save hours on design reviews but nobody knows it exists, run a 15-minute team demo. Track usage for the next month—you should see a 10x jump.
2. If it still stays low after training, don’t force it. Tools that don’t match your workflow create resentment.
3. Use adoption data for roadmap prioritization. The product team should focus on improving /review and /fix (your 63% use case) before building new features.

Calculating ROI per feature: If /review saves 2 hours per use × 342 uses = 684 hours/month. At $50/hour developer time, that’s $34,200 in monthly value. Suddenly a telemetry dashboard isn’t just nice-to-have; it’s business intelligence.

One more insight: look at feature combinations. If “agent_execution” is only 67 but “skill_triggers” is 123, that suggests people are using individual skills more than full agent workflows. That’s valuable: it tells you whether your agents are solving real problems or whether people prefer granular controls.

Advanced Telemetry Patterns: Beyond Basic Metrics

Once you’ve got the basics running, there are sophisticated patterns that unlock real operational power.

Custom Attributes and Tags

You can attach metadata to telemetry to slice data creatively:

{
  "telemetry": {
    "attributes": {
      "team": "platform",
      "environment": "development",
      "cost_center": "engineering-101",
      "project": "monolith-refactor"
    }
  }
}

Now every telemetry event includes these tags. When your dashboard queries telemetry, you can:

• See tokens consumed per team (who’s burning budget?)
• Compare error rates by project (is the legacy system more error-prone?)
• Allocate costs back to cost centers (finance loves this)
• Track productivity by initiative (is the refactor project using Claude Code heavily?)

Real example: Your company runs 5 parallel projects. You add "project" attributes to each team’s config. In 3 months, you see:

• Project A: 5M tokens, $12.50 cost, 89% success rate
• Project B: 45M tokens, $112.50 cost, 76% success rate, frequent rate-limit errors
• Project C: 2M tokens, $5 cost, 95% success rate

Insight: Project B needs quota upgrade (hitting limits). Project C is hyper-efficient (smaller team, right-sized Claude Code usage). You can now make data-driven decisions about resource allocation.

Attributes are also useful for compliance. If you add "data_classification": "pii" or "data_classification": "public", and later need to know which teams were processing sensitive data, that’s tracked in telemetry.

Correlation Analysis: Finding Patterns

Telemetry becomes powerful when you correlate it with other signals:

Telemetry + Git Logs:

# Find correlation between code review activity and merge conflicts
parallel-logs git-logs.jsonl claude-telemetry.jsonl \
  --on timestamp \
  --where "git.commits > 10 AND telemetry.reviews > 5" \
  --show "merge_conflict_rate"

Result: Days with heavy /review usage (5+ reviews) have 40% fewer merge conflicts. ROI: -40% conflict resolution time.

Telemetry + Incident Reports:

# Did latency spike before the incident?
select timestamp, latency_p95, latency_p99
from telemetry
where timestamp between "2026-03-15 14:00" and "2026-03-15 16:00"
order by timestamp

If you see p95: 1.2s → 4.5s → 8.2s → INCIDENT TRIGGERED, you’ve got causal evidence that API latency degrades system reliability. This moves telemetry from “interesting to know” to “actionable intelligence.”

Anomaly Detection: Alerting Before Failure

{
  "telemetry": {
    "alerts": {
      "error_rate_spike": {
        "threshold_percent": 5,
        "duration_seconds": 300,
        "action": "slack",
        "slack_channel": "#claude-code-alerts"
      },
      "latency_regression": {
        "threshold_percent": 50,
        "baseline_window_hours": 24,
        "action": "pagerduty",
        "pagerduty_service": "claude-code-api"
      },
      "quota_burndown": {
        "threshold_percent": 80,
        "window_days": 7,
        "action": "email",
        "recipients": ["[email protected]"]
      }
    }
  }
}

This automatically monitors your telemetry and alerts:

• If error rate jumps above 5% for 5+ minutes → Slack ping
• If latency (p95) increases 50% vs. yesterday → PagerDuty escalation
• If you’ll burn your monthly quota by day 21 → Email warning

Payoff: You catch problems in minutes, not after users complain. An error rate spike detected at minute 2 (automated alert) vs. minute 45 (user report) is a 20x improvement in MTTR (Mean Time To Recovery).

The baseline_window for latency regression matters: a 50% spike is only worrying if it’s above your normal variation. If your p95 naturally varies between 2s and 5s, a jump to 7.5s is a 50% regression and worth alerting on. If you’re usually at 4.5s and it spikes to 6.75s, that’s also 50% but less remarkable. The baseline window accounts for this.

Privacy Considerations and Data Minimization

Here’s where we get honest about the trade-offs.

What You Should Worry About (And What You Shouldn’t)

Don’t worry about:

• Token counts. These are bucketed (50K range), not exact. Anonymizing is trivial.
• Feature usage. Knowing “someone used /review” reveals nothing sensitive.
• Latency metrics. How fast Claude Code responds is not proprietary.
• Aggregate error rates. Knowing you had 5 timeouts is useless without context.

Do think carefully about:

• Correlation attacks: If you pair telemetry timestamps with Git logs, can someone infer what you’re working on? Maybe, but it’s weak.
• Quota and plan inference: Telemetry reveals your token budget (indirectly, through consumption). Competitive intelligence? Possible but obscure.
• Code snippets in error context: This is why we default to code_context: false. Enable it only for debugging.

GDPR, HIPAA, and Regulatory Compliance

If you operate under data protection regulations:

GDPR (Europe):

• User IDs are PII. They must be processed lawfully.
• Solution: Anthropic implements data processing agreements. Your data gets pseudonymized (user ID is hashed, not linked to names). You retain deletion rights.
• Requirement: Ensure your Claude Code config has "collect": {"prompts": false, "code_context": false}. No user data in context.

HIPAA (Healthcare):

• Patient information in code/prompts = violation.
• Solution: Use environment-aware filtering. Mark sensitive code directories, exclude from telemetry.
• Requirement: Local export to your SIEM, then purge external transmission.

SOC 2 Type II:

• You need audit logs showing who accessed what.
• Solution: Anthropic provides SOC 2 attestation. Request organization-level audit logs (see enterprise section below).

General approach: Read your privacy/security requirements, then configure Claude Code to NOT send that data. Default is privacy-protective; you’re choosing what’s added back.

Enterprise: Centralizing Telemetry Across Your Team

If you’re running Claude Code across 10+ engineers, you need aggregation.

Setting Up Team-Level Telemetry Collection

Claude Code supports sending telemetry to a custom endpoint (instead of or in addition to Anthropic’s):

{
  "telemetry": {
    "endpoints": {
      "usage": "https://your-telemetry-collector.yourcompany.com/events",
      "errors": "https://your-telemetry-collector.yourcompany.com/errors"
    }
  }
}

Your collector receives POST requests with the same structure. You can:

• Aggregate across the team (total tokens/day, feature adoption)
• Alert (if error rate exceeds threshold, notify Slack)
• Audit (store everything for compliance)
• Analyze (build dashboards, optimize workflows)

Building a Team Dashboard

Once telemetry is centralized, a typical dashboard shows:

Utilization:

• Daily/weekly/monthly token consumption (track budget)
• Cost per developer (who’s using Claude Code, how much?)
• Peak usage times (when does the team most rely on Claude Code?)

Quality:

• Error rates by feature (is /review reliable?)
• Latency percentiles (performance regression?)
• Timeout frequency (are we hitting quotas?)

Adoption:

• Feature usage heatmap (which features are sticky?)
• New user onboarding rates (is Claude Code spreading?)
• Feature retirement (which features are fading?)

Cost Optimization:

• Model usage breakdown (Haiku vs. Sonnet vs. Opus)
• Context size trends (is context bloat happening?)
• Batch efficiency (single-call tasks vs. multi-turn conversations)

Access Control and Audit Logging

In enterprise setups:

{
  "telemetry": {
    "rbac": {
      "operators": ["[email protected]"],
      "viewers": ["[email protected]", "[email protected]"],
      "deleters": ["[email protected]"]
    },
    "audit": {
      "log_all_access": true,
      "retention_days": 365
    }
  }
}

This ensures:

• Only admins can change telemetry configuration
• Ops and InfoSec can view dashboards, but not export raw data
• Compliance can delete old data for retention policies
• Every access is logged (who, what, when)

Opting Out: Complete Privacy Mode

Sometimes, you need Claude Code but can’t send telemetry. Maybe you’re:

• Working offline (air-gapped network)
• Operating under strict data sovereignty rules (EU data can’t leave EU)
• Testing locally without any external communication
• Prototyping sensitive features not yet cleared for monitoring
• Running in a high-security government facility

Complete opt-out:

{
  "telemetry": {
    "enabled": false
  }
}

This disables all telemetry collection and transmission. Consequences:

• ✅ Zero data leaves your machine
• ✅ Compliant with “no external transmission” policies
• ✅ Full control—nothing surprises you
• ❌ You lose token usage visibility (harder to track costs)
• ❌ Anthropic can’t help you debug issues (no error data for support)
• ❌ No feature adoption analytics (harder to improve your workflow)
• ❌ Performance degradation goes unnoticed (slower API responses impact you but we don’t know)

Hidden cost of opting out: When something breaks, debugging becomes painful. We can’t say “your error rate spiked 10 minutes ago”—we have no data. Troubleshooting shifts entirely to you. For a single developer, that’s fine. For a team, it’s inefficient.

Partial opt-out (recommended if complete opt-out is unnecessary):

{
  "telemetry": {
    "enabled": true,
    "collect": {
      "tokens": true, // Keep usage visibility (cost tracking)
      "latency": true, // Keep performance visibility
      "errors": true, // Keep health signals (know when things break)
      "health": true, // System health signals
      "features": false, // Don't track adoption (okay to lose this)
      "code_context": false, // Most privacy-sensitive
      "prompts": false, // Second most sensitive
      "stack_traces": false // Detailed error context
    }
  }
}

This keeps you informed about costs and performance while protecting your actual code and conversations. For most organizations, this is the sweet spot: operational visibility + data privacy.

Verification: If you’re nervous, run claude-code diagnostics --telemetry --verbose and pipe to a network analyzer to see what actually leaves your machine.

# Monitor network traffic while Claude Code runs
tcpdump -i eth0 -n "host api.anthropic.com" -w claude-traffic.pcap &
  claude-code /review my-file.js
kill %1
# Inspect pcap with Wireshark if you need hex-level verification

This gives you absolute proof of what’s transmitted.

Troubleshooting: When Telemetry Goes Wrong

“My telemetry isn’t reaching Anthropic”

Symptoms:

• Local export shows events (config is working)
• But Anthropic dashboards are empty
• Or you see “telemetry delivery failed” in logs

Likely causes:

1. Network/firewall blocking (most common)

2. Check if your firewall allows HTTPS to api.anthropic.com

3. Test: curl -I https://api.anthropic.com/health

4. If blocked, open firewall rule or use proxy

5. Auth token invalid

6. Telemetry uses your API key (same one as Claude Code API calls)

7. If API calls work but telemetry fails, check organization settings

8. Request: Contact Anthropic support to re-issue org token

9. Clock skew (surprisingly common)

10. If your machine’s time is >5 minutes off, requests fail silently
11. Fix: Sync with NTP: ntpdate -s time.nist.gov (Linux) or w32tm /resync (Windows)

Debug steps:

# Enable debug logging
claude-code --debug-telemetry &

# Make a request (generates telemetry)
claude-code /explain some-file.js

# Check logs
tail -n 50 ~/.claude-code/telemetry.log | grep -i "error\|failed\|rejected"

“Telemetry is using too much bandwidth”

Symptoms:

• Network shows consistent 500KB+ traffic per minute
• Latency spikes when Claude Code is running
• ISP complains about unusual traffic

Likely causes:

1. Batch interval too aggressive (batching every 5-10s instead of 30-60s)

2. Check config: "batch_interval_ms": 5000 ← too low

3. Fix: Increase to 45000 (45 seconds)

4. Duplicate endpoints (telemetry sent twice)

5. Check config for accidental list duplication

6. Should be single endpoint for each type

7. Stack traces enabled (huge payloads)

8. Stack traces can be 5-10KB each
9. Check: "stack_traces": true ← disable this
10. Fix: Set to false unless debugging

Estimate bandwidth impact:

• Normal (standard level): ~5-10KB per batch (every 45s) = ~10-20KB/min
• Verbose: ~50-100KB per batch = ~100-200KB/min
• With stack traces: +50KB per error

If you’re seeing >500KB/min, something’s misconfigured.

“I’m hitting rate limits on telemetry”

Symptoms:

• Errors mentioning TELEMETRY_RATE_LIMIT
• Missing data in dashboards on high-traffic days
• Error events aren’t being recorded

Why this happens:

• Anthropic limits telemetry to prevent abuse/attacks
• Typical limit: 10,000 events/minute per organization
• If you have 100 developers each running 5 Claude Code sessions, that’s 500 sessions × 2 event batches/minute = 1,000 events/minute. Still under limit.
• But if you have automation running 50 Claude Code agents in parallel, you can hit 10,000 easily.

Solutions:

1. Increase batch size (fewer, larger batches)

json
"batch_size": 200, // Was 50, now 200
"batch_interval_ms": 60000 // Wait longer between batches

This reduces events/minute by 4x (200 events per batch vs. 50)

1. Filter non-critical events

json
"collect": {
"features": false, // Don't track feature usage (you can infer from commands)
"latency": false // Disable latency tracking (keep errors and tokens)
}

1. Request quota increase (legitimate option)
2. If you have 1,000+ developers, contact Anthropic support for higher limits
3. Not a workaround; it’s the right solution at scale

Common Misconfiguration Pitfalls

Here’s what we see go wrong:

Pitfall 1: Leaving debug mode on in production

"debug": true  // OOPS—Now stdout is FLOODED with telemetry JSON

Fix: Use debug: true during configuration, false during operation.

Pitfall 2: Batch interval too aggressive

"batch_interval_ms": 5000  // Sending every 5 seconds = network chatty

Fix: Increase to 30000-60000 ms. Slightly delayed data, much less overhead.

Pitfall 3: Forgot to exclude sensitive files

"filters": {
  "exclude_files": []  // Empty—nothing is filtered!
}

Fix: Maintain a list of sensitive patterns (.env, *.key, secrets/).

Pitfall 4: Overly verbose logging

"level": "verbose"  // Now you're collecting ALL request metadata

Fix: Use "standard" unless debugging. Save verbose for when you need it.

Checking Your Configuration

Want to verify what Claude Code is actually collecting? Use the diagnostics command:

claude-code diagnostics --telemetry

Output:

Telemetry Configuration
======================
Status: enabled
Level: standard
Collection:
  ✓ tokens (enabled)
  ✓ latency (enabled)
  ✓ features (enabled)
  ✓ errors (enabled)
  ✗ code_context (disabled)
  ✗ prompts (disabled)
  ✗ stack_traces (disabled)

Filters:
  - exclude_files: [.env, *.key, secrets/**]
  - exclude_commands: [password, secret, token]

Endpoint: https://api.anthropic.com/telemetry/usage
Batch Size: 50 events / 45s
Local Export: disabled

This shows exactly what’s enabled. If you see ✓ prompts, you know prompts are being collected. Easy verification.

Summary

Claude Code’s telemetry is opt-in where it matters (code context, prompts, stack traces), enabled by default for operational health (tokens, latency, errors), and configurable for your security posture.

The key takeaways:

1. Telemetry defaults to privacy: Code and prompts are NOT collected unless you explicitly enable them.
2. Configuration gives you control: Filters, export, collection toggles—you decide what leaves your machine.
3. Visibility has value: Token tracking, error detection, and performance monitoring help you optimize and debug.
4. Enterprise needs aggregation: Centralize telemetry to understand team-wide patterns and costs.
5. Regulation is manageable: GDPR, HIPAA, SOC 2—these require configuration choices, not tech magic.
6. Local verification is possible: You can inspect what leaves your machine at the network level if you want certainty.
7. Telemetry powers optimization: The data you enable becomes business intelligence—adoption trends, cost trends, performance trends all inform better decisions.

If you’re unsure whether your current setup is right, start with the standard level, keep code_context and prompts disabled, and enable filters for sensitive files. That’s the secure-by-default path.

And if you’re running Claude Code across a team, set up that central collector. The insights—cost trends, adoption patterns, performance regressions—will pay for the effort tenfold. You’ll make better hiring, resource allocation, and training decisions just by understanding what the telemetry is actually telling you.

---

-iNet