Orchestration Part3: Why I took the architect tier out of my delivery work on purpose

I pay for less AI than I could afford. On purpose. Two months ago I dropped the top tier from my subscription — the architect tier, the one with Opus Max in it. Not because it wasn't good. Because it was too good at being reached for.

Here's what was happening. A flaky test in the BowSmith suite? Architect tier. Renaming a config key across three files? Architect tier. A one-line fix I could have typed faster myself? You guessed it. When the most capable model is one keystroke away, every problem starts to look like an architecture problem. I was paying a premium to overthink.

Price is the only reviewer that never sleeps

The moment the tier came with a visible line item, something changed: every call to it had to survive a question. Is this worth the architect? Most weren't. Roughly four out of five things I'd been routing to the top of the stack got done — done well — by Opus orchestrating a couple of Sonnet workers.

That's not a discount trick. That's the whole point of the three-tier stack: the architect tier exists for decisions, not for work. Which system boundary to draw. Whether a plan is worth building at all. The moments where being wrong costs you a week. Cost-per-token is the wrong unit; cost-per-decision-that-mattered is the right one. Measured that way, Opus Max is cheap — but only if you stop spending it on things that never needed a decision.

The dishes-vs-kitchen rule

You don't remodel the kitchen to wash a plate. But if remodeling is free at the point of use, you'll find yourself doing it weekly. The overengineering trap isn't a capability problem, it's a friction problem: three tiers pointed at a one-tier task doesn't just waste tokens, it adds hand-offs, context transfer, review overhead — coordination cost with nothing to coordinate.

Removing the top tier from the default path taught me what the top tier is actually for. When I add it back for a real architecture week — and I do — it earns its seat every time.

Then Fable disappeared from availability entirely, and the constraint I'd chosen became everyone's constraint. Suddenly my weird frugality looked like preparation. The stack didn't collapse; it barely noticed. Which tells you something about how much of the "architect tier" workload was ever architectural.

Next week I'll map the whole stack onto the Research → Plan → Implement → Quality loop — where the architect tier genuinely lives, in Post 4.

If you're testing Fable / Opus Max too, where did it land for you? Did the top tier earn its line item, or did it become the expensive habit? I'm collecting answers.