AI Engineering Analytics
paceflow is a local-first CLI for understanding whether coding-agent work is actually helping.
It reads local Claude Code, Codex, Cursor, and OpenCode history plus git metadata, then turns that evidence into four practical report views:
session: were you getting leverage, or just steering and retrying?delivery: did AI-heavy work turn into commits that reached review or mainline?quality: did accepted AI-generated code hold up, or did it churn out later?cost: what did useful work cost in tokens, compute estimates, and accepted output?
The point is not to count prompts or accepted lines for their own sake. The point is to help individual engineers improve how they work with coding agents.
What It Does
Most AI coding workflows feel productive in the moment. That does not mean they were useful.
paceflow helps spot patterns that are easy to miss:
- sessions that felt busy but produced little accepted output
- AI-heavy work that never made it to mainline
- accepted code that landed quickly and was removed soon after
- costly sessions that produced little accepted or mainline output
If those patterns show up repeatedly, you usually need tighter task slicing, better upfront constraints, earlier validation, or stricter review before accepting generated code.
Quick Start
Run paceflow from a git repository you want to analyze:
The first ingest reads local assistant history, scans git metadata, and creates the local analytics database at ~/.paceflow/paceflow.db.
Use this loop when you are trying the tool for the first time:
- Run
paceflow ingestafter you have local Claude Code, Codex, Cursor, or OpenCode history on the machine. - Run
paceflow sessionto see whether sessions are producing accepted code and commits. - Run
paceflow deliveryto see whether AI-heavy commits reached PRs or mainline. - Run
paceflow qualityto see whether AI-heavy code churned, drew follow-up fixes, or was reverted. - Run
paceflow costto compare API-equivalent cost against accepted and mainline output. - Re-run
paceflow ingestwhenever you have new sessions, commits, or GitHub PR metadata to refresh.
For GitHub PR reach and PR merge metrics, save a token and ingest again:
PACEFLOW_GITHUB_TOKEN can be used for CI or one-off overrides.
Installation
Install a prebuilt binary with cargo-binstall (recommended if you have cargo):
Or compile from crates.io:
Build and install from a local checkout:
Prefer not to build from source? Download a prebuilt release from GitHub Releases.
Supported release targets:
| Platform | Asset |
|---|---|
| Windows x86_64 | paceflow-x86_64-pc-windows-msvc.zip |
| Linux x86_64 (glibc) | paceflow-x86_64-unknown-linux-gnu.tar.gz |
| macOS Apple Silicon | paceflow-aarch64-apple-darwin.tar.gz |
See packaging/INSTALL.md for platform-specific install commands, macOS Gatekeeper notes, and optional path overrides.
If team hooks or setup scripts will call paceflow, make sure the binary is available on PATH; see Add paceflow To PATH.
Requirements:
gitmust be installed and available onPATH- local Claude Code, Codex, Cursor, or OpenCode history must exist on the machine you run
paceflowon - GitHub PR sync requires
paceflow github tokenorPACEFLOW_GITHUB_TOKEN
Reports
By default, the four report commands compare outcomes by model.
Use --overall when you want one rolled-up summary row:
Use --model <provider/name> to keep the same report but narrow it to one model:
The reports answer four questions:
session: which models or providers are efficient, noisy, or stuck in loops?delivery: which AI-heavy changes actually turn into shipped work?quality: which AI-heavy changes remain durable versus needing cleanup?cost: which sessions or groups produce useful output for the spend?
For metric definitions, status bands, grouped report behavior, and interpretation guidance, see docs/USER_GUIDE.md.
Common Options
session, delivery, quality, and cost share the same filter interface:
--from YYYY-MM-DD --to YYYY-MM-DDfocuses a time window.--repo /path/to/repoanalyzes a specific repository.--all-projectsshows results across all tracked projects instead of defaulting to the current repo.--provider codex,--provider cursor,--provider claude, or--provider opencodefilters by provider.--group-by provider,--group-by model,--group-by branch, or--group-by taskchanges the comparison dimension.--branch <name>or--task ABC-123narrows reports to a branch or ticket-like task key.--limit <n>controls the number of grouped rows shown.
Useful examples:
Use paceflow <command> --help to see command-specific options and metric notes.
Troubleshooting
Reports Say There Are No Rows
Run a fresh ingest from a repository that has local assistant history and git commits:
If session --all-projects has rows but the plain report does not, you are probably running paceflow from a repo that has no matched sessions yet. Use --all-projects, run from the target repo, or pass --repo /path/to/repo.
GitHub PR Metrics Are Empty Or Stale
GitHub PR reach and PR merge metrics need a token and a fresh ingest:
The saved token lives locally under the PACEFLOW_HOME base directory. PACEFLOW_GITHUB_TOKEN can be used for CI or one-off overrides.
Start Over With A Clean Database
If reports look stale, an ingest was interrupted, or you want to rebuild everything from local source data, delete the local analytics database and ingest again.
If you use a custom PACEFLOW_HOME, remove the database under that directory instead:
This only removes Paceflow's derived analytics database. It does not delete Claude Code, Codex, Cursor, OpenCode, git, or GitHub source data.
Cursor Data Is Missing
Paceflow looks for Cursor state/history in the OS config directory under Cursor/User. If your Cursor data lives somewhere else, point Paceflow at it before ingesting:
More Documentation
- User Guide: report interpretation, metric definitions, status bands, and grouping behavior
- Install Notes: release assets, platform commands, and local data requirements
- Development Notes: source workflows, tests, profiling, and validation commands
- Architecture: ingestion, storage, and analytics pipeline internals