All that keeps jumping out at me is how they've set it to refuse giving users thinking tokens and prompts for full reasoning in output. Just drives me further away; I may not stop using Claude completely for now, but I'll be moving even more of my primary workload to Chinese providers. That's where openness and freedom is now at.
What Chinese models/providers are you using for this? I'm hitting Claude's weekly limits much sooner than I used to with roughly the same workload, so I'm interested in trying alternatives, especially ones with strong coding/agentic performance.
In my experience that tactic works well if the codebase is limited in size, or well maintained and separated. Otherwise I do notice a difference also letting fable do the execution, not just the planning for complex tasks.
In my experience it never works well on any real work. In fact, I'd go the opposite, plan with the dumb model and execute with the smart model because at least the model writing the code and solving the emergent problems is capable.
In my experience (and I've been trying this a bunch): smart planner + dumb executor produces worse code with higher spend than simply using the smart planner to do both.
It's easy to understand why:
- If the planner has truly thought the issue through, properly designed the solution, solved all of the emergent problems, then the final "write" of the code is just a few more output tokens.
- If the planner has NOT truly planned the issue completely, then you're letting a substantially dumber and less capable model make significant decisions, and trusting its problem solving, without having a better model check it.
If you're highly cost conscious (paying for your own tokens and not making any money) then you have no choice but to trade your time and effort for tricks like this to save money by lowering the quality of your output.
But if your employer is paying for tokens: just use the smarter model. You save your time preventing re-work and reducing code review, you save your employer money (primarily from the cost of your own labor and reduced rework), and you get a better output every time (Opus 5.5 mogs Deepseek 4.1 flash in every single way except cost).
> If the planner has truly thought the issue through, properly designed the solution, solved all of the emergent problems, then the final "write" of the code is just a few more output tokens.
For me, what usually creates the high cost of implementation with a larger model is the validation process, not the writing of code.
I would get excited to see it finish writing code with so little usage, but then it would gobble up ten times as many tokens on validation.
I've tried to instruct it to keep the validation light with the intention of doing batches of deep validation after a few tasks, but it couldn't stop itself from doing heavy validation on each task no matter how I rephrased the instructions.
skeledrew · · focus · HN ↗
rajeevk · · focus · HN ↗
arcanemachiner · · focus · HN ↗
A common tactic is to used a big brain model like Opus for planning and reviewing, and a cheaper model for execution.
lukan · · focus · HN ↗
criley2 · · focus · HN ↗
In my experience (and I've been trying this a bunch): smart planner + dumb executor produces worse code with higher spend than simply using the smart planner to do both.
It's easy to understand why:
- If the planner has truly thought the issue through, properly designed the solution, solved all of the emergent problems, then the final "write" of the code is just a few more output tokens.
- If the planner has NOT truly planned the issue completely, then you're letting a substantially dumber and less capable model make significant decisions, and trusting its problem solving, without having a better model check it.
If you're highly cost conscious (paying for your own tokens and not making any money) then you have no choice but to trade your time and effort for tricks like this to save money by lowering the quality of your output.
But if your employer is paying for tokens: just use the smarter model. You save your time preventing re-work and reducing code review, you save your employer money (primarily from the cost of your own labor and reduced rework), and you get a better output every time (Opus 5.5 mogs Deepseek 4.1 flash in every single way except cost).
joquarky · · focus · HN ↗
For me, what usually creates the high cost of implementation with a larger model is the validation process, not the writing of code.
I would get excited to see it finish writing code with so little usage, but then it would gobble up ten times as many tokens on validation.
I've tried to instruct it to keep the validation light with the intention of doing batches of deep validation after a few tasks, but it couldn't stop itself from doing heavy validation on each task no matter how I rephrased the instructions.