◇ Could this help me?
Yes. Matching the model to the difficulty of the task is one of the most reliable ways to cut cost without losing quality, because the hard part of most coding work is deciding what to build, and once that decision exists a cheaper model executes it perfectly well. The tiering proposed here is sensible in shape: strongest model for architecture and design, mid tier for breaking that into pieces, standard for writing the code, smallest for search and lookup. General practice, with the caveat that the boundaries are worth testing on your own work rather than adopted as fixed, since a task that looks like execution can turn out to need judgment, and the saving is not worth a wrong result.
Help me set up tiered model routing for my work so I stop paying top-tier prices for tasks that do not need it. Take the kinds of tasks I describe below and sort them into four tiers: architecture and design decisions where reasoning quality changes the outcome, breaking those decisions into implementable pieces, writing code against a plan that is already decided, and simple search or lookup. For each tier, recommend the cheapest model you would trust, explain what would go wrong if I dropped one tier lower, and tell me which tasks are borderline enough that I should test both before committing.