Which coding tasks are worth the highest-capability model in your workflow?

[u/whereismy1]

I am trying to separate coding work that needs deep reasoning from work that mainly needs reliable execution. Designing a change across an unfamiliar codebase, diagnosing a subtle regression, and reviewing a risky patch seem worth a stronger model. Formatting, small translations, and clearly specified edits seem better suited to a faster path.

The decision is less obvious for medium-sized tasks: adding more context may be enough, but sometimes the task remains ambiguous even with all the relevant files included. Do you use a fixed escalation rule based on risk and testability, or decide case by case?

Which coding tasks do you consistently send to the most capable model?

I recently came across Flatkey while testing this kind of coding-task split. It is an OpenAI/Anthropic-compatible gateway that can be evaluated by changing the base URL while keeping the existing SDK and request format. That makes it possible to compare routine edits with a stronger path without rewriting the coding workflow. Actual savings depend on the model mix and current supply, so I would measure patch quality, tests, latency, retries, and total cost.

[u/dvduval]

Almost all my work involves databases and repose and customer questions and coordinating these three things often through a longer conversation.

We might be creating a new feature and we need to keep that conversation going for a while and it might go out with another thing we’re building and we have to coordinate that with a different feature.

I just find using extra high reasoning is simply more accurate. I know when I’m answering the customer or pushing out the feature that a lot of thought went into it and there’s very little slop.

[u/Sunstorm84]

Only really breaking down plans and things like that. Everything else I don’t really gain any noticeable speed difference between it and open weight models because of the need to review and fix all the problems.

I say that as someone using 5.6 sol xhigh for everything since it came out. It’s a lot slower for no eventual benefit; what’s the point?

I’m intending to trial making plans with Kimi k3 and some other open weight models with oh my pi next week, and if it’s good enough, I’ll be cancelling ChatGPT.

[u/TikiMagic]

I haven't figured it out yet. With Claude, I blow a zillion tokens with Opus or Fable and get pretty good results. Sometimes brilliant. Or hideous overthinking and overbuilding and Claudish glossolalia. You pays your money, you takes your chance.

So I step down to Sonnet for what I think are well-defined tasks and get janky brittle code, irrelevant questions, or just broken shit. And sometimes perfectly serviceable code.

Then I glance over at Haiku, but it still has gum in its hair and spit up on its shirt. But it seems so happy.

GPT Sol has been pretty good for me. But I don't have as much workflow and structure built up around GPT yet.

[u/AlexanderDoak]

I only use deep reasoning and or agentic crap for stuff that doesn't matter. Fun, inconsequential side projects. Outside of that, I need more low level evidence that the system isn't taking any shortcuts. Harder problems get LESS automatic reasoning, and MORE directed/custom reasoning.

[u/DevWorkflowBuilder]

rule of thumb here: if a bad diff is expensive to catch in review, big model. everything else gets the fast one.

[u/JBO_76]

writing the code for new exotic heads for my vision models: Vidsy AI — Offline AI Pipe Inspection Software

[u/Real-Service-8135]

imo the escalation trigger should be "can I verify correctness quickly." If the output is easy to test or lint, use the cheaper path and just validate. If a mistake would be subtle and hard to catch in review, thats when you want deeper reasoning upfront.

[u/Right-Performance-93]

Worth adding a budget dimension to the risk/testability rule everyone's using here: with Max 20x or Pro 20x, a weekly pool of roughly 500M-2B tokens (cache-inclusive, varies a lot by plan) means burning the top model on a task you could've verified cheaply isn't just wasted spend, it's quota you don't get back until the reset. I keep a running tally of which tasks actually needed the escalation in the post-mortem, and most of the "just in case" escalations turned out unnecessary once I checked the diff against tests.