Prelude

The systemprompt.io Control Center tracks six performance metrics that quantify how you work with Claude Code. These are not vanity numbers. Each metric is derived from deterministic event data captured during every Claude Code session, giving you an accurate picture of your interaction patterns, efficiency, and growth over time.

If you have ever looked at the metrics cards in the Control Center and wondered what exactly they measure, how they are calculated, or what a good score looks like, this guide covers all of it.

The Problem

Claude Code sessions generate enormous amounts of data. Every file read, every edit, every bash command, every prompt you submit, every error that occurs — all of it is captured as structured events. Without metrics, that data is just noise. You cannot tell whether today was more productive than yesterday, whether your error rate is climbing, or whether you are actually using the tools available to you.

The six metrics in the Control Center distill that raw event data into actionable numbers. They answer specific questions: How fast am I iterating? How clean is my execution? Am I parallelising effectively? How much data is flowing through my sessions? Am I using the full toolkit? Am I delegating work to subagents?

The Journey

APM (Actions Per Minute) {#apm}

APM measures the rate of meaningful interactions between you and Claude Code per minute of session time. It counts every tool execution (file reads, edits, searches, bash commands) and every prompt you submit.

Formula:

APM = (tool_uses + prompts) / session_duration_minutes

Data source: plugin_session_summaries.tool_uses, plugin_session_summaries.prompts, and session duration calculated from started_at / ended_at timestamps.

Why it matters. APM measures your iteration speed with AI. Higher APM indicates tighter feedback loops — you are giving instructions, reviewing results, and course-correcting rapidly. In StarCraft terms, this is your raw actions per minute. A session where you submit 5 prompts and Claude executes 45 tool calls over 10 minutes gives you an APM of 5.0. Professional StarCraft players average 300+ APM; effective Claude Code users typically range 5–30 APM depending on task complexity.

How to interpret your APM:

  • Below 5 — May indicate long-running autonomous tasks or idle time within sessions. Not necessarily bad if Claude is executing complex multi-step operations.
  • 5 to 20 — Typical range for interactive development sessions. You are actively steering Claude and reviewing outputs.
  • Above 20 — Rapid interactive sessions with tight feedback loops. Common during debugging, refactoring, or exploratory coding where you are giving frequent corrections.

EAPM (Effective Actions Per Minute) {#eapm}

EAPM is APM with errors removed. It counts only successful tool executions and prompts, excluding failed tool calls.

Formula:

EAPM = (tool_uses + prompts - errors) / session_duration_minutes

Data source: Same fields as APM, plus plugin_session_summaries.errors.

Why it matters. EAPM separates signal from noise. If you have 50 APM but 20 of those actions are errors, your EAPM of 30 reveals your true productive pace. In StarCraft, this is the difference between spam-clicking and meaningful actions. A high APM with low EAPM suggests you may need to adjust your prompts or tool configurations to reduce errors.

How to interpret the gap between APM and EAPM:

  • EAPM close to APM — Clean execution. Your sessions run with minimal errors, meaning prompts are clear and tool configurations are correct.
  • EAPM significantly lower than APM — High error rate worth investigating. Common causes include misconfigured tools, ambiguous prompts that lead Claude down wrong paths, or working in environments with flaky dependencies.

Concurrency {#concurrency}

Concurrency measures the number of Claude Code sessions running simultaneously. It is calculated by counting overlapping session time windows — sessions where the started_at to ended_at ranges overlap.

Formula:

Peak = maximum number of sessions with overlapping time ranges
Average = time-weighted mean of concurrent session count over the day

Data source: plugin_session_summaries.started_at and plugin_session_summaries.ended_at, calculated using a sweep-line algorithm.

Why it matters. Concurrency shows how effectively you parallelise AI work. Running multiple Claude Code sessions on different tasks simultaneously is like managing multiple bases in StarCraft — it multiplies your output. Peak concurrency of 4 means you had 4 AI assistants working in parallel at one point during the day.

How to interpret your concurrency:

  • 1 — Serial work. One session at a time. This is fine for focused, complex tasks but leaves throughput on the table.
  • 2 to 3 — Moderate parallelism. You are running a couple of sessions simultaneously, perhaps one for a main task and another for a side task or code review.
  • 4 or higher — Power user territory. You are leveraging multiple sessions effectively, delegating independent tasks to separate Claude Code instances and managing them concurrently.

Throughput {#throughput}

Throughput measures the total data volume exchanged between you and Claude Code. This includes all content sent to the AI (prompts, file contents, tool inputs) and all content received (responses, tool outputs, generated code).

Formula:

Total = content_input_bytes + content_output_bytes
Rate = total_bytes / total_active_session_seconds

Data source: plugin_session_summaries.content_input_bytes and plugin_session_summaries.content_output_bytes.

Why it matters. Throughput reflects the volume of work being processed. High throughput means large files are being read, significant code is being generated, or complex analyses are being performed. In StarCraft terms, this is your resource gathering rate — how much material flows through your AI pipeline. A session generating 2 MB of output is doing substantially more work than one generating 50 KB.

How to interpret your throughput:

  • Displayed as total bytes (KB/MB) and rate (bytes per second).
  • Higher throughput generally correlates with more productive sessions, but context matters. A refactoring session that touches many files will naturally have higher throughput than a focused debugging session.
  • Sudden throughput drops may indicate sessions that stall or hit context limits.

Tool Diversity {#tool-diversity}

Tool diversity is the number of unique tools used across all sessions in a day. Tools include Read (file reading), Edit (file modification), Bash (command execution), Grep (code search), Glob (file search), Write (file creation), and Agent (subagent delegation).

Formula:

Tool Diversity = COUNT(DISTINCT tool_name) WHERE event_type = 'PostToolUse'

Data source: plugin_usage_events.tool_name filtered to successful tool executions.

Why it matters. Tool diversity indicates how versatile your AI usage is. Using only Read and Bash is like building only one unit type in StarCraft — it works, but you are not leveraging the full toolkit. Users who employ Read, Edit, Grep, Glob, Bash, Write, and Agent have a richer interaction pattern and typically complete more complex tasks. A diversity of 7 (all tools) suggests sophisticated multi-step workflows.

How to interpret your tool diversity:

  • 1 to 2 — Basic usage. You may be using Claude Code primarily for reading files or running commands. Consider whether Edit, Grep, or Glob could speed up your workflow.
  • 3 to 4 — Moderate diversity. You are using a reasonable subset of the available tools.
  • 5 or higher — Advanced usage. You are leveraging the full Claude Code toolkit, including search tools and subagent delegation.

Multitasking Score {#multitasking}

The multitasking score is a composite metric (0–100) measuring how effectively you delegate and parallelise work. It factors in subagent spawning (Claude creating helper agents) and session concurrency.

Formula:

Multitasking = min(100, (subagent_spawns × 2 + peak_concurrency × 3) / session_count × 10)

Data source: plugin_session_summaries.subagent_spawns, peak concurrent sessions, and total session count.

Why it matters. The multitasking score captures your ability to leverage AI at scale. Spawning subagents means you are letting Claude break complex tasks into parallel subtasks — the AI equivalent of army splitting in StarCraft. Combined with session concurrency, this shows whether you are using AI as a single worker or as a coordinated team.

How to interpret your multitasking score:

  • 0 to 20 — Sequential, single-task usage. You are working with one Claude session at a time without subagent delegation. This is fine for simple tasks.
  • 20 to 50 — Moderate delegation. You are either running concurrent sessions or triggering subagent spawns, but not both heavily.
  • 50 or higher — Heavy parallelism and delegation. You are running multiple concurrent sessions and using subagents within those sessions. This is the pattern of users who treat Claude Code as a team rather than a single assistant.

Metric Combinations: Reading the Full Picture

Individual metrics tell you something useful. Metrics read together tell you what is actually happening in your workflow.

Speed vs Accuracy: APM + EAPM

The gap between APM and EAPM is your error rate. If your APM is 15 and your EAPM is 12, you have a 20% error rate. Track this ratio over time rather than absolute values.

Pattern APM EAPM Ratio Diagnosis
Clean execution 12 11.5 96% Prompts are clear, tools are configured correctly
Moderate noise 18 13 72% Some errors, likely from exploratory work or unfamiliar codebases
High error rate 25 10 40% Significant retry overhead. Check for misconfigured tools, ambiguous prompts, or flaky test suites

When the ratio drops below 70%, investigate your error sources. The most common causes are: running bash commands that fail due to missing dependencies, file edits that conflict with concurrent changes, and grep patterns that match nothing. Each of these wastes a tool call and time.

Efficiency vs Scale: EAPM + Concurrency

High EAPM with concurrency of 1 means you are fast but sequential. Low EAPM with concurrency of 4 means you are parallelising but each session is sluggish. The combination reveals your actual throughput capacity.

A user with EAPM of 10 and concurrency of 3 is effectively producing at a rate of 30 effective actions per minute across their workspace. Compare that to EAPM of 20 with concurrency of 1 — technically faster per session but lower total output.

Breadth vs Depth: Tool Diversity + Throughput

Low tool diversity with high throughput suggests you are doing repetitive bulk operations (reading many files, running many bash commands). High tool diversity with moderate throughput suggests complex multi-step workflows that leverage the full toolkit.

Diversity Throughput Pattern
2 (Read + Bash) High (5 MB+) Bulk analysis or log review
4 (Read + Edit + Bash + Grep) Moderate (500 KB–2 MB) Standard development workflow
6+ (all tools) Moderate to High Complex refactoring or multi-repository work
7 (all tools including Agent) Any Advanced orchestration with subagent delegation

Delegation Effectiveness: Multitasking + Concurrency

The multitasking score combines subagent usage and session concurrency. But the two components tell different stories. High subagent spawns within a single session means Claude is breaking down complex tasks internally. High concurrency without subagents means you are manually managing parallel sessions.

The most effective pattern is both: multiple concurrent sessions where Claude also spawns subagents within those sessions. This represents full utilisation of Claude Code's parallelism capabilities.

Session Profiles: What Good Looks Like

Different types of work produce different metric signatures. Comparing your metrics to these profiles helps you understand whether your numbers are typical or indicate something worth adjusting.

The Debugger

Tight feedback loops, lots of reads and searches, few edits until the fix is found.

Metric Typical Range
APM 8–20
EAPM 6–18
Concurrency 1
Throughput 200 KB–1 MB
Tool Diversity 4–5 (Read, Grep, Bash, Edit, Glob)
Multitasking 0–15

The Refactorer

High throughput from touching many files, moderate APM, high tool diversity.

Metric Typical Range
APM 10–25
EAPM 9–23
Concurrency 1–2
Throughput 1–10 MB
Tool Diversity 5–7
Multitasking 10–40

The Architect

Multiple concurrent sessions, subagent delegation, exploring different approaches in parallel.

Metric Typical Range
APM 5–15 per session
EAPM 4–14 per session
Concurrency 3–6
Throughput 2–15 MB total
Tool Diversity 6–7
Multitasking 40–100

The Reviewer

Low APM, high read-to-edit ratio, focused on understanding code rather than changing it.

Metric Typical Range
APM 2–8
EAPM 2–7
Concurrency 1
Throughput 500 KB–3 MB
Tool Diversity 3–4 (Read, Grep, Glob, Bash)
Multitasking 0–5

Improving Your Metrics

Metrics are descriptive, not prescriptive. Chasing higher numbers for their own sake is counterproductive. But if you notice patterns that suggest inefficiency, here are specific actions tied to each metric.

Raising EAPM (reducing errors)

  1. Write more specific prompts. Instead of "fix the tests", say "fix the failing test in test_auth.rs by updating the mock to return a 200 status". Specific prompts reduce the chance of Claude taking wrong turns.
  2. Pre-check your environment. Many errors come from missing dependencies, wrong working directories, or stale build artifacts. Running a quick build or test before starting a Claude session eliminates these.
  3. Use /compact to manage context. When sessions get long, Claude's context fills up and error rates increase. Compacting the conversation keeps the AI focused on relevant context.

Raising Concurrency

  1. Identify independent tasks. If you have a feature to build and tests to write, those can run in separate sessions. If you have two unrelated bugs, each gets its own session.
  2. Use worktrees. Git worktrees let multiple Claude Code sessions operate on the same repository without file conflicts. Each session gets its own working copy.
  3. Start with two sessions. The jump from 1 to 2 concurrent sessions is the biggest productivity gain. Do not try to manage 5 sessions on day one.

Raising Tool Diversity

  1. Use Grep instead of Bash grep. Claude's built-in Grep tool is faster and provides structured output. If you see Claude running grep -r, your tool diversity is artificially low.
  2. Use Glob for file discovery. Instead of find . -name "*.rs", let Claude use the Glob tool. Faster and counts toward diversity.
  3. Delegate with Agent. If a task has independent subtasks (research one component, modify another), tell Claude to use subagents. This raises both tool diversity and multitasking score.

Raising Throughput

Throughput is primarily a function of task complexity. You do not need to artificially inflate it. But if throughput is consistently low, you may be under-utilising Claude:

  1. Let Claude read more context. Instead of pasting snippets, let Claude read the full files. More input context generally leads to better output.
  2. Ask for complete implementations. Instead of asking Claude to outline an approach, ask it to write the full code. This generates more output and typically saves you time.

How Data Is Collected

All metrics are derived from hook events that Claude Code sends to systemprompt.io. Every tool execution, prompt submission, error, and session lifecycle event (start, stop) is captured as a deterministic event with precise timestamps and byte counts. No estimation or sampling is involved — every metric is calculated from actual observed events.

When you install the systemprompt.io hooks into your Claude Code configuration, they fire HTTP requests to the platform on each lifecycle event. These events are stored as raw records and then aggregated into the metrics you see in the Control Center.

Event Types

The following event types feed into the metrics calculations:

  • PostToolUse — A tool was successfully executed (Read, Edit, Bash, Grep, Glob, Write, Agent). This is the primary event for APM, EAPM, and tool diversity calculations.
  • PostToolUseFailure — A tool execution failed. Used to calculate the error count that separates EAPM from APM.
  • UserPromptSubmit — You submitted a prompt to Claude. Counted in both APM and EAPM.
  • SessionStart / SessionEnd / Stop — Session lifecycle events. Used to calculate session duration, concurrency, and to delineate session boundaries.
  • SubagentStart / SubagentStop — Subagent lifecycle events. Used in the multitasking score calculation to track how many subagents were spawned.

Daily Reports

These metrics are aggregated into daily summaries at 11 PM UTC. The aggregation process calculates totals, averages, and peaks across all sessions for the day. An AI-generated analysis accompanies each daily summary, providing insights about patterns, identifying skill gaps, and offering recommendations for improving your workflow.

Historical data is preserved indefinitely, allowing you to track trends over weeks and months. The Control Center displays both the current day's live metrics and historical daily summaries for comparison.

Tracking Progress Over Time

The Control Center preserves daily summaries indefinitely. This history is where the real value lives. A single day's metrics are a snapshot. A week of daily summaries shows a trend.

What to look for weekly

Review your metrics at the end of each week. Focus on three questions:

  1. Is my EAPM/APM ratio improving? A rising ratio means fewer errors per session. This is the most directly actionable trend because it responds to better prompt quality and environment hygiene.
  2. Is my concurrency stable or growing? If you are stuck at concurrency 1 week after week, you have not adopted parallel workflows. Even moving to 2 concurrent sessions doubles your effective capacity.
  3. Has my tool diversity changed? If you added a new tool to your workflow (for example, starting to use Agent for subagent delegation), it should show up as a bump in tool diversity. If it does not, the tool is not being triggered.

Setting personal baselines

After two weeks of data, calculate your averages for each metric. These become your personal baselines. Deviations from baseline are more meaningful than absolute numbers.

For example, if your baseline EAPM is 12 and you see a day at 5, something changed. Maybe you worked in an unfamiliar codebase, or your test suite was broken, or you spent the day on a task that required more reading than writing. The metric flags the deviation; you supply the context.

Comparing across projects

Different projects produce different metric profiles. A greenfield project typically shows higher throughput and higher tool diversity (lots of file creation and search). A maintenance project shows lower throughput but potentially higher EAPM (focused, precise edits). Do not compare metrics across fundamentally different project types.

Detailed Metric Documentation

Each metric has a dedicated reference page with additional examples, edge cases, and technical details:

The Takeaway

The six metrics in the Control Center give you a complete, deterministic picture of how you interact with Claude Code. APM and EAPM measure your speed and accuracy. Concurrency and multitasking score measure your ability to parallelise. Throughput measures the volume of work flowing through your sessions. Tool diversity measures the breadth of your toolkit usage.

None of these metrics have a universally "correct" value. A focused debugging session will naturally have different metric profiles than a large refactoring session. The value is in tracking your own patterns over time, identifying sessions where metrics deviate from your norm, and understanding why.

Read them in combination, not isolation. A high APM with low EAPM means errors are eating your speed. High concurrency with low tool diversity means you are running parallel sessions but each one is doing simple work. High throughput with low EAPM means large volumes of data are flowing but much of the work is being retried.

Use the daily AI-generated insights as a starting point, then drill into the metrics that matter most for your workflow. If you are consistently seeing a gap between APM and EAPM, focus on reducing errors. If your concurrency is always 1, consider whether some tasks could run in parallel. If your tool diversity is low, explore whether Grep or Glob could replace manual file navigation.

The data is there. The metrics make it legible.