Inspiration
Developers using AI coding assistants almost always default to one familiar model for every task — the one they're used to, regardless of whether the task actually needs that much power. Formatting a CSV with a top-tier reasoning model, routing every support ticket through the most expensive option, using the same model for a one-line fix as for a full architecture redesign. This is backed by research on model adoption patterns showing usage is driven by habit and brand familiarity, not task fit — even built-in auto-routers optimize for general cost/performance, not for decomposing what a specific task actually needs.
What it does
Agentic Model Router takes a task, breaks it into logical steps (discovery → design → implementation → verification), estimates the real complexity of each step separately, and routes it to the right GPT-5.6 tier — Luna for easy work, Terra for standard implementation, Sol (with high reasoning effort) for steps that genuinely need deep reasoning. Instead of one model for the whole request, every piece of the task gets the model it actually needs.
How we built it
Planner → Estimator → Router → Executor, all built inside Codex, iterating module by module. The Planner decomposes a task and lists relevant files (not contents). The Estimator (Terra) classifies each step against a concrete rubric — easy/medium/hard/very hard — and routes it to Luna/Terra/Sol accordingly. The Executor is an agentic call with file read/list tools that executes the step against the real codebase. Context handoff between steps uses a git-diff-based approach: only the most recently changed files are passed forward, keeping context lean.
We demoed it by adding a Labels feature (color-coded, filterable) to Kanboard (open source, MIT license), decomposed into 6 steps of varying complexity.
Challenges we ran into
The estimator initially over-classified almost everything as hard/very_hard, which would have defeated the entire cost-saving premise — we tightened the rubric with concrete anchoring examples and a conservative-by-default instruction, which brought it to a realistic 1 easy / 4 medium / 1 hard distribution, verified stable across repeated runs. We also found, through manual review, that Sol's design step decided to reuse Kanboard's existing tagging system entirely rather than building a new data model — which we hadn't anticipated but is exactly the kind of decision-quality this approach is meant to surface.
Accomplishments that we're proud of
Real, measured numbers, not estimates: on this run, only 1 of 6 steps needed Sol, but that step still made up ~81% of the actual cost — a reminder that step count and cost share tell different stories. Overall the run cost ~17% less than routing everything through Sol. The full feature was manually verified end-to-end in the running Kanboard app.
What's next
This is a focused PoC with deliberately scoped-out pieces: no automated result verification yet (test/lint + LLM-as-judge is the natural next step), no fallback for tier unavailability (circuit breaker pattern), and complexity estimation is currently LLM-judgment based rather than calibrated against benchmarks.
Log in or sign up for Devpost to join the conversation.