Skip to content

Documentation

How G6 Thinks

Five PhD-level problems, solved two ways. Download each notebook to see the complete reasoning trace — every tool call, every decision, every mistake — so you can judge for yourself.

How G6 Thinks: Worked Examples on PhD-Level Problems

Five problems from Humanity's Last Exam, solved two ways: Claude alone, then Claude with G6 tools. Each notebook shows the complete reasoning trace so you can see exactly where tools help — and where they don't.

Delegate computation, keep reasoning
When the hard part is calculation rather than insight, G6 tools let the model hand off the work and stay cheap.
Structured decomposition prevents wrong paths
On Q28 the baseline wandered for 11 minutes and got the wrong sign. G6's decompose-then-verify sequence caught the error early.
Tool trust is an open problem
On Q22 the grounding tool returned the correct clinical fact, but the model overrode it. We show exactly where this happens.
A note on honesty

These notebooks don't cherry-pick wins. Two of the five questions are failures — and the failures are more interesting than the successes. We show you exactly where G6 falls short and why, because understanding the limitations is how you decide whether the system is right for your problem.

Download summary notebook 06_hle_evaluation_v3.ipynb

Worked Examples

Each notebook contains the full reasoning trace from both conditions — Claude alone and Claude + G6 — followed by an honest analysis of what happened and why.

1

When tools save 13x on cost

"What is the largest prime divisor of 8,139,881?"

The model knows how to factorise — but doing it in-context burns tokens. One tool call gets the answer in seconds for a fraction of the cost.

Mathematics
Notebook
2

When tools gracefully stay out of the way

"How many categories with 3 morphisms and one object exist?"

Pure reasoning problem — no computation to delegate. G6 adds no overhead: same answer, similar cost. Tools don't hurt when they're not needed.

Mathematics
Notebook
3

When the benchmark itself is wrong

"Central pixel of Bresenham's line from (1,1) to (11,5)?"

Every implementation agrees on (6,3). The ground truth (7,4) relies on a non-standard convention from an illustration. G6's tool audit trail gives us confidence in the answer.

Computer Science
Notebook
4

When the model ignores its own tools

"Maintenance fluid rate for a 22kg child on chemotherapy?"

G6's grounding tool returned the correct clinical fact (milk is 70% free water). The model read it, then explicitly rejected it. This is the model-tool trust gap — a solvable but unsolved problem.

Medicine
Notebook
5

When structured reasoning prevents catastrophic failure

"Elasticity of search intensity w.r.t. unemployment probability?"

The baseline got the wrong sign (-0.342 vs ground truth 0.218). G6's decompose-symbolics-numerics-verify sequence produced 0.220 — correct structure, correct sign, 0.9% off. The tool chain acts as guardrails.

Economics
Notebook
About these examples: Problems are drawn from Humanity's Last Exam, a benchmark of expert-level questions across mathematics, computer science, medicine, and economics. Each question was run through Claude Opus 4.6 via Claude Code headless — once without tools, once with G6's MCP tools (domain grounding, symbolic math, cognitive architecture, debate/consensus). Every notebook is self-contained and reproducible from development/run_hle_eval.py.