Research
Design decisions, experiments, and technical rationale for the 0 engine. The public research index links investigation and disclosure records; those records make target-specific claims, not universal reproduction or production-readiness guarantees. Many early experiments used the XBOW benchmark (104 Docker CTF challenges).
For benchmark scores, methodology, and competitor comparisons, see Benchmarks. For mechanism docs (agent loop, triage, verification), see Architecture.
For practical workflows (variant hunting, deep review, specification checks, fuzzing, kernel evidence, binary analysis, and the distinction between live execution and imported evidence), start with Research Workflows. The pages below document design rationale and experiment history.
Read each page’s status before applying it: a dated run is empirical evidence for that configuration, a blank ablation template contains no results, and a proposal is not a shipped workflow. Benchmark figures here remain dated snapshots. Multi-model research informs explicit configuration and role diversity; it does not establish automatic optimal discovery/verification/fix model routing.
Essays & rationale
Section titled “Essays & rationale”Design decisions and shipped techniques.
Why the agent uses bash over structured tools, with A/B test data on prompt length, reasoning effort, tool routing, concurrent subagents, and multi-checkpoint budgets.
Shipped agent loop features: early-stop retry, exploit templates, loop detection, context compaction, dynamic playbooks, attack-tree search, strategy racing, and progress handoff.
Head-to-head testing of gpt-5.4, Kimi K2.5, Qwen3 Coder, DeepSeek, GLM, and free OpenRouter models. Cost, speed, and flag extraction across XBOW challenges.
False-positive reduction stack, measured effects per benchmark slice, layer ordering rationale, and how the dataset and feature foundation supports the shipped runtime layers.
Why 0 uses TypeScript for orchestration while moving deterministic engines such as FoxGuard into Rust behind stable contracts.
Self-evolving harnesses
Section titled “Self-evolving harnesses”The engineering target is an agent that can author and select alternative implementations, activate them during a task, retain useful learned skills, and recover when an experiment fails. See Improvement Plane for implementation status and Architecture for runtime boundaries.
These sources address complementary mechanisms and are not interchangeable proofs that 0 improves autonomously:
| Source | What informs the design | What it does not establish |
|---|---|---|
| A Programming Paradigm for Spatiotemporal Composability and Cordis | Reversible component effects, reactive dependencies, configuration reconciliation, and hot replacement | A security-quality benchmark, automatic compensation for external effects, or durable campaign recovery |
| Self-Harness, v3 | Same-model weakness mining, diverse targeted code proposals, and held-in/held-out regression-gated selection | Open-ended self-improvement, live hot swapping, multi-day recovery, or security-quality gains in 0 |
| Evo-Harness, v2 | Failure-grounded natural-language skill curation, separate general/topic guidance, and bounded retrieval for a frozen solver | Executable self-rewriting, multi-agent validation, universal solver transfer, or measured gains in 0 |
| DeepSeek Harness architecture | Replaceable agent-loop, tool, model, and session services rather than only fixed tool extension points | Live reload in its shipped headless/SDK profiles or first-class Python plugin hosting |
| Hermes Python plugins | Python-native tools, hooks, commands, bundled skills, and memory/context provider interfaces | A language-neutral live-generation implementation for 0 |
| Voyager’s skill manager | Retaining executable skill code and retrieving reusable programs by description | General-purpose harness replacement or evidence of cybersecurity effectiveness |
| Darwin Gödel Machine | Evaluated agent-code changes and alternative implementations | Guaranteed monotonic improvement or a substitute for independent evaluation |
| Chord’s lifecycle plan | Explicit dependency ordering, stable service handles, and resource ownership | Graph-transactional reload or post-cutover rollback; its plan explicitly excludes both for shape-preserving replacement |
Cordis and Chord are different projects. Cordis’s formal context discipline differs from Chord’s application-neutral service host. Upstream implementation plans and APIs can change.
Evo-Harness complements code evolution; it does not implement it. Its natural-language-only learning loop turns failed or negatively reviewed executions into candidates carrying a lesson, trigger, evidence, and scope hint. A curator chooses ADD, MERGE, REVISE, or SKIP; later tasks receive bounded relevant guidance. General cross-task lessons remain distinct from topic-specific procedures. For 0, this informs curation within the existing skills and revision-aware hunt memory, not another registry or a claim that this curator is already implemented. Retain provenance and scope, invalidate stale codebase knowledge, and evaluate future-task usefulness separately from successful memory writes. The paper reports three-run averages: Opus 4.6 on TerminalBench2 improved from 62.92% to 73.03%; self-generated judgment regressed CL-Bench from 29.54% to 27.96% and SWE-bench Lite from 63.67% to 61.67%. External feedback is not uniformly beneficial, and solver/evolver pairings can regress. Neither these aggregate results nor individual retained skills establish causal gains in 0, executable-code safety, or a free evolution allowance.
For a long-horizon experiment, report the task and harness versions, measured outcomes, model/tool cost, generation transitions, retained capabilities, and recovery behavior. A successful import or one lifecycle smoke is not evidence that a self-evolving agent performed better across an extended task.
Triage ML
Section titled “Triage ML”Learned triage pipeline design and reference material.
Implementation notes: reachability, consensus verify, PoV generation, memories, adversarial debate, and multi-modal agreement with foxguard.
A learned per-finding classifier that picks which subset of triage layers to run, motivated by the finding that no static policy wins on all benchmark slices.
The shipped v0 rule-based router, its four decision rules, the routing-trace dataset shape, and the upgrade path to a learned classifier.
How benchmark runs and verified findings are converted into labeled JSONL for triage-model training.
The current 55 handcrafted features exposed by extractFeatures() (45 original
web/finding features plus 10 kernel-crash features) and their heuristic limits.
Design for an append-only execution journal and an orchestrator that separates what to do next from what has been done.
Experiment logs
Section titled “Experiment logs”Dated, archival records of specific experiments. Kept for transparency and auditability — not necessarily current guidance.
Audit of the agent loop against the “agents need control flow, not more prompts” thesis, and the five deterministic-chokepoint fixes it produced.
Why autonomous-pentest reporting should publish a dollar-per-flag axis alongside the solve percentage, and how 0 computes its number.
Aggregate analysis of 590 HackerOne programs scored on automation policy, scope shape, and Safe Harbor status — where AI pentest agents can actually operate under the May 2026 CoC update.
The 21-profile triage ablation with batch-1 and batch-2 numbers, methodology notes, and links to raw run artifacts.
Root-cause investigation into why XBEN-099 failed on the patched fork and the proposed fix.
Source-level investigation into an earlier 8-challenge XBOW holdout set. Useful for exploit-path reasoning, but not the canonical current unsolved list.