AntOmniEvo

AntOmniEvo is a Python framework that treats optimization as file editing. You supply five things — a System that runs the thing under optimization, an Evaluator whose 0–1 scoring criteria are the objective, train and validation instances, a schema for the files that may change, and the starting files — then a coding agent reads the failure trajectories, rewrites those files as a new candidate, and the framework decides whether it survives. The genome is a real directory: a mutation can be a Markdown rule, a node script or a retrieval DAG’s pipeline.json. Each iteration rolls a parent and its child out on the same batch, keeps the child only if the summed improvement clears a threshold or is perfect, re-scores it on the validation set, then prunes the pool by Pareto dominance with a top-N fallback. A candidate that misses is not discarded: a reflection chain refines it for a bounded number of rounds. The run is written to a resumable workspace, and a React and Flask visualizer renders it. No release was ever tagged: version 0.1.1 of the two packages goes to an internal index.

Who built itAnt Research is an organisation account rather than a person: 45 public repositories, 368 followers, opened on 2022-12-17, with antresearch.com on its profile. Every commit in this repository comes from one member account, jacklv111 — opened on 2022-09-20, 13 public repositories and 5 followers — which is the author name on 9 of the 21 commits, the linked account on all of them, and the only entry in the contributor list. The paper the README cites lists six authors, led by Yubin Lyu; the repository’s internal release pipeline names two approvers, lyuyubin.lyb and hanpu.mwx. Which account belongs to which name is not stated in the material.

1. 01

   Fifteen days, 21 commits, nine pull requests and no releases

   The repository was created on 2026-09-15, and its first commit, init, landed two hours and eighteen minutes later; the newest is the merge of pull request 9 on 2026-09-30. That is 21 commits in fifteen days, all of them in September, and one account stands behind every one of them: jacklv111 is the linked account on all 21 and the author name on 9, the other 12 carrying a second author name written in Chinese characters and an address at 163.com. Seven commits carry a Co-authored-by: Claude trailer. Nine pull requests were opened in the same window and all nine were closed by the same account with no comments at all — their bodies are the author’s own change notes rather than conversations, which is where most of what follows comes from. No release and no tag was ever created; the version lives only as 0.1.1 in two pyproject.toml files, and what publishes them is an internal pipeline, .aci/python/.aci.yml, whose README describes a manual “Verify & Confirm” gate, a required PIP_INDEX_URL so the isolated build cannot reach the public index, and two named approvers. Around it sit 866 stars, 86 forks, 35 watchers and 0 open issues in a repository of 45,613 KB.

2. 02

   One slot, and what has to be true before a child is kept

   The framework calls an iteration a slot, and the design document writes out every step of it. The optimizer derives a batch from the parent’s own (epoch, dataset_index) cursor — tail-aligned, wrapping to the next epoch at the end, and advanced even when a rollout fails, so the data order is a snapshot rather than a reaction. Parent and mutated child are then rolled out on the same batch, and the comparison is a plain sum: improvement equals the sum of the child’s scores minus the sum of the parent’s. Two things clear the bar — an improvement at or above min_improvement_per_batch, or a perfect score. A child that clears it is re-scored on the validation set, gets a summary.json and flips back to pending; one that misses goes to the reflection chain if reflection is enabled, and is retired if it is not. After every slot the parent advances its cursor, eliminate runs, and a line goes to iteration_records.jsonl. The quickstart expects batch_size=3, max_iterations=1000, num_proposals=1, max_reflection_iterations=2, min_improvement_per_batch=2.0 and max_candidate_num=3. Slots run concurrently inside one process, and any budget cap stops new slots opening while running ones drain — the features document counts four hard caps, the design document five, the extra one being max_system_runs, which also counts the validation runs the proposer may not read.

3. 03

   A rejected candidate is kept and refined, not discarded

   When a batch misses its threshold the framework does not stop at a single natural-language reflection. A mara chain starts: the reflection prompt is pre-loaded with the whole chain context — the chain id path, a per-instance score table with delta columns, the attributed changelog, every earlier link’s analysis for that instance, and the chain links’ run files — and the analysis agent is then made to run a five-method diagnosis, fill in an A–I diagnosis table, prefer REMOVE and REPLACE over adding, name in artifact_issue which link of the chain it holds responsible, and hunt for “lost wins”. Up to max_reflection_iterations rounds run this way; the best chain member that beats the original parent is validated and kept and the rest are retired. Phase 2, the mutation step, is mechanically unchanged on the reflection path, which is where the design puts the whole of the chain’s learning: in the analysis JSON, not in new machinery. The features document is explicit about what is borrowed and what is not — Pareto selection is adopted from GEPA, and the deltas claimed here are concurrency and the mara chain — and the paper the README cites rests on the observation that a discarded candidate often holds information later proposals need, so throwing it away only makes the next proposal visit the same failure again.

4. 04

   Where “optimizes anything” actually stops

   The description promises a framework that optimizes anything, and the boundary is written down: the thing under optimization must be expressible as a directory of tunable artifacts, and its evaluation must be repeatable and reasonably cheap. Three shapes are claimed — an AI agent’s skill, harness or memory directory; a workflow of config plus node code; and a single-file algorithm plus its description — and it says twice that the target need not contain a model. The proposer, unlike the target, must be an LLM coding agent. The exclusions are just as plain: no tunable artifact at all (a few scalar parameters, best handled by black-box tuning), evaluation that is not repeatable or is extremely expensive, and outputs under strict compliance, where it warns that the proposer edits files in a sandbox and the reader must audit the sandbox permissions. Two more limits sit in the code rather than the pitch: the framework does not manage the runtime or scoring harness of the target, and distributed evolution is out of scope — a cloud store is a “local plus transparent sync” subclass you write, and the document says this is not several workers sharing one store across hosts. The example entry points confirm a third limit by not running: each depends on an external codebase, and one still carries an absolute path into the author’s home directory as its workspace.

5. 05

   Ten successes and an empty results directory

   The most useful pull request in the repository is a bug fix, and its body states the root cause, the wrong behaviour and the fix. Under rate limiting at the model gateway the model returns empty assistant messages; the agent CLI retries internally and then exits 0, so nothing ever reaches trajectory.errors. Phase 1 counted every such session as a success — the log said “10 succeeded” — while the analysis result directory stayed empty, and Phase 2 then proposed on “(no analysis results available)” and edited nothing. Two of the three changes in that pull request are spelled out in the material: a find_degenerate_ending check that treats two or more trailing empty model spans, or zero tool calls with zero text, as a failure and raises PiEmptyResponseError into the retry path the 429s already used, with the same backoff and the existing retry hook; and a Phase 1 assertion, after a clean exit, that the analysis result file really was written or rewritten since the run started, so a silent session counts as a failed instance rather than a successful one. The third change, scoped to Phase 2, is cut off in the excerpt available here. What makes it worth recording is the shape of the failure: a counter, a metric and a log line all agreed that work had been done, and the only thing that disagreed was the empty directory.

6. 06

   What is recorded about a run, and what is not

   Nothing in the repository publishes a result: no benchmark table appears in the README or the eight English documents beside it. The only evidence of real runs is visual — the visualizer’s documentation embeds six screenshots: a gym where candidates are drawn as lobsters in score-tiered rooms, a lineage tree, a best-score curve, a coverage grid of the questions no candidate solved, and a file viewer. What it publishes instead is a method for checking a run yourself: compare baseline_avg_score with best_avg_score in logs/statistics.json; read iteration_records.jsonl for each slot’s accepted flag, its old and new batch score sums and its reflection_depth, a value above zero meaning reflection rescued it; then walk parent_id to the root and read changelog.jsonl, the append-only lineage the workspace document calls the history of why the artifacts look as they do. The numbers it does have are in the paper the README began linking on 2026-09-30: its abstract claims up to 20.5% relative improvement over GEPA, ACE and SkillOpt-Lite on AppWorld with 65.5% fewer rollouts to reach the target score, pass-rate gains of 20.2 and 22.5 points over AHE and Meta-Harness on TerminalBench 2.1, and MuSiQue nDCG@10 and Recall@10 gains of 0.104 and 0.131 over a hand-written retrieval pipeline. Those are claims in an abstract by the same team; nothing in the material reproduces them.