cost-speed-meter

Files (3)

• SKILL.md
• meter-hook.sh
• meter.sh

SKILL.md (first lines)

# Cost & Speed Meter

Track execution time. Suggest faster paths. Prove optimizations worked.

Measure only commands the user asks to compare. Across sessions, the optional metrics file can show trends without adding noise or overhead to normal work.

## When to Use

- User asks to measure tests, builds, or lint commands
- User asks: "is this slow?", "how long did that take?", "what's the slowest operation?"
- User asks: "what's a faster way to do this?", "what's the quick feedback loop?"
- User is optimizing something — measure before, optimize, measure after to prove it worked
- Working across multiple repos — compare execution costs

## What It Tracks

| Operation | Tracked? | Example |
|-----------|----------|---------|
| `pytest`, `jest`, `cargo test`, `go test` | ✓ Tests | `45s` |
| `npm run build`, `cargo build`, `pip install` | ✓ Builds | `8s` |
| `ruff check .`, `eslint .`, `cargo clippy` | ✓ Lint | `2s` |
| `git push`, `git pull` | ✓ VCS | `3s` |
| Custom commands | ✓ Named in `.claude/metrics.json` | `custom:deploy` |

## Output

### Command Reports

On demand:

```
Use `skills/cost-speed-meter/meter.sh show` for current measurements or
`skills/cost-speed-meter/meter.sh report` for a weekly summary.
```

## Fast-Path Recommendations

Auto-detect patterns:

```
Full suite: pytest (45s)
Unit only: pytest -m 'not integration' (15s)

→ Recommendation: For quick feedback, use unit tests (3x faster)
  Use full suite before pushing.
```

Per-language:
- **Python:** `pytest -m 'not slow'`, `pytest tests/unit/`
- **Node:** `npm run test:unit`, `vitest --run` (vs jest)
- **Rust:** `cargo test --lib` (vs full + integration)
- **Go:** `go test ./...` (vs `go test ./... -v` with benchmarks)

## Metrics File (`.claude/metrics.json`, gitignored)

```json
{
  "repo": "code-to-docs",
  "timestamp": "2026-08-20T14:30:00Z",
  "operations": [
    {
      "name": "tests",
      "category": "test",
      "last_run_seconds": 45,
      "last_run_time": "2026-08-20T14:30:00Z",
      "run_count_7d": 12,
      "avg_7d": 43,
      "trend_7d": "+2s",
      "trend_pct": "+4.7%"
    },
    {
      "name": "unit_tests",
      "category": "test",
      "last_run_seconds": 15,
      "run_count_7d": 4,
      "avg_7d": 14
    },
    {
      "name": "build",
      "category": "build",
      "last_run_seconds": 8,
      "run_count_7d": 8,
      "avg_7d": 8.2,
      "trend_7d": "-0.5s"
    }
  ],
  "slowest_op": {
    "name": "tests",
    "seconds": 45,
    "reason": "integration tests (50 of 1000 tests)"
  },
  "recommendations": [
    "For quick feedback, run unit tests (15s vs 45s) — 3x faster",
    "Test suite grew 4.7% last week; check for new integration tests"
  ]
}
```

## How It Saves Tokens

**Feedback loops:** 
- Run fast path (unit tests 15s) instead of full suite (45s)
- 10 iterations per day × 30s saved = 5 min/day = fewer re-runs
- Fewer retries = fewer tokens

**Prevents wasted optimization:**
- Data-driven: you know tests are slow, not build (actual problem)
- Don't optimize wrong thing (wastes time, tokens)

**Team alignment:**
- Everyone sees same metrics
- "Let's optimize integration tests" (shared understanding)
- No "why is my machine slow?" guessing

## Integration with RTK

RTK compresses output noise.  
Meter tracks execution time.

From Benkapner/claude-code-basecamp, MIT.

More from Benkapner/claude-code-basecamp