DEV Community: Sohaib Hassan

AI Just Posted a Perfect Score at the Real Math Olympiad. I Spent Months Building One of These Systems. Here's What It Actually Takes

Sohaib Hassan — Sat, 08 Aug 2026 08:55:32 +0000

In July 2026, in Shanghai, something happened that mathematicians had been debating for two years: AI systems from Huawei and Xiaohongshu were each reported to have solved all six problems of the International Mathematical Olympiad, a perfect 42 out of 42. Several other labs reported matching results on their own. It followed a 2025 breakthrough where Google DeepMind's Gemini Deep Think, officially graded by IMO coordinators, and an OpenAI experimental model both reached the gold-medal threshold of 35/42.

Headlines called it AI "beating" the world's best teenage mathematicians. I want to tell you what's actually behind a headline like that, not as a journalist, but as someone who spent the past several months building a much smaller, much less glamorous version of exactly this kind of system.

My teammate Samuel Koh and I entered AIMO3, the third AI Mathematical Olympiad Progress Prize, hosted on Kaggle. We scored 42 out of 50, placing 495th out of 4,138 teams, the top 12% globally. Here's the honest, unglamorous story of how we got there, what we tried that failed, and what the finished system actually looks like under the hood.

What AIMO Actually Is (And Why It's Not the IMO)

First, an important distinction, because the acronyms get confusing fast: AIMO is not the IMO.

The AI Mathematical Olympiad is a $10 million prize fund, created in 2023, that exists specifically to close the gap between what the closed, proprietary models at OpenAI and Google can do and what the open community can build. Its grand prize, $5 million, goes to the first team that publicly shares a model capable of gold-medal-equivalent performance at the actual IMO. Along the way, Kaggle hosts periodic "Progress Prize" competitions to measure how far the open field has come.

AIMO1 was won by Project Numina in 2024. AIMO2 was won by NVIDIA's team, NemoSkills, who solved 34 of 50 problems. AIMO3, the one we entered, raised the difficulty again: 110 entirely original problems, ranging from national-olympiad level up to full IMO standard, spanning algebra, combinatorics, geometry, and number theory. "Entirely original" matters enormously here: it means no amount of memorization from training data helps you. Every problem has to be reasoned through, not recalled.

Competitors were also given access to H100 GPUs, roughly double the compute of AIMO2, which meant we could run larger open-weight models than previous years: models like GPT-OSS-120B and Qwen3-Next became viable for the first time.

So when you read that an AI "scored a perfect IMO," understand what's actually being claimed. In 2026, most of those results, including the ones from Huawei and Xiaohongshu, were the companies' own self-reported submissions, run after the human competition window closed, evaluated against the same problems and time limit but not scored live by IMO coordinators. Only a small number of 2025 and 2026 results have been independently, officially graded. That's not a reason to dismiss the progress. It's real, and it's fast. But it's worth knowing the difference between "officially certified" and "self-administered" when you see the next big claim.

Two Rules That Shaped Every Decision We Made

Before I describe what we built, you need to understand the two constraints that made this hard, because they killed almost every "obvious" idea we had.

Rule one: five hours of GPU compute, total, per problem set. Not per problem. Per set. That immediately rules out anything computationally greedy.

Rule two: binary scoring, no partial credit. A problem is either fully correct or fully wrong. This sounds simple, but it has a brutal implication: a system that produces a plausible, confident-sounding, but wrong answer is worse than a "generic" wrong answer, because it's confidently wrong. Under this rule, knowing when your system is unsure is almost as valuable as getting the right answer.

I handled the mathematical side: interpreting problems, checking whether a given line of reasoning was actually valid, and sourcing harder test cases beyond the standard dataset to stress-test our system. Samuel handled the engineering: building and running the inference pipeline under that fixed compute budget. Neither role alone was enough. The problems weren't purely mathematical, and they weren't purely a systems problem either.

Four Ideas We Killed Before Writing a Line of the Final System

Here's what we considered and rejected, and why each one matters as a lesson, not just a footnote:

Supervised fine-tuning. The obvious first instinct. Rejected immediately: it needs massive GPU clusters and months of runway, not a fixed five-hour, competition-scale budget.
Fully agentic search, a system that breaks a problem into steps, calls tools, verifies intermediate results, and loops back on itself. Conceptually, this is the closest thing to how a human mathematician actually thinks. We rejected it anyway, because Kaggle's environment has no outbound internet access, and an open-ended agentic loop risked silently burning our entire compute budget before ever producing a final answer.
Monte Carlo Tree Search. Not used.
Long, verbose chain-of-thought prompting. We tested it. Concise prompting consistently outperformed it.

The pattern across all four rejections is the same one that ended up defining our whole approach: under a fixed, non-negotiable compute budget, a simpler system you can actually trust beats a theoretically more powerful one you can't fully control.

The Architecture: A Parallel Self-Consistency Pipeline

What we actually built and submitted, we called a Parallel Self-Consistency Pipeline. Here's how a single problem moves through it, end to end:

The problem is written in LaTeX and gets converted into a structured prompt.
The base model, GPT-OSS-120B (OpenAI's open-weight mixture-of-experts model, around 120 billion total parameters but only about 5 billion active per token, which is exactly why it fits on a single H100 despite its size), generates a reasoning attempt at temperature 0.8.
The Parallel Sampler does this eight times, independently, all at once. This is the "self-consistency" idea, and it's built on a real insight from a 2022 paper by Wang et al.: a single reasoning chain can silently go wrong at any step with no way to catch it, but across eight independent attempts, correct reasoning tends to converge on the same answer while failure modes tend to scatter in different directions.
Tool-Integrated Reasoning. Each of those eight attempts is paired with a live Python interpreter. The moment a reasoning chain hits a calculation it can't reliably do purely in text, it hands that calculation off to Python instead of guessing, a small design choice that removes an entire category of careless arithmetic errors.
The Entropy-Weighted Aggregator. This is the part I'm proudest of. Instead of a simple majority vote across the eight candidate answers, each one is scored by:

score = \frac{1}{H} + 8.0 \cdot V

Here, H is the mean generation entropy of that attempt (how "confident" the model was, token by token, while producing it) and V is a verifier score. Because the formula uses 1/H, a low-entropy, confident attempt scores higher than a scattered, uncertain one, even if it wasn't the majority answer. There's also an early-stopping rule: if any single answer already has four or more votes, the aggregator stops and submits it immediately, saving compute for the next problem instead of waiting out the clock.

I actually animated this entire pipeline in Manim: every arrow, every fan-out, every step of the aggregation, so you can watch it play out visually instead of just reading a static diagram:

From 8/50 to 42/50: What the Climb Actually Looked Like

Our first working version of this pipeline scored 8 out of 50. The final version scored 42. That climb didn't come from one clever trick. It came from three unglamorous things, repeated over and over: systematically diagnosing bugs in the pipeline itself, upgrading the base model as better open-weight options became available, and steadily refining the few-shot prompts feeding into step one.

There's one more data point that told us we were on the right track, and it came after the competition closed. The eventual first-place team's public writeup also centered on GPT-OSS-120B, and their approach was also built around entropy-weighted self-consistency, refined further with things like adaptive runtime scheduling, but directionally the same idea we'd arrived at independently. When a team with more resources converges on the same core mechanism you did, without either of you seeing the other's work, that's a stronger signal than any single benchmark score.

The One Lesson I'd Give Anyone Building AI Under Real Constraints

Every rejected idea (fine-tuning, agentic search, tree search, verbose prompting) failed for a version of the same reason: it added complexity we couldn't fully control inside a budget we couldn't negotiate. The thing that actually worked was the opposite: precision and reliability over architectural cleverness.

That's not a lesson specific to Kaggle competitions. It's true anywhere you're building an AI system against a real constraint: a latency budget, a cost ceiling, a compliance requirement. The fanciest architecture on paper is worth nothing if you can't trust what it does when the clock is running.

As for the "AI beat the Olympiad" headlines, they're not wrong, exactly. The field genuinely moved from silver-medal level in 2024, to officially certified gold in 2025, to multiple perfect-score claims in 2026, in about two years. I watched a smaller version of that same curve happen inside my own project, going from 8/50 to 42/50 in a few months of iteration. The trend is real. Just read the fine print on "official" versus "self-reported" before you decide how impressed to be by any single claim.

I've taught undergraduate mathematics for 9+ years, and I build Manim-animated math content as PlotLab. If you want to learn the exact animation workflow shown in the diagram above, from your first Scene to a full multi-step pipeline animation, I wrote a complete, copy-paste-ready guide: Manim CE Beginner's Handbook. If you'd rather have someone build it for you, for an undergraduate or graduate thesis defense, a research paper, or any project where the math needs actually to look as good as it sounds, I take on that work directly; you can see the quality for yourself on Facebook (35K+ followers) and Instagram (15K+ followers), and reach out if you'd like to work together. I write more essays like this one on mathematics, AI reasoning, Manim Animations, and teaching at sohaib-hasan.github.io. I'd genuinely like to hear what you think of the pipeline above; drop a comment.

I Spent 5 Years Making Math Animations in Python. Here's Everything I Wish I Knew on Day One.

Sohaib Hassan — Wed, 29 Apr 2026 12:04:54 +0000

A complete, honest guide to building 3Blue1Brown-style math animations with Manim CE — from zero setup to your first polished scene. No fluff, just what actually works.

The first time I tried to make a math animation, I spent four hours staring at an error message I didn't understand.

No one warned me about LaTeX dependencies. No one explained the difference between Text and MathTex. No one told me why my equation was rendering in the wrong position — or why my animation was playing twice — or why the camera was cutting off half my scene.

I figured it out eventually. But it took months, not days.

If you're reading this, you probably want to create math animations. Maybe you've watched 3Blue1Brown explain calculus and thought "I want to make something like that." Maybe you teach mathematics and you're tired of static diagrams that put students to sleep. Maybe you're just curious whether Python can actually produce beautiful, publication-quality math visuals.

It can. And it's more accessible than you think.

But only if someone shows you where to actually start.

What Is Manim — And Why Does It Matter?

Manim is an open-source Python library built specifically for mathematical animations. Every equation you render is typeset through LaTeX. Every shape, every graph, every transformation is mathematically precise — not visually approximate.

This is what separates Manim from every other animation tool.

When you draw a circle in Manim, it's a perfect circle — defined mathematically, rendered with zero distortion. When you write a quadratic formula, it looks exactly like a published research paper. When you animate a transformation, every frame is calculated programmatically.

This is why educators, researchers, and content creators around the world have adopted it. Not because it's easy — but because nothing else produces results like this.

The Mistake Everyone Makes on Day One

Most beginners open Manim, look at the documentation, and immediately feel overwhelmed.

The documentation is comprehensive — but it's not written for beginners. It assumes you already know what you're looking for. If you don't, you'll spend hours reading without actually building anything.

Here's the truth: you learn Manim by writing scenes, not by reading documentation.

Every concept clicks the moment you run working code and see it render. Not before.

This is why the copy-paste-first approach works so much better than theory-first learning.

What You Actually Need to Get Started

Before writing your first scene, you need four things — and three of them are completely free.

1. Python 3.9 or later
If you already have Python installed, you're halfway there. If not, the official Python website has a one-click installer for every OS.

2. Manim CE v0.20.1

pip install manim==0.20.1

3. A LaTeX Distribution ← This is where most beginners get stuck

Manim uses LaTeX to render equations. You need either:

MiKTeX (Windows)
TeX Live (Mac/Linux)

Both are free. Both take about 15 minutes to set up. Do not skip this step — skipping it is why 80% of "Manim doesn't work" posts exist on forums.

4. VS Code
Any text editor works, but VS Code gives you syntax highlighting, terminal integration, and extensions that make Manim development significantly smoother.

That's the entire setup. No subscriptions. No expensive software. No complicated configuration beyond these four things.

Your First Scene — What It Looks Like

Here is the simplest possible Manim scene. Copy this exactly, save it as first_scene.py, and run it:

from manim import *

class HelloManim(Scene):
    def construct(self):
        equation = MathTex(r"x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}")
        self.play(Write(equation))
        self.wait(2)

Render it with:

manim -pql first_scene.py HelloManim

In under ten seconds, you'll have a video of the quadratic formula writing itself onto the screen — typeset perfectly, animated smoothly.

That's Manim. That's what three lines of actual code produce.

💡 Always use -pql (low quality) while developing. High-quality renders take minutes. Save -pqh for your final output only.

The Five Concepts That Unlock Everything

After years of building animations, I can tell you that 90% of what you'll ever need in Manim comes down to five core concepts.

1. `MathTex` and `Text`

MathTex renders LaTeX equations. Text renders plain words. Knowing when to use which — and how to color individual parts of an equation — is the foundation of every math explainer.

# Correct — renders LaTeX
equation = MathTex(r"E = mc^2")

# Wrong for equations — won't render LaTeX
label = Text("E = mc^2")

2. Shapes and Geometry

Circles, squares, triangles, lines, arcs — all mathematically defined, all fully customizable. Once you understand how positioning works in Manim, placing objects exactly where you want them takes seconds.

circle = Circle(radius=1, color=BLUE)
square = Square(side_length=2, color=GREEN)
square.next_to(circle, RIGHT, buff=0.5)

3. Animations and Transforms

Write, Create, FadeIn, Transform, ReplacementTransform — these are the verbs of Manim. Each one does something specific, and choosing the right one makes the difference between an animation that feels natural and one that feels jarring.

self.play(Write(equation))           # draws stroke by stroke
self.play(FadeIn(circle))            # fades in from transparent
self.play(Transform(square, circle)) # morphs one shape into another

4. `NumberPlane` and Graphs

Plotting functions in Manim is remarkably clean. Define your axes, pass a lambda function, and Manim draws it — with full control over color, range, and style.

axes = Axes(x_range=[-3, 3], y_range=[-1, 9])
graph = axes.plot(lambda x: x**2, color=YELLOW)
self.play(Create(axes), Create(graph))

5. Updaters and `ValueTracker`

This is where Manim becomes truly powerful. Updaters let objects respond dynamically to changing values — this is how you create animations where a tangent line moves along a curve, or a point traces a parametric path in real time.

tracker = ValueTracker(0)
dot = always_redraw(
    lambda: Dot(axes.c2p(tracker.get_value(), tracker.get_value()**2), color=RED)
)
self.play(tracker.animate.set_value(2), run_time=3)

The Common Mistakes That Cost Beginners Hours

I made every single one of these. You don't have to.

Mistake	What to do instead
Rendering high quality every time	Use `-pql` while building. Switch to `-pqh` only for the final render.
Not using `VGroup` for positioning	Group related objects with `VGroup` — positioning a group is infinitely cleaner than positioning each object individually.
Hardcoding coordinates	Use `.next_to()`, `.shift()`, `.move_to()`. Your layout will survive any change you make.
Using `Text` for equations	If your equation looks wrong — jagged, unstyled, broken — you're almost certainly using `Text` when you should be using `MathTex`.
One long `construct()` method	Break your scene into helper methods. A readable scene is a maintainable scene — especially when you return to it three weeks later.

A Complete Working Example — From Zero to Polished

Here's a scene that combines everything above. Copy it, run it, and modify it as your own starting template:

from manim import *

class QuadraticExplainer(Scene):
    def construct(self):
        # Title
        title = Text("Solving a Quadratic Equation", font_size=36)
        self.play(Write(title))
        self.wait(1)
        self.play(title.animate.to_edge(UP))

        # Standard form
        standard = MathTex(r"ax^2 + bx + c = 0", font_size=48)
        self.play(Write(standard))
        self.wait(1)

        # Transform to quadratic formula
        formula = MathTex(
            r"x = \frac{-b \pm \sqrt{b^2 - 4ac}}{2a}",
            font_size=48
        )
        self.play(ReplacementTransform(standard, formula))
        self.wait(2)

        # Highlight the discriminant
        formula[0][9:19].set_color(YELLOW)
        discriminant_label = Text("discriminant", font_size=24, color=YELLOW)
        discriminant_label.next_to(formula, DOWN)
        self.play(Write(discriminant_label))
        self.wait(2)

Run with:

manim -pql scene.py QuadraticExplainer

Where to Go From Here

Manim has a learning curve — but it's not as steep as it looks from the outside. The moment your first animation renders, something shifts. You stop seeing it as code and start seeing it as a creative tool.

The path forward is simple: build scenes. Start with something small — an equation, a shape, a simple transform. Then add complexity one layer at a time.

I spent years on this path. I documented everything — every mistake, every shortcut, every pattern I kept returning to — into a structured beginner handbook:

📘 Manim CE v0.20.1 Beginner Handbook

Ten complete chapters. Copy-paste-ready code for every concept above. Common mistakes are prefixed before you hit them. 60 pages.

If you want to see what Manim looks like in practice before committing to anything, the animations are here:

📱 @plotlab01 on Instagram

Start building. The best math animation you'll ever make is the next one.

About the author: Sohaib Hasan is a Mathematics Lecturer with 9 years of experience and 1,500+ students taught. He creates 3Blue1Brown-style math animations using Python and Manim, and shares them at @plotlab01.