Yeah, I've tried this as well, but via Antigravity - it was very effective. I wish to have some smart router that monitors the trends of your usage and has skills-based routing to the best model for the job.
By usage trend I mean something considering Codex almost predictable resets, your usage, and maybe even plan ahead using your backlog to know what you will need sooner.
For example, if you want to ship a lot of UI/UX this week, save Claude for it, and use other models to do the coding.
In fact, I completely revamped the way I do testing and even GitHub Actions, because I started to get hit with a lot of GitHub Actions costs. So, what I did was a smart test actions, which verify if the code has test attestations for local runs, so, they just skip burning GitHub Actions redundantly - the code has already been tested successfully locally.
Another huge burn from Actions came from squashed PRs - my attestations didn't work as the commit hash changes, so, I needed to put that into consideration as well.
In general, I'm completely revamping my release cycle, not allowing PRs to age, and main no longer represents Production. Agents keep merging as soon as possible and then another process assesses if there's a good enough release candidate having enough features that pass more extensive tests. There's no point to always test and always fix piece by piece if you're not going to release.
So, the RC candidate also generate a changelog, blog posts with the features, and so on.
By usage trend I mean something considering Codex almost predictable resets, your usage, and maybe even plan ahead using your backlog to know what you will need sooner.
For example, if you want to ship a lot of UI/UX this week, save Claude for it, and use other models to do the coding.
In fact, I completely revamped the way I do testing and even GitHub Actions, because I started to get hit with a lot of GitHub Actions costs. So, what I did was a smart test actions, which verify if the code has test attestations for local runs, so, they just skip burning GitHub Actions redundantly - the code has already been tested successfully locally.
Another huge burn from Actions came from squashed PRs - my attestations didn't work as the commit hash changes, so, I needed to put that into consideration as well.
In general, I'm completely revamping my release cycle, not allowing PRs to age, and main no longer represents Production. Agents keep merging as soon as possible and then another process assesses if there's a good enough release candidate having enough features that pass more extensive tests. There's no point to always test and always fix piece by piece if you're not going to release.
So, the RC candidate also generate a changelog, blog posts with the features, and so on.