How I route three models through one harness and get a 25x latency gap to work for me.
I was paying $500 a month for AI and still hitting usage limits. After Sol 6, Opus 5.5, and Grok 4.7 landed, my setup got simpler: two 20x subscriptions now cover the heavy work.
This benchmark shows a 25x spread before the first token appears. Grok 4.7 High starts in 0.85 seconds, Sol 6 Low in 1.81 seconds, and Opus 5.5 Medium in 21.27 seconds. That spread is a routing signal, not a leaderboard.
Most days I use three models, and sometimes a fourth, inside the same harness (that I built by myself).
The files, context, memory, tools, skills, terminal, and tests stay in place. I switch the model without rebuilding the job. I don’t context switch between Claude Code, Codex or Cursor.
Sol is my model. I use it to run the business, think, write, make decisions, and prepare prompts and specifications for coding agents. Opus 5.5 gets the serious code. Grok 4.7 gets narrow debugging loops where the work is easy to verify and I want it done FAST. A fourth model comes in when I want a clean comparison or second opinion, typically Astra (because Fable makes zero sense right now).
Grok has a measurable advantage in that lane. It started 53% sooner than Sol Low in this snapshot. At official API rates, Grok costs $2 per million input tokens and $6 per million output tokens; short-context Sol 6 costs $2 and $10. Input costs the same, while Grok output costs 40% less. Grok pricing, Sol pricing.
A client asked for a skill that could make these calls from the task, recent results, expected wait, and remaining usage. I am building it now.
Join the newsletter and I will send subscribers the alphaOS system when it is ready. No catch, free forever.
A fast first token changes the way I work
The table below comes from a September 24 snapshot of Artificial Analysis's API measurements. I checked the Sol, Sonnet, and Opus rows earlier that evening and added Grok 4.7 after its release. All rows use Intelligence Index v4.3.2. The cost column is the average cost of an Index evaluation task, not a monthly subscription price.
Sol Low has a combination I like. In this test it scored 34 on the Intelligence Index, started output in 1.81 seconds, and generated 91.8 tokens a second. Sonnet 5 Low started slightly sooner at 1.71 seconds, then generated 63.9 tokens a second and scored 24 on the same index. Sol Medium scored 40 and generated 114.3 tokens a second, with a 1.96-second time to first token. Those are API results, but they help explain why Sol feels so good for the everyday conversation. I can ask, see, correct, and keep going. Sol Low, Sol Medium, Sonnet Low.
I use boost because I like the feel of the faster interaction. I won't turn that into a made-up multiplier. OpenAI's Codex speed documentation lists the higher credit consumption for Sol Fast mode, but it doesn't publish a Sol-specific 1.5× speed claim. The table measures API performance, not my boosted subscription session.
Time to first token has another limit: a reasoning model may start producing internal reasoning before it produces an answer I can read. It doesn't tell you when the task is done. I care about first response, answer quality, corrections, and total elapsed time. A model wins a place in my day by doing well across all four. Artificial Analysis's performance method separates these measurements.
Sol is the model for me
I use Sol for general work: running the business, thinking through decisions, editing a paragraph, planning client work, and writing the prompt or specification that a coding agent will execute. It stays close to how I think. When the job becomes production code, I usually hand the plan to Opus.
Low keeps the back-and-forth immediate. I can catch a wrong assumption while the context is still in my head, correct it, and keep moving.
Then a task changes. A simple question turns into a difficult tradeoff. A code change exposes an edge case. I don't have to throw away the conversation and explain the whole problem again. I can move Sol to High or Extra High, or use Max when one problem deserves a longer single-agent run. Ultra is different: it can delegate separate parts of a complex task to subagents. It is useful when the work actually divides that way. OpenAI's model controls describe that distinction; the API model page lists Low through Max as reasoning efforts.
The wait rises quickly as you turn the dial. In this benchmark, Sol Extra High took 46.52 seconds to first token and scored 44. Max took 181.31 seconds and scored 48. That is a good trade when a hard result saves hours. It is a poor default for the kind of conversation where I want to ask another question in ten seconds. Sol Extra High, Sol Max.
MIKE wrote about changing reasoning effort inside one conversation:
“One conversation, one context, but different levels of effort depending on what you need.”
That's the feature I use. Cerebras puts its routing advice into a short instruction:
“Start with Luna, Then Escalate.”
I prefer Sol as my starting point. Nothing wrong with the escalation rule: turn the dial when the first setting runs into a real limit.
But as a CEO, my time is more valuable then to run on last year’s intelligence… I don’t care who you are, your personal time is all that you have, so why not raise the bar? Right?
Grok 4.7 gets the debugging lane
SpaceXAI announced Grok 4.7 this week. I use it for tasks with short feedback loops and an obvious pass/fail signal: reproduce a bug, patch a CSS problem, fix a failing test, change one API response, or tighten a small refactor. I can run the code after every step. If the patch misses, I can correct it immediately.
Artificial Analysis measured 0.85 seconds to first token at High and 0.95 seconds at Extra High. Sol Low took 1.81 seconds. Grok therefore started 53% sooner in this snapshot. Once it started, Grok High produced 52.4 tokens a second versus 91.8 for Sol Low. “Fast” here means faster visible feedback, not a guaranteed faster finish. Grok High, Grok Extra High, Sol Low.
The price reinforces that lane. SpaceXAI lists $2 per million input tokens and $6 per million output tokens. OpenAI lists short-context Sol 6 at $2 and $10. Grok input costs the same and its output costs 40% less.
The benchmark's cost-per-task column is still higher for Grok: $2.73 at High versus $0.13 for Sol Low. The models produced different amounts of work on the evaluation. For debugging, I track the cost of a verified fix. Cheap tokens stop being cheap when they create rework.
For architecture, migrations, and code where a mistake is expensive, Opus gets the first shot. Grok earns repeat work on the small deterministic jobs where speed changes the rhythm of the session.
Two 20x subscriptions are more than enough
The latest releases simplified my subscription stack. Codex Pro 20x handles Sol, and Claude Max 20x handles Opus. Together they cover the bulk of my work. I no longer need the biggest plan from every provider just because a new model launched.
Grok stays in a bounded fast lane. Its lower token price makes narrow debugging cheap enough to use freely, while the two 20x plans carry longer Sol and Opus sessions. The harness keeps the provider shuffle out of my way: the same context, tools, and tests are waiting whichever model I choose.
Run the code before you score the model
Opus 5.5 is my code model. It gets architecture, complex changes, migrations, and jobs where I want a deeper pass before I touch the result. It scored 51 at Medium in this table, the highest score here, with 21.27 seconds to first token. I accept that wait when it can remove rounds of repair.
I use Sol to shape the assignment, Opus for deeper implementation, and Grok for quick, verifiable corrections. The running code decides whether the route worked.
“A cheap model that produces rework is expensive.”
Exactly. If I spend my Friday afternoon fixing what the model broke, those cheap tokens cost me the part of the day I wanted back.
Karan's agent-system breakdown puts a name to the other problem:
“Put a frontier model into a badly designed agent system and you get a more articulate failure.”
Tools, context, memory, and verification change the result. I see it whenever an agent loses the thread of a project or declares code finished before running it. Then I get the final hour of work back on my plate.
My routing rule is short enough to remember:
Start business work, writing, decisions, and coding-agent prompts in Sol Low.
Increase Sol's effort inside the conversation when the problem earns the wait. Use Ultra when the job genuinely divides into separate parts.
Send architecture, complex production changes, and difficult migrations to Opus 5.5.
Use Grok 4.7 for reproducible bugs, failing tests, CSS problems, and narrow refactors with a clear pass/fail check.
Keep the harness constant. Run the code, record the result, and change the route when the evidence changes.
That is the skill I am building. It will consider the shape of the task, each model's recent success, expected wait, remaining usage, and the cost of a mistake. The harness already holds the context, tools, and tests, so switching models takes seconds.
Join the newsletter and I will send the routing skill free when it is ready. The first version will include the rules, usage checks, and fallbacks I use in my own harness.