Using a small model as orchestrator and a large model as worker costs more and produces worse results than the opposite approach.
Adapted from @anshuc# The Idiot Boss approach to getting more Astra/Fable quota Most people say to use the big, expensive model as an orchestrator, delegating grunt work to small, cheap workers. That's the opposite of what you should do. Here's why. # Comparing different approaches ## Approach 1: Just use the big model This is how most people start. Fire up Codex or Claude Code, pick the best model, drop in your prompt, and off you go. This produces great results; it's what AI companies test, optimize for, and promote. Here are a couple examples with GPT-6 Astra (light): Prompt: > Build a polished browser-based 3D room-planning studio called ROOM / STUDIO. I want simultaneous editable 2D plan and interactive 3D room views, with a furniture catalog, pointer placement/dragging, selection synchronized across both views, .25m snapping, 90-degree rotations, a dimensions/position inspector, deletion, and clear collision/out-of-bounds feedback. Use actual 3D geometry with orbit controls, coherent furniture silhouettes and lighting. Start with a tasteful valid furnished 6x5m living room. All visible controls should work. Keep it usable at desktop 1440x900 and laptop 1100x760. Export from the adapter must work now so I can retain this layout for future changes. Serve the app from index.html using a static server. Validate through the browser before calling it done. Result: Prompt: > Create a full-viewport realtime 3D articulated robot scene. Focus effort on attractive mechanically coherent geometry: bolted pedestal, cylindrical shoulder/elbow housings, tapered links, wrist collar, gripper, inset seams, layered materials, soft lighting and floor shadows. Real joint hierarchy follows supplied kinematics. Orbit/zoom, 3D picking with highlight, camera presets and four joint controls in a small collapsible overlay. No app shell, panels, editor, menus or file workflows. This is what Astra can do out of the box. It's a good model! Unfortunately, it's also an expensive model. Here are the costs for the above runs: We'll compare everything as equivalent API cost, since OpenAI and Anthropic don't give us insight into how quotas are calculated. API cost is directly proportional to quota consumption. ## Approach 2: Genius Boss, Idiot Worker This is what most people think you should do. Astra is expensive, so don't make it do grunt work. Let it own the planning, and delegate the heavy work to smaller models. Here are the same examples with GPT-6 Astra (light). In each case, we use the same prompt as before, with this added instruction: > Plan and review the work, but delegate most of the implementation to subagents using Luna with xhigh reasoning. You are responsible for orchestration, execution, and delivering a good end result. Only take on minor bug fixes yourself where delegation would be overkill. We clearly lost quality. The 2D and 3D room views got much more simplistic, and the sidebars are plainer and uglier. The arm scene ended up blockier and less detailed. OK, but at least we saved quota, right? Well… What?! It's more expensive? The web app took 5x as long?? This shocked me, so I had Astra investigate the difference. Here's what went wrong with this approach: - The outer Astra thread grew long, filled with subagent tool calls and validation work. Despite prefix caching, the long input added up. - Astra had to write a lot of tokens as subagent prompts, to spell their jobs out clearly. - Astra then had to spend more tokens reviewing the work, testing it, and cleaning up bugs. On top of costing more tokens, the results were worse because weaker agents wrote all the code, and Astra could only do so much to clean up after them. ## Idiot Boss, Genius Worker Let's see what happens when we swap the roles of Luna and Astra. Yes, it sounds weird, but we're going to let Luna boss Astra around. Bear with me. Again, same prompt as in the baseline, with added instructions: > Use an Astra subagent with light effort to do all implementation work in one continuous thread. You coordinate, browser test, and pass findings + the latest product screenshot back to Astra. Instruct Astra to not test or review work, just stop after implementation. Each of your prompts to Astra should be minimal, with the above product brief and screenshot, no technical opinions or details. Tell it to work towards the goal and fix issues it finds, then recap very briefly. Stop after 3 rounds of this, or if Astra says the product is complete. Compared to letting Astra do everything, it's pretty close. The robot arm looks great to me, but the room previews are a little less detailed. However, look at the costs: We cut costs by more than half, and it's 30% faster! # Why does this work? Four words: Easier said than done. Suppose you want to build a beautiful landing page with AI. In the Genius Boss case, your big model needs to compress all the taste in its weights into instructions for a dumber model. This is lossy. > Genius Boss: Hey, build me a beautiful landing page for a boutique hotel on the Portuguese coast. I'm thinking travel magazine: like, oversized serif headlines, warm cream backgrounds, deep blue accents. Big, sunlit photos. Plenty of breathing room, with a few off-center details for visual interest, know what I mean? Want the hero to stand out, not too generic. Write natural, specific copy. Be sure to put nice, subtle timing curves on those animations! Oh, and make it look great on mobile. No sloppy gradients—but you knew that, didn't you? Idiot Worker: Uhh, yep, got it boss In the Idiot Boss case, we're asking the small model to just describe the goal at a high level. It doesn't need to know or care about details. The big model will do a great job with minimal direction. > Idiot Boss: Hey, build me a beautiful landing page for a boutique hotel on the Portuguese coast. I dunno, do your best. Make no mistakes? Genius Worker: Of course sir, it shall evoke within the user the delight of a glorious travel magazine… If you've been a manager of humans before, this won't surprise you. People think of the big-shot CEO with the strong vision and all the answers, calling the shots, giving everyone clear tasks and hitting milestones. This isn't how successful teams operate. You want your team to be smarter than you. You want to get them unblocked, point them in a direction, and let them run. # So this is the solution to all my problems? Use GPT-5.6 Luna for everything? Yes. GPT-5.6 Luna fixed my marriage. But only on xhigh reasoning. No, of course I don't think what I've described here is the general solution to every engineering problem. If you're trying to one-shot an entire complex multi-service application, you probably shouldn't let Luna run the show. Ask yourself these questions to determine how best to structure your agents: Do I care about quality/correctness above all else? If so, just use the big model for everything. Is my task very ambitious, with multiple steps? If so, don't let the small model decide things. Use the big model to break it down into a plan, and get the small model to just step through the plan and call out to big models to implement. Is the plan itself complex, or the product hard to test? You don't need to use the absolute smallest model as your orchestrator. One or two notches up (Terra or Sol, in Codex) will do a much better job following the plan and testing the app, while still saving tokens. And bear these in mind: - You do not want the small agent to have technical opinions. Its job should be glue, and light QA. It reads a plan, takes the next item, hands it to the worker, glances at the output, tests it out, grabs screenshots, and gives you status updates. All the things you wouldn't want to spend big model tokens on. - If your results are poor, look at the actual prompts being sent from the small model to the big one. Is it prescribing solutions instead of problems? You want to make sure you get the big model's judgment, not let the small one feed it bad information. - In long, complex runs, you may want to create additional hierarchy and occasionally clear out the big subagent's context. In smaller runs, you may benefit more from keeping one continuous subagent thread, so its prefix stays cached and it doesn't have to rediscover stuff. Put 10 minutes of thought into your setup, and you'll save hours of pain and millions of tokens. - Using clear target screenshots, plans, or prompts that keep the orchestrator honest and give the worker direction will lead to the best results. Multi-agent setups amplify ambiguities in your prompt. I haven't pushed this to the limits, and there are probably many use cases where it's not a good fit. If you try this out, I'd love to hear your experience, good or bad.
