Skip to main content

Documentation Index

Fetch the complete documentation index at: https://kode-f177b001.mintlify.app/llms.txt

Use this file to discover all available pages before exploring further.

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.