Inspiration
Wikipedia racing looks deceptively simple: start on one article and reach a target article using only links inside Wikipedia pages.
But recent research shows that it is actually a surprisingly difficult test of AI reasoning. The LLM-WikiRace benchmark evaluates whether language models can navigate Wikipedia step by step using their world knowledge and planning ability. On easy games, frontier models perform very well — but performance collapses as paths get longer. On the hardest split, the best-performing model, Gemini 3.1, succeeds in only 29% of games.
The paper argues that the difficulty is not just knowing facts. WikiRace forces a model to turn that knowledge into a sequence of decisions, plan several steps ahead, and recover when its original strategy fails. In fact, the authors found that even strong models frequently get trapped in loops and struggle to replan.
That gave us an idea:
If WikiRace is still difficult for frontier AI models, how would one actually perform against a human in real time?
We built WikiRacer to find out.
Instead of treating WikiRace purely as a benchmark, we turned it into a live head-to-head game. A human and an AI start on the same Wikipedia page, share the same target, and race through hyperlinks under the same basic constraint: no search and no jumping directly to the destination.
The result is part game, part AI demo, and part visualization of long-horizon reasoning — you can literally watch the model decide where to go, commit to a route, recover from bad choices, or get stuck.
What it does
WikiRacer lets you race an AI across Wikipedia in real time.
At the start of a race, both the human and the AI are placed on the same article. After a countdown, the human clicks links in the left side of the interface while the AI controls its own live browser on the right.
The AI cannot search Wikipedia, type in URLs, or teleport directly to another page. At every step, we extract the legal links from the current article and give those choices to Claude. Claude selects exactly one link and explains why it thinks that link is the best route toward the target.
The interface shows the AI's browser and reasoning as the race happens, so instead of simply seeing an answer from a model, you can watch its navigation strategy unfold step by step.
The first racer to reach the target article wins, and at the end we show both complete paths.
How we built it
We built WikiRacer as a React + TypeScript web application with a Python backend.
The frontend handles the race interface, countdown, human Wikipedia navigation, live agent updates, and final results. The backend manages the AI race loop and communicates with the frontend using Server-Sent Events so that every AI action appears immediately in the UI.
For each AI turn, we:
- Load the current Wikipedia page.
- Extract the links that are legal moves under the game's rules.
- Remove already visited pages where possible to prevent the agent from getting stuck in loops.
- Send the remaining candidates, current article, target article, and race history to Claude.
- Force Claude to select exactly one candidate using structured tool calling.
- Navigate a real browser to that article and repeat until it reaches the target or runs out of hops.
We use Steel to give the AI a real cloud-hosted Chrome browser. This is what makes it possible to display the agent's browser alongside the human player's view instead of running the entire race invisibly in the backend.
We also use Wikipedia's MediaWiki API to validate and canonicalize article titles so redirects do not incorrectly affect race results.
Challenges we ran into
One of the hardest parts was making the race both fair and reliable.
The AI had to operate on exactly the links available on the page rather than using its knowledge to jump directly to an answer. We therefore built our own link extraction and candidate-selection pipeline and use structured Claude tool calls to constrain every move.
Preventing loops was another problem. An AI can easily alternate between two related pages forever, so we explicitly track previously visited articles and filter them from future choices whenever possible.
We also had to synchronize two very different racers. The human interacts directly with the web app, while the AI operates through a remote browser and an LLM API. We created an event-driven race protocol so both sides start from the same gun and the frontend can continuously stream the AI's clicks, reasoning, timestamps, and arrival state.
Finally, hackathon demos need to keep working even when external services do not. We added fallbacks for API failures, Wikipedia rate limits, browser problems, and even a complete mock-agent mode so the application can still demonstrate the full race flow without API keys.
What we learned
One of the most interesting things we learned was that WikiRace is not simply a test of who knows more facts.
In practice, the AI wins most races against human players, which makes sense: Claude has extremely broad world knowledge and can often identify useful conceptual connections very quickly. But the races are usually much closer than we expected.
Humans have a different advantage. We can recognize useful Wikipedia "hub" pages, take intuitive shortcuts, and change strategies quickly when a route feels unproductive. The AI is often very strong at choosing individually sensible links, but WikiRace still requires those decisions to add up to a good long-term route.
That helped us understand why WikiRace is an interesting benchmark for LLM agents. The LLM-WikiRace paper shows that frontier models perform extremely well on easier tasks but still struggle as navigation paths become longer and require more replanning. Our own races made that distinction much more tangible: an AI can look impressive almost every step of the way while still taking a route that gives a human a chance to catch up.
We also learned that building an AI agent involves much more than simply connecting an LLM to a browser. We had to define which actions were legal, extract and validate possible links, maintain race state, prevent loops, handle failures, and connect Claude's decisions to a live browser session through Steel.
The end result was something we did not entirely expect: not a demonstration that humans are better than AI at WikiRace, but a surprisingly close competition between two very different styles of navigation.
What's next for WikiRacer
We would like to expand WikiRacer into a broader benchmark and game for human-versus-agent navigation.
Some ideas include multiplayer races, different AI models competing against each other, leaderboards, procedurally generated race challenges, replay visualization, and statistics comparing human and AI navigation strategies.
We would also like to explore whether different models develop recognizable Wikipedia "routing strategies" — for example, whether they consistently travel through broad hub articles such as countries, historical periods, scientific fields, or major organizations before narrowing in on the target.
Built With
- python
- react
- steel
- tailwind
- typescript
- vite
Log in or sign up for Devpost to join the conversation.