kode stats — View Verification Statistics

kode stats parses the kode.log audit file and prints pass/fail rates, top-failing files, failure type breakdown, model usage, and a daily trend chart.

kode stats reads the JSONL audit log written by kode verify and kode loop and prints a rich summary of your project’s verification health. You get overall pass and fail rates, a ranked list of the most problematic files, a breakdown of which gate types are failing most often, a per-model usage table, and a visual daily trend chart — all from the terminal without leaving your workflow.

Synopsis

kode stats

What it does

kode stats opens <cwd>/logs/kode.log (or the directory you specify with --log-dir), parses each JSONL line as an audit entry, and computes:

• Overall totals — total verifications run, pass count, fail count, pass rate, and average verification duration.
• Failure type breakdown — which gate names are failing most frequently, sorted by count.
• Most failed files — the source files that appear in failure records most often (top N, configurable).
• Model usage — which LLM models were used and how many verifications each drove.
• Daily trend — a text bar chart of pass/fail counts for each of the last N days, so you can see whether verification health is improving or degrading over time.
• Recent verdicts — a one-line sparkline of the last 20 verification results using ✓ and ✗.

Flags

--log-dir · string · default: "<cwd>/logs"

Directory containing kode.log. Kode looks for a file named kode.log inside this directory. Use this flag if your audit log is in a non-standard location.

kode stats --log-dir /var/log/kode

--top · integer · default: "10"

Number of top-failing files to display in the “Most Failed Files” section.

kode stats --top 5

--days · integer · default: "14"

Number of days to include in the daily trend chart. Entries older than this window are parsed for aggregate totals but excluded from the chart.

kode stats --days 30

Example output

  ┌─ Kode Gatekeeper Statistics ──────────────────────────────────────────┐
  │
  │  Total Verifications:  147
  │  Passed:               121  (82.3%)
  │  Failed:                26  (17.7%)
  │  Avg Duration:         312.4ms  (total: 45.9s)
  │
  │  Failure Breakdown (26 total):
  │    syntax:       11  (42.3%)
  │    imports:       8  (30.8%)
  │    security:      5  (19.2%)
  │    architecture:  2  ( 7.7%)
  │
  │  Most Failed Files (top 10):
  │    internal/user/handler.go                      7 failures
  │    internal/api/router.go                        4 failures
  │    internal/auth/middleware.go                   3 failures
  │
  │  Models Used:
  │    anthropic/claude-sonnet-4-6:   98  (66.7%)
  │    openai/gpt-4o:                 49  (33.3%)
  │
  │  Daily Trend (last 14 days):
  │    2025-01-02  ████████████░░░░░░░░  12/20 (60%)
  │    2025-01-03  ████████████████░░░░  16/20 (80%)
  │    2025-01-04  ████████████████████  10/10 (100%)
  │    2025-01-05  ███████████████░░░░░   9/12 (75%)
  │
  │  Recent Verdicts (last 20):
  │    ✓ ✓ ✗ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✗ ✓ ✓ ✓ ✓ ✓ ✓ ✗ ✓
  │
  └────────────────────────────────────────────────────────────────────────┘

Audit log format

Every run of kode verify or kode loop appends a JSONL entry to logs/kode.log. Each line is a self-contained JSON object:

{
  "timestamp": "2025-01-15T10:32:11.004Z",
  "task_id": "verify",
  "status": "FAIL",
  "files": ["internal/user/handler.go"],
  "failures": {
    "internal/user/handler.go": "syntax: unexpected token '}' at line 42"
  },
  "rounds_used": 1,
  "duration_ms": 284,
  "model": "anthropic/claude-sonnet-4-6"
}

The failures map uses gate names as prefixes (e.g. syntax:, imports:, security:, architecture:), which is how kode stats builds the failure type breakdown.

kode stats reads the log but never modifies it. You can safely run it in CI or in a watch loop without risk of corrupting the audit trail. To reset your statistics, delete or rotate logs/kode.log manually.

Interpreting the results

• Pass rate below 70% — your prompts are likely too broad or the blast radius limit is too tight for the task size. Try using kode plan --packet to give the LLM better context.
• syntax failures dominate — the LLM is producing malformed code. Consider switching to a stronger model or reducing task scope.
• security failures on the same file repeatedly — that file may have a pre-existing vulnerability pattern. Review it manually and consider adding an inline suppression annotation.
• Blast radius failures — your max_blast_radius in kode.json may be too conservative for the task. Increase it or break the task into smaller steps.