Polymath Zero

Polymath Zero

Work from intent
to verified execution.

Polymath Zero starts from real code, then organizes engineering around structured Work: bugs, features, epics, refactors, investigations, and greenfield projects. Cases close only with proof.

  • → GitHub issues, manual intent, or greenfield — all become structured Work
  • → Each session logs hypothesis, diff, and test results
  • → RESOLVED requires verified evidence — always

Desktop app · macOS · Apple Silicon and Intel

1 · WORKOPEN
intent defined
Bug, feature, epic, or greenfield. From GitHub, Jira, or manual — a Work item opens.
2 · SESSIONSIMPLEMENTING
AI works it
Each run logged: hypothesis → diff → tests.
3 · PROOFRESOLVED
Verified evidence
Test logs, traces, operator notes. Gate flips to RESOLVED.
CASE 001auth timeout on /api/loginsource: gh #1284
VERIFYING
SESSIONS
4
ELAPSED
00:47
TESTS
47/47
PROOF
pending
SYSTEMsource: gh #1284 → github-context.md written · Work item ready
AGENTtracing jwt refresh path…
AGENTexpiry check: < → <= · auth/jwt.rs:142
TOOLcargo test auth
SYSTEM✓ 47 / 47 passed · 2.3s
APPROVALattach diff as proof? y
AGENTproof attached → PR #87 ready-check unblocked
SESSIONS4
001hypothesis formedINVESTIGATING
002jwt fix appliedIMPLEMENTING
003refresh storm fixVERIFYING
004regression runVERIFYING
PROOF GATE
RESOLVED blocked until 1 verified proof.
RECALL
/auth timeout
CASE 001 · jwt < vs <= RESOLVED

Vocabulary

Work is the core unit. Sessions execute it. Proof closes it.

WORKOPEN
A bounded unit of engineering intent: a bug, feature, refactor, epic, or greenfield project. Work has a source (GitHub issue, Jira ticket, or manual), a type, and a definition of done.
SESSIONIMPLEMENTING
One run of AI-assisted execution on a Work item. Logs hypothesis, code changes, test results, and operator notes.
PROOFRESOLVED
Verified evidence required before RESOLVED. Test logs, traces, or operator-attached files. No proof = Work stays open.
  • ✓Code never leaves your machine
  • ✓Case memory stored locally — not synced remotely
  • ✓Approval required before any code executes

Work variety

Not every Work item
is a code change.

3 RESOLVED · sampled from /cases
CASE 042bugrefresh token race · duplicate issuance
RESOLVED
authconcurrencypostgres
001INVESTIGATINGnon-atomic check-then-act on rotation
002VERIFYINGatomic CAS · 10k concurrent · 0 dup
OUTCOMEConfirmedCodeBug
load-10k.log · 0 DUPLICATE_ISSUE
PROOF
CASE 044bugschema drift error lacks field detail
RESOLVED
pipelineobservability
001IMPLEMENTINGbool → SchemaDriftError{field,from,to}
002VERIFYINGdebug time · 20m → <30s
OUTCOMEConfirmedCodeBug
unit + integration · verified
PROOF
CASE 038investigationempty timeline on pre-012 cases
RESOLVED
serdedata-model
001INVESTIGATINGStateTransition added in s012 · #[serde(default)]
OUTCOMEINTENDED_BEHAVIOR
no fix required · classification verified
PROOF
CASE 042 · SUMMARY TAB
RESOLVED
OUTCOME
ConfirmedCodeBug
2 sessions2 proofs
MEMORY
problem-definition.mdfinal-classification.md+ New file
PROOF
load-10k.logtest-log
diff-fix-cas-atomic.patchdiff

One full case

Four sessions.
Three days. One verified fix.

A session is one AI-assisted run on a Work item. Each session logs: hypothesis → code changes → test results.
CASE 001
auth/login
OPEN
INVESTIGATING
IMPLEMENTING
VERIFYING
RESOLVED
Apr 21Session 001INVESTIGATINGfirst trace · jwt timing window on refresh
Apr 22Session 002IMPLEMENTINGexpiry check `<` → `<=`
auth/jwt.rs+3−1
42/42 passed
Apr 22Session 003VERIFYINGrefresh storm · short-circuit concurrent refresh
auth/refresh.rs+18−4
47/47 · 200 concurrent logins
Apr 23Session 004RESOLVEDregression pass · proof attached
47/47 passed
PROOF · VERIFIED
OUTCOMEConfirmedCodeBug
SIX WEEKS LATER · THE BUG COMES BACK
WITHOUT ZERO
Re-investigate from scratch.
auth timeout1 result
URL/?q=auth+timeout
case 001 · jwt `<` vs `<=`RESOLVED

GitHub flow

GitHub issue → Work.
Work → verified PR.

gh issue → Work item → sessions → PR → regression
01 · INTAKE
gh issue
issue #1284
repoacme/api
labelsbug · auth
ac3 items
02 · CASE
POST /cases/import
work 001 opened
github-context.mdwritten
proof checklist5 required
stateOPEN
# github-context.md
title: auth timeout on /api/login
repo: acme/api · #1284
labels: bug · auth
ac: 3 items
03 · SESSIONS
work 001 / sessions
4 sessions · proof 5/5
s001investigating
s002implementing
s003verifying
s004verified ✓
04 · PR READY
GET /pr/ready-check
PR #87 · ready
ci checks
reviews2 resolved
blockers0
05 · MERGED
regression-memory/
saved · acme-api-1284.md
issue commentproof posted
regression memoryindexed
recallindexed
· progress comments posted to source issue· proof comment posted to PR on resolve· regression memory indexed for future recall

Comment-triggered Work

Write a comment.
Zero offers to take over.

Type an actionable comment in the editor — fix, refactor, investigate, improve. Zero detects the intent and surfaces a one-click approval offer. Nothing runs until you approve.

.ts.rs.py.sh.js.yaml.html.css
auth/jwt.rs
refresh.rs
138pub fn validate_jwt(token: &str, secret: &[u8]) -> Result<Claims> {
139 let claims = decode::<Claims>(token, secret)
140 .map_err(|_| Error::InvalidToken)?.claims;
141 if now < claims.exp {
142 return Err(Error::TokenExpired);
143 }
144 Ok(claims)
145}
146
147
148
Rust · auth/jwt.rs · Ln 147Zero watching for intent
01Type an actionable comment
Comments starting with fix, refactor, improve, investigate, explain, simplify, and others. Ignored: TODO, FIXME, NOTE, linter directives.
02Zero surfaces an offer
An inline tooltip appears: “Hmm.. let me take over..” with Approve and Decline. No agent starts, no files change.
03You approve — Work begins
Zero creates a Work item, spawns an agent with the comment as instruction, and opens a session. The comment becomes the bounded intent.
TRIGGERS
fixrefactorimproveoptimizeinvestigateexplainsimplifyaddreviewclean upmakefindhelp meplease

Regression memory

When it comes back.
Search before you dig.

Zero indexes every resolved case. When similar Work opens again — a bug, a regression, a recurring edge case — you see root cause, resolution, and proof before starting a new session.

SEARCH · LOCAL INDEX
/auth timeout
1 RESULT
CASE 001 · Apr 21
jwt expiry check — auth timeout on /api/login
RESOLVED
regression-memory/acme-api-1284.mdmd
# auth timeout on /api/login
outcome: ConfirmedCodeBug
resolved: 2026-04-21
## root cause
JWT expiry check used < instead of <=.
## proof
session-004 test log · PR #87 merge

Memory lives locally. Your cases are never sent to a remote index.

How Work runs

One Work. One run. Verified outcome.

PLAN MODE
Agent forms hypothesis and plan. Operator reviews before any execution begins.
WORK MODE
Approved plan executes. One Work item, one agent run, one diff. No task queue.
PERMISSION POLICY
Each tool call requires operator permission. Execution never proceeds without approval.
defined
OPEN
Work defined. Operator review pending.
plan approved
INVESTIGATING
Plan mode: hypothesis formed. Operator approves plan before execution begins.
diff
IMPLEMENTING
Work mode: approved plan executing. Diff produced.
proof
VERIFYING
Evidence collected. Proof gate evaluated.
RESOLVED
Verified proof attached. Work closes.

+ BLOCKED — operator decision: Resume, Skip, Reject, or Mark Not Applicable. Returns to prior state on Resume.

Proof gate
CASE 001 · auth/jwt.rs:142
PUT /cases/001/state
NO PROOF ATTACHED
› PUT { "state": "RESOLVED" }
HTTP 422
{ "error": "no verified proof" }
PROOF VERIFIED · 1/1
› PUT { "state": "RESOLVED", "proof": ["cargo-test-auth-47", "diff-jwt-142"] }
HTTP 200
{ "state": "RESOLVED", "outcome": "ConfirmedCodeBug" }
Outcome ledger
each row proof-gated
GET /cases?state=resolved
OUTCOME
COUNT
SAMPLE
CODE CHANGE
Every row gated by Proof gate above. RESOLVED ⇎ proof attached.

Why proof?

Why “done” needs evidence.
Not a comment.

Without proof, "done" means nothing.
Work marked resolved without evidence can silently regress — or never have been complete in the first place. Six weeks later, you're investigating from scratch.
Proof is the handshake.
When you attach proof, you're telling Zero — and yourself — that the work is verifiably complete. That verification is gated, not optional.
Memory works because proof is enforced.
Zero's recall is useful only if past resolutions are trustworthy. Proof enforcement is what makes the memory credible — for bugs, features, and everything in between.

Work in progress

Active Work.
Verified outcomes.

103 cases · regenerated each build
Work queue
OPEN · 88INVESTIGATING · 13RESOLVED · 2
GET /cases
RUN STATE
WORK
TITLE
SOURCE
INVESTIGATING
0336764B
Order ManagementCash payments are taking longer than expected to be displayed on the order card after payment got registered.
project-reactivate #1945
INVESTIGATING
1CBC76FA
Payment TerminalOn the external Android payment terminal, the card payment is not cancelled when the user cancels it from the Sunmi T2s device. The transaction continues until it times out.
project-reactivate #1944
INVESTIGATING
1D2AC6AD
Order CardKitchen receipts are not being printed via the receipt flow on the order card
internal
INVESTIGATING
39C9D8E5
Payments[Dual Screen] Softpay App Is Not Shown on Customer-Facing Display During Card Transactions
project-reactivate #1928
INVESTIGATING
43E7525F
StagingHome/Order page becomes unresponsive for a few seconds after navigating back post card payment
project-reactivate #1862
INVESTIGATING
4801116F
Print[Refund] Refund receipt is not printed even when it is enabled from the backend.
project-reactivate #1924
INVESTIGATING
4AA67D22
Payments[Receipts] Failed or aborted card payments do not consistently print an automatic failure receipt
project-reactivate #1873
INVESTIGATING
506921F4
help me audit this file
internal
INVESTIGATING
65FF8871
Order ManagementNot All Open Orders Are Displayed
project-reactivate #1929
INVESTIGATING
9F253B7C
KITCHEN PRINTINGAll text on React BT kitchen receipts prints too small - almost all font should be large
project-reactivate #1888
INVESTIGATING
B03995BE
Refund[Order Card] Refund details are not reflected on the Order Card post-refund completion. A manual refresh or application restart is required to view the updated status.
project-reactivate #1923
INVESTIGATING
BF64BF32
End of DayEnd of Day Receipt Print Prompt Is Shown Twice
internal
+ 91 more cases — same memory, same gateSource: ~/zero/zero-memory/cases

Workspace

Cases. Code. Evidence.
All in one workspace.

Zero’s desktop workspace puts case management, AI sessions, and evidence in one view. No tab-switching, no context loss.

Action inbox
INBOX · 3 NOWg+i
BLOCKEDcase 001 · awaiting proof
NEEDS_USER_INPUTcase 022 · approve fix
VERIFYING · NO PROOFcase 009 · 2/47 tests failed
Inline git diff
auth/jwt.rs
− if now < exp {
+ if now <= exp {
Outcome filter
FILTER BY OUTCOMEclear
ConfirmedCodeBugConfirmedConfigBugConfirmedDataBugConfirmedEnvironmentIssueConfirmedOperatorErrorIntendedBehaviorDuplicateUnreproducibleNeedsProductDecisionNeedsUserInputConfirmedHardwareSetupIssue
Proof gate
CASE 001 · STATEVERIFYING
→ RESOLVED0 proofs
Transition blocked until at least 1 verified proof is attached.
→ RESOLVED1 proof ✓
Memory recall
CASE 001 · S004 RESUMErecalling…
← from s001 · s002 · s003
case · auth timeout on /api/login
proof · cargo test auth ✓ 47/47
fix · jwt.rs:142 < → <=
files · jwt.rs, refresh.rs
context loaded · ready to continue
Memory files
zero-memory/cases/001/local
›problem-definition.md
›final-classification.md
›planning.json
›proofs.json
outcome: ConfirmedCodeBug
proof: cargo-test-auth-47.txt
resolved: 2026-04-21

Positioning

How Zero fits your workflow.

Without Zero
Manual issue tracking. No session logs. Work marked "done" without evidence. Re-investigation starts from scratch.
Generic AI chat
Helpful for one-off questions. No case structure. No proof enforcement. No memory across sessions.
With Zero
Structured Work — bugs, features, investigations, epics. Every session logged. Proof required before RESOLVED. Memory for recall across all Work types.

What Zero is not

✗
Not a bug tracker
Zero handles bugs, features, epics, refactors, and greenfield projects. The core abstraction is Work — not issues or tickets.
✗
Not an auto-pilot
Zero requires operator approval at every decision point. Plan mode produces a plan; execution only starts after you approve it.
✗
Not a CI/CD pipeline
Zero does not run in CI. It is a local execution and verification tool. Code never leaves your machine without explicit action.
✗
Not a chat interface
Zero is structured around Work, sessions, and proof. There is no free-form AI chat. Every run is bounded by a plan and a proof gate.

Pricing

Pick by usage shape.

Work items, sessions, machines — not tokens.

STARTER
$40/mo
1 repo · light week
machines1
active cases
≤ 5
sessions / wk
~20
proof requiredenforced · all plans
supportcommunity
MOST POPULAR
PRO
$100/mo
daily driver · 1 dev
machines1
active cases
≤ 20
sessions / wk
~80
proof requiredenforced · all plans
supportdirect email
TEAM
$200/mo
5 machines · shared memory
machines≤ 5
active cases
≤ 100
sessions / wk
~400
proof requiredenforced · all plans
case exportjson + md
supportpriority
PAY-AS-YOU-GO
$300 initial  ·  $50 recharge
burst · no subscription
APPLIES TO ALL PLANSProof gate is enforced on all plans. No case resolves without verified evidence. This is not a premium feature — it’s how Zero works.

Early access is approval-gated. After submitting a request, we review and follow up directly. Access is not instant.

HOW LIMITS WORK

Active cases
Work items in OPEN, INVESTIGATING, IMPLEMENTING, VERIFYING, BLOCKED, or NEEDS_USER_INPUT. RESOLVED and NON_ISSUE don’t count against the limit.
Sessions / week
Each planning, implementing, or verifying session counts as 1. Browsing diffs or editing memory files does not. Unused sessions don’t roll over.
Machines
Each machine running the Zero desktop app counts as 1. You can switch machines within your plan limit.

FAQ

Common questions.

Where does my code go?+

On your machine. Zero does not upload source code.

What OS does Zero run on?+

macOS — Apple Silicon and Intel. Windows and Linux are planned.

Is there a CLI?+

Zero has a desktop UI and a local HTTP API. No separate CLI required.

How is this different from GitHub Issues?+

GitHub Issues track what work exists. Zero tracks how that work was done — sessions, diffs, and verified proof. When the same problem surfaces again, Zero shows the prior investigation.

Can I use Zero without GitHub?+

Yes. Work items can be created manually. GitHub issues are one source of import context, not a requirement.

Do I need the GitHub CLI installed?+

GitHub integration uses a locally installed CLI for repository access. If the CLI is not installed, Zero works fully for manual Work items and local sessions — source imports are skipped until you install it later.

What happens if a session fails?+

The session is logged. You can review what was tried, add context, and start a new session.

Who reviews my access request?+

We review each request manually. Access is intentionally gated.

Is proof optional?+

No. Each session produces evidence — diffs, test logs, operator notes. You review the output and attach evidence as verified proof. Without it, Work stays open.

Early access

Define Work.
Close it with proof.

01
Open Zero
0 cases
workspace ~/acme-api · empty
02
Create or import your first Work item
OPEN
auth timeout on /api/login
source: gh #1284 · or create manually
03
Run a session, attach proof, close verified
RESOLVED
✓ 47 / 47 tests · 1 proof verified
BEFORE YOU SUBMIT
→What you're building (codebase type, language)
→What problem you want Zero to help with
→How many active Work items you expect

AFTER APPROVAL

→You'll receive an email with your access link.
→Set up your account and download Zero.
→Open your first workspace — native OS folder picker.
→Your first session is ready.
REQUEST ACCESS

Early access is approval-gated. After submitting, we review and follow up directly. Access is not instant.

Currently macOS only. Windows and Linux support planned.