One Person and Four AI Agents vs. the Order Book: Three Weeks on Wunder Fund Alpha Connectome
I joined the Wunder Fund Alpha Connectome competition on October 24, with three weeks left to go. The task: given a sequence of order book states and trades for two instruments, predict two hidden indicators of future price movement. Solutions are evaluated on CPU, and they have to run fast.
I didn’t write the model. I built a lab where four AI agents searched for it, while I set the direction and made the decisions that can’t be delegated.
As of November 5, we’re at 0.66012 on the public leaderboard, in 244th place out of 5,705. The first submission scored 0.63261 and landed in 985th place.
The lab
- An MCP server in Code Mode. The agent doesn’t call dozens of tools. It writes short code against an SDK, and that code runs on the server, right next to the data. Both Claude Code and Codex connect to the same server.
- A wiki in git. Hypotheses, pre-registrations, findings, the journal and the submissions table all live in Markdown. Each agent commits under its own name. In two weeks that added up to more than a thousand commits and two hundred experiments.
- A queue with gates. A worker with two slots. The final pre-submission check runs alone on the machine: it measures speed and verifies parity and packaging.
Roles
- The orchestrator hands out directions, makes technical decisions and records them in ADRs, and also uploads submissions to the site.
- Two executors each own a direction: they formulate a hypothesis, run the experiment and read the result.
- The reviewer checks pre-registrations and hunts for validation leaks. Before every submission it verifies the file hashes and issues a verdict: “submit” or “don’t.”
What was left to me as the owner were the decisions that change the risk: whether to fine-tune on validation, how often to submit, what to pick as the final. I delegated everything else in writing. ADR-0006 already lists 29 such decisions, each with a date and a reason.
The rules that turned a swarm into research
- Pre-registration. Before a run, the expected range and the criterion are written down. A result that is “inside the range but below 2 SE” is a zero, not an “almost worked.”
- The two-seed rule for effects smaller than +0.002.
- Submitting without my “yes,” but only by the rules. The solution has to beat the last submission by more than 2 paired SEs. The reviewer says “submit.” No more than five submissions per day. Submissions go only through a script that refuses to upload a file if its hash is already on the site.
- A speed threshold derived from data. Seven submissions fell on a straight line of “local speed → time on the site.” That gave a threshold of 33 µs per row for ONNX Runtime. For numba, the threshold was first set at 44 µs, then lowered to 41 after a real measurement.
What worked
- Distillation from an ensemble teacher into a small GRU, followed by a long recipe and a cooldown: from 0.64363 to 0.65258 on the site.
- Ensembles of two, three and five models. To fit the five-model ensemble within the time limit, inference was rewritten as a numba kernel, with parity checked to 1e-4.
- Fine-tuning on validation with protection against overfitting: 5-fold cross-fit, checks at the level of the whole ensemble, no iterating against the site. On the site this gave twice what the local estimate promised.
What didn’t work
There were more dead ends than wins, and they are exactly what shows the process is honest.
- Adaptive per-sequence normalization: −0.00145 and −0.00047, and slower on top of that.
- Reweighting train toward validation: +0.00013 ± 0.00049, and fold 0 got worse.
- A sixth model in the ensemble: 46.45 µs, doesn’t fit within the time limit.
- Re-distillation from the five-model ensemble: all three students gave zero, the best at 1.2 SE.
Where the process broke
- The agents stalled. They would take a step and wait. The longest idle stretch was about 20 hours, while the machine sat free the whole time. The fix turned out to be mundane: a watchdog checks the queue once a minute and wakes the agents itself.
- A double submission. The same file went to the site twice. After that came
safe_submit.sh: it compares the hash against already-uploaded ones and uploads nothing on any error. - The reviewer caught itself. It ran its own computations during an exclusive speed measurement, wrote that down in the journal and introduced a rule: no jobs of its own during such a window.
- A guardrail kicked in before the rules did. A submission that the project protocol allowed was stopped by Claude Code’s own permission classifier. That’s fine: an external action with consequences is better confirmed by a human one extra time.