Productivity
The Productivity page answers a different question than Usage. Usage tells you what AI resources your team consumed — tokens, cost, requests. Productivity tells you what came out the other end: how many coding sessions ran, how many commits and pull requests the agent created, and how much code it wrote and removed.
The three sections of the page — Sessions, Merge Activity, and Code Changes — each measure a different layer of output. Read together, they let you assess whether AI coding activity is actually translating into shipped work, and where sessions are happening but not producing results.
What the numbers measure
Before interpreting the page, it helps to understand how the underlying metrics are collected, because they are narrower than they might first appear.
Sessions count agent process lifetimes. One session starts when you launch the agent and ends when the process shuts down. Sub-agents spawned during a session — for example, the worker agents in a Ferment run — share the same session ID and do not add to the count. The number reflects top-level invocations, not total agent activations.
Commits and pull requests are detected from the agent's bash tool calls during a session. A commit is counted when the agent runs git commit; a PR is counted when it runs gh pr create. This means the numbers reflect work the agent completed autonomously — manual commits and PRs you create yourself are not included, and neither is any git activity that happened outside the agent process.
Lines of code are counted from the agent's file edit tool calls. Each time the agent writes or edits a file, it diffs the old and new content to produce a line count. This is not the same as running git diff at the end of a session: it captures only what the agent wrote directly, at the moment it wrote it.
Attribution is based on the API key used during the session. The agent resolves the user by calling /v1/me with that key. If your team uses a shared API key — as in the managed settings setup — all sessions will be attributed to the same identity and the page will show team-wide totals with no per-user breakdown. Per-user attribution requires each developer to use their own key; see Collect Claude Code usage metrics with Kimchi.
Sessions
The Sessions section shows how frequently the agent is being used. The KPI cards give you total sessions, daily average, and the peak day for the selected time range. The bar chart shows daily session volume, which is useful for spotting whether usage is consistent or concentrated in bursts.
A large gap between session count and the commit or PR numbers in the next section is the most useful signal here: it suggests sessions are running — exploration, investigation, partial attempts — without producing completed, merged work.
Merge Activity
The Merge Activity section tracks the version control output the agent produced: pull requests (via gh pr create) and commits (via git commit). Toggle between the two views using the button in the top right. Each view shows the same KPI cards — total, daily average, peak day — and a bar chart of daily volume.
Because these numbers only capture what the agent did autonomously, they will always be lower than your repository's actual commit and PR history. Use them as a relative signal — trends and ratios — rather than an absolute record of team output.
Code Changes
The Code Changes section shows the volume of code the agent wrote and removed. Lines Added and Lines Removed are counted per edit tool call; Net Change is the difference. The area chart shows additions (green) and removals (orange) over time.
The ratio between additions and removals gives you a rough read on what kind of work the agent is doing. Heavy additions with few removals suggest net-new feature work. A period where removals are high relative to additions usually means refactoring or cleanup. Consistently near-zero numbers in both directions — while Sessions are active — may indicate the agent is spending most of its time exploring and reading rather than writing.
Practical uses
- Session-to-PR conversion: divide Total PRs by Total sessions over a 30d window. A ratio well below 1 is normal — not every session ends in a PR — but if it's very low, sessions may be running without clear completion criteria. Review how tasks are being handed to the agent.
- Shared-key teams: if your setup uses a shared API key, the Productivity page reflects the whole team's output as one. That's useful for org-level reporting but useless for individual attribution. Switch to per-user keys if you need the latter.
- Validating rollout: after deploying Kimchi Coding to a new team, the Sessions chart is the fastest way to confirm the tooling is being used. Flat counts in the first week usually mean a configuration issue or a need for more enablement.