Evaluation Plan
Quantify piex lift over bare Pi, with omp as peer reference—suites, metrics, Docker architecture, and rollout path.
Goal
Quantify how much piex lifts bare Pi, with omp as a peer reference—same suites, same model, comparable metrics.
Using Pi as the baseline, compare pi + piex and omp on the same suites. The goal is to quantify how much piex lifts Pi, with omp as a peer reference for industry-relative level.
Goals
Core questions: How much does piex help Pi? How do metrics compare to omp?
| Role | Agent | Notes |
|---|---|---|
| Baseline | pi (bare) | Stock Pi, no extensions: the starting point |
| Subject | pi + piex | All implemented piex packages: measure lift |
| Reference | omp | oh-my-pi, source of many piex capabilities: peer level |
Together they answer:
- How large is piex’s lift over bare Pi?
- How far is pi + piex from omp?
Comparison matrix
Same suite, same model for the three self-run agents. Competitor numbers are taken from public leaderboards—not re-run here.
Self-run agents
| Role | Agent | Config |
|---|---|---|
| Baseline | pi (bare) | Stock Pi, no extensions |
| Subject | pi + piex | Pi + all implemented piex packages |
| Reference | omp | oh-my-pi, full built-ins |
Public competitors (cited)
SWE-bench Leaderboard, official blogs, papers—Claude Code / Aider / OpenHands / Devin, etc.
PieX evaluation scope
Each run loads all implemented piex packages; re-run after new packages land.
Implemented (in scope)
| Package | Capability | Eval link |
|---|---|---|
| hashline | overrides edit (hashline syntax) | SWE-bench (edit accuracy, tokens), Can It Edit |
| dap | debug (14 adapters) | DebugBench, SWE-bench (debug path) |
| lsp | lsp (~50 default servers) | RepoBench, SWE-bench (code understanding) |
| plan | /plan, /todos | SWE-bench (multi-step planning) |
| review | /review, review tool | CodeReviewer / c-CRAB |
Planned (reserved)
| Package | Status | Eval link |
|---|---|---|
| todo | 📋 P0 | SWE-bench (task management) |
| conflict | 📋 P0 | custom merge-conflict suite |
| ast-grep / ast-edit | 📋 P1 | SWE-bench (search/edit precision) |
| web-search | 📋 P1 | external-knowledge tasks |
| eval | 📋 P1 | data-analysis tasks |
| memory | 📋 P1 | cross-session retention |
| gh | 📋 P1 | PR/Issue operations |
| browser | 📋 P2 | web interaction |
Suites
Tier 1 — core
| Suite | Scale | What it tests | piex link |
|---|---|---|---|
| SWE-bench Verified | 500 tasks, 12 Python repos | repo-level bugfix end-to-end | edit, search, debug, plan—almost all piex |
| Aider Polyglot | 225 tasks, multi-lang | NL → code edit | hashline |
| Can It Edit | multi-lang edit instructions | fine-grained edits | hashline / ast-edit |
Tier 2 — specialized
| Suite | Scale | piex link |
|---|---|---|
| DebugBench | 4,253 bugs | dap: locate & fix |
| RepoBench | cross-file completion | lsp + ast-grep |
| CodeReviewer / c-CRAB | PR review | review quality |
Tier 3 — later
| Suite | piex link |
|---|---|
| SWE-bench Multimodal | browser (image issues) |
Metrics
Core (comparable across three agents)
| Metric | Definition | Focus |
|---|---|---|
| resolve_rate | pass / total | gap vs omp |
| avg_tokens | mean tokens per task | efficiency |
| avg_time | mean wall time | speed |
| est_cost | mean API cost per task | cost |
Attribution (Pi family only—credit individual packages)
| Metric | Definition | Package |
|---|---|---|
| edit_accuracy | fraction of edit calls with valid hashline syntax | hashline |
| search_precision | fraction of grep/glob/lsp hits that are relevant | lsp |
| first_try_rate | fraction of first edits that are correct | hashline |
| debug_success | fraction of dap uses that locate the bug | dap |
| plan_follow_rate | fraction of runs that follow the plan | plan |
| review_quality | fraction of reviews that surface real issues | review |
Docker architecture
Each task runs in one Docker environment with baseline (pi bare), subject (pi + piex), and reference (omp), judged by the standard harness.
┌────────────────────────────────────────────────────────────┐
│ Eval Orchestrator │
│ eval/runner.ts │
│ │
│ Task Loader ──→ Agent Runner ──→ Sandbox ──→ Judge │
│ (JSONL) (pi/omp CLI) (Docker) (SWE-bench) │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Metrics Collector │ │
│ │ resolve_rate │ tokens │ wall time │ API cost │ │
│ └──────────────────────────────────────────────────────┘ │
│ │
│ ┌──────────────────────────────────────────────────────┐ │
│ │ Report Generator │ │
│ │ baseline → subject → reference + public leaderboard │ │
│ └──────────────────────────────────────────────────────┘ │
└────────────────────────────────────────────────────────────┘Single-task flow
1. Task Loader: read { repo_url, base_commit, issue_text, test_patch }
2. Sandbox: docker run swebench-image-{repo}
→ container already at base_commit with deps installed
3. Agent Runner:
docker exec pi pi --model ${MODEL} \
-e /piex/extensions/hashline/src/hashline.ts \
-e /piex/extensions/dap/src/dap.ts \
-e /piex/extensions/lsp/src/lsp.ts \
-e /piex/extensions/plan/src/plan.ts \
-e /piex/extensions/review/src/review.ts \
-p "${ISSUE_TEXT}" > /workspace/result.json
4. Collect: result.json → patch + tool_calls + token_usage
5. Judge: apply patch → run test_patch → pass/fail
6. Metrics: persist to SQLite / JSONLImages
| Image | Notes |
|---|---|
pi.Dockerfile | Pi base (Node.js)—used for pi bare and pi+piex |
omp.Dockerfile | omp (Bun) |
swebench.Dockerfile | SWE-bench repo runtime |
pi bare and pi+piex share one image; -e controls which extensions load.
Directory layout
piex/eval/
├── README.md
├── package.json
├── tsconfig.json
│
├── src/
│ ├── runner.ts
│ ├── orchestrator.ts
│ ├── sandbox.ts
│ ├── agents/
│ │ ├── pi.ts
│ │ └── omp.ts
│ ├── benchmarks/
│ │ ├── swebench.ts
│ │ ├── aider-polyglot.ts
│ │ ├── can-it-edit.ts
│ │ ├── debugbench.ts
│ │ └── repobench.ts
│ ├── metrics.ts
│ └── report.ts
│
├── docker/
│ ├── pi.Dockerfile
│ ├── omp.Dockerfile
│ └── swebench.Dockerfile
│
├── results/ # gitignored
│ └── 2026-07-14/
│ ├── swebench-pi-bare.json
│ ├── swebench-pi-piex.json
│ ├── swebench-omp.json
│ └── report.md
│
└── fixtures/
└── merge-conflicts/Report format
Each run produces a Markdown report: piex lift over Pi first, then omp as reference:
## SWE-bench Verified — piex report (2026-07-14)
### Results
| Role | Agent | Model | Resolve Rate | Avg Tokens | Avg Time | Est. Cost |
|------|-------|-------|-------------|------------|----------|-----------|
| Baseline | pi (bare) | deepseek-v3 | 12.4% | 85K | 3.2min | $0.18 |
| **Subject** | **pi + piex** | deepseek-v3 | **18.8%** | 62K | 2.8min | $0.14 |
| Reference | omp | deepseek-v3 | 19.2% | 60K | 2.6min | $0.13 |
### pi + piex analysis
| Metric | pi bare | pi + piex | omp | vs baseline | vs omp |
|--------|---------|-----------|-----|-------------|--------|
| resolve_rate | 12.4% | 18.8% | 19.2% | **+51.6%** | **-2.1%** |
| avg_tokens | 85K | 62K | 60K | **-27.1%** | **+3.3%** |
| edit_accuracy | 67% | 91% | 92% | **+35.8%** | **-1.1%** |
| avg_tool_calls | 42 | 28 | 26 | **-33.3%** | **+7.7%** |
### Public leaderboard (same suite)
| Agent | Resolve Rate | Source |
|-------|-------------|--------|
| Claude 4 Opus + SWE-agent | 42.6% | anthropic.com/blog |
| Devin | 35.8% | swebench.com |
| GPT-5 + OpenHands | 38.2% | openhands.dev |
### Takeaways
- piex lift over Pi: resolve rate **+51.6%**, tokens **-27.1%**
- vs omp: gap **< 5%**, core edit capability in the same band
- Pi Extension API can carry omp-level agent capability with a lighter architectureImplementation path
Phase 1 — Docker infra + first suite (~1 week)
- [ ]
docker/pi.Dockerfile - [ ]
docker/omp.Dockerfile - [ ]
docker/swebench.Dockerfile - [ ]
src/sandbox.ts - [ ]
src/agents/pi.ts(bare + piex) - [ ]
src/agents/omp.ts - [ ]
src/benchmarks/aider-polyglot.ts— first end-to-end suite
Phase 2 — SWE-bench (~1 week)
- [ ]
src/benchmarks/swebench.ts— dataset + official harness - [ ] first pi vs pi+piex vs omp report
Phase 3 — specialized (as needed)
- [ ]
can-it-edit.ts→ hashline - [ ]
debugbench.ts→ DAP - [ ]
repobench.ts→ LSP - [ ]
src/benchmarks/code-reviewer.ts→ review
Risks & mitigations
| Risk | Mitigation |
|---|---|
| SWE-bench contamination | focus on relative lift, not absolute; LiveCodeBench later |
| ARM64 / x86 emulation cost | prefer SWE-bench Lite (300); Modal cloud if needed |
| Pi non-interactive limits | validate -p; PTY if required |
| Eval cost | Lite first, full Verified on demand |
Source Markdown: docs/evaluation.md