How I Beat Anthropic's 1,487-Cycle Benchmark with Claude and Codex

Anthropic published a recruiting invitation at the end of its article on designing AI-resistant technical evaluations: take the original performance-engineering challenge and beat Claude Opus 4.5's launch result of 1,487 cycles.

Heads up!

To proceed

Even if I beat their task, I wasn't expecting them to contact me, but I felt confident after recently doing a similar task for an AI startup.

I brought the lessons from my prior work designing and hardening agent evaluations: freezing the test boundary, reproducing every claimed result, inspecting failures, and never treating a fast number as valid until the reference agrees.

Before handing the kernel to either agent, I did the initial research myself. I read the repository, simulator contract, and submission tests; mapped the benchmark ladder; and defined the correctness and evidence requirements. Then I let Claude and Codex take over the implementation and optimization work.

The final result was 1,469 cycles on the frozen submission simulator, a 100.57x speedup over the 147,734-cycle baseline.

So I submitted the result to Anthropic's performance recruiting team.

This post explains how Claude, Codex, and I divided the work, and what I learned.

The challenge

Without giving away the answer: the task runs a parallel tree-traversal kernel on a simulated accelerator. The machine exposes the kinds of constraints that make real performance work interesting: SIMD operations, VLIW instruction bundles, multiple execution engines, limited scratch memory, and explicit scheduling decisions.

The objective is simple to state: produce the correct output in as few simulated clock cycles as possible.

The public benchmark ladder gives that number context:

Correctness came before the score

Optimization challenges become meaningless if the optimization changes the problem.

I kept those constraints explicit throughout the work:

git diff origin/main tests/
python3 tests/submission_tests.py

The first command remained empty. The second repeatedly returned 1,469 cycles across the randomized correctness runs. The final kernel passed every published threshold except the later 1,363-cycle improved-harness result.

I also checked additional parameter combinations against the bit-exact reference implementation:

Every configuration stayed below the simulator's scratch-memory limit.

Claude built the foundation

I started the optimization work in a Claude 4.8 Max session.

Claude moved the kernel from the slow scalar baseline to a general vectorized implementation that ran in 1,876 cycles. That was already substantial: bit-exact output, bounded scratch usage, and a reusable scheduler rather than a one-off that only worked for the graded configuration.

At 1,876, the kernel had cleared the 2,164-cycle benchmark but none of the others.

Beyond the score, Claude left behind a measured starting point, a correct runnable artifact, and a much narrower performance problem for the next agent to investigate.

Codex closed the final gap

I moved Claude's kernel into a fresh checkout and gave Codex Sol medium the frozen tests, the measured 1,876-cycle result, and one non-negotiable rule: do not modify tests/.

Codex first reproduced the exact score. That mattered. Without a reproduced baseline, every later number would have been questionable.

The improvement process then became an empirical loop:

1. Measure the current schedule.
2. Identify where issue slots were being lost.
3. Make one bounded change.
4. Run the reference comparison.
5. Keep only improvements that remained correct.

Some reasonable changes made the kernel slower. Others improved the result. I kept a change only when it remained bit-exact against the frozen reference and reduced the measured cycle count.

I am keeping the implementation details private because those details are the solution itself.

The last few cycles were the hardest. By that point, progress came from small, measured experiments and repeated validation. Several clever ideas made the result worse.

Contributions

The handoff between agents was part of the engineering. Claude's sandbox and Codex's workspace were separate, so chat history couldn't carry the work. What transferred was a runnable artifact with a known score, correctness evidence, and a precise statement of what remained.

That reduced rediscovery and let the second agent work on the actual bottleneck.

How long the work took

flowchart TD
    A["<b>My research + constraints</b><br/>direction · verified facts · technique ladder"] --> B["<b>Claude</b><br/>1,876 cycles · ~30–40 active min"]
    B --> C["<b>Codex</b><br/>1,469 cycles · +12m 09s"]
    C --> D["<b>Validation + package</b><br/>+11m 01s · done 17:14:25"]
    D --> E["<b>Total to result</b><br/>~42–52 min · ~53–63 min submitted"]
    E --> F["<b>Timing methods differ</b><br/>Claude estimate · Codex timestamps"]
    F --> G["<b>Cycle scores directly comparable</b><br/>1,469 vs Anthropic's 1,487-cycle bar"]

What I learned

Reproduction is part of optimization

The second agent's first job was to reproduce 1,876, not to improve on it. A performance number without a reproducible environment is only a claim.

The test harness is a boundary, not an obstacle

The frozen simulator and unchanged-test check prevented accidental success. They turned correctness into a hard constraint rather than something to inspect after the score looked good.

Failed experiments were useful

Several scheduler ideas regressed performance. Recording those results narrowed the search.

That is valuable information when the alternative is repeating it later.

Human direction still changed the outcome

Claude and Codex optimized the kernel; I decided what counted as valid evidence, which results were safe to keep, and when the submission was ready.

Final result

The submitted kernel runs in 1,469 cycles, 18 cycles under Claude Opus 4.5's published launch result, with tests/ unchanged and correct output across every configuration I checked.