Over the past year every AI tool I rely on for development of O9X has limited their usage limits(usage limits that refresh every 5 hours, and a weekly limit). Despite all my complaints, subscription is far cheaper than API usage (up to 20X cheaper). As I started to hit the weekly limits faster, I realised I need to focus on getting most work done within one 5-hour session, rather than issues closed or code generated or tokens consumed.
Over the last three weeks, I moved from using the latest model to using whatever could close the work safely inside one 5-hour session. The change looks simple but it needed me to change how I plan work, which models to use, when to create handoffs, and when to consider an issue closed.
I currently subscribe to four AI providers:
- Claude Pro Plan
- ChatGPT Business Plan
- Ollama Pro Plan
- Gemini Pro Plan (18 Months free for Jio subscribers)
Before starting any new session, I need to make 3 key decisions: the model, the reasoning level and the coding harness.
I started developing O9X in Claude Code with Opus and Sonnet. In the initial days, apart from Anthropic models, I never found other models reliable (too many errors and bugs). I stayed with Claude till the launch of OpenAI’s GPT-5.3-Codex.
In Feb ‘26 when OpenAI gave access to Codex for its Go plan users, I tried Codex. I was impressed with both the Codex and the GPT-5.3-Codex model. Codex’s security plugin listed 90+ security loopholes in my app. GPT-5.3-Codex identified errors, encouraging me to re-design my workflow.
In the same period, open-source models also made rapid improvement in code generation. However, in my test, I did notice higher token consumption of around 20-50% (using Nvidia Nim’s free API) when compared to Anthropic and OpenAI models. After a lot of trials, I subscribed to the Ollama Cloud Pro plan, giving me access to multiple open-source models.
For most part of May and June 2026, I updated my app’s payroll and compliance engine(implementing new labour codes). Once done, I ran a security audit in Codex, which identified eight minor issues and twenty architecture recommendations.
After reading the report, I tasked Opus 4.8 (Xhigh) to build a development plan using /to-prd skill. While Opus 4.8 and GPT 5.5 are excellent models, they exhaust my limits rapidly (2-4 times faster). Hence, I use alternate models (Sonnet, GPT 5.4 Mini, Kimi 2.6 and GLM 5.1) for implementation.
I asked Opus 4.8 (Xhigh) to group the twenty recommendations into themes, and build a plan for each theme. Either Opus or GPT 5.5 generates each plan and the other reviews it. Opus 4.8 recommended four themes. After reviewing the themes, I asked Opus to generate detailed plans for both the four themes and the eight issues.
I fixed the eight issues without any errors. However, it wasn’t the case for the security recommendations.
Opus reviewed work completed for my first theme, highlighting multiple errors. I asked Opus to fix them. Fifteen minutes later, I got the dreaded message: 100% Usage. Resets in 2 hr 35 min. Not even 40% of the errors were fixed by then.
I was tightening access control for the payroll and the pricing engine in O9X. The app has six user types, and every feature has it’s own access rules. While tightening payroll and pricing, AI loosened access for the compliance end points. My documentation allowed Opus to catch such errors but exhausted my limits before it could fix them.
If I keep using GPT 5.5 or Opus 4.8 to either code or fix the errors, my weekly limit would be exhausted before resolving all pending issues. Rather than resume the old session, I asked myself a different question: “How can I plan, build, test, review and deploy within one 5-hour session for different providers?”
In the first few months, Claude Pro plan (higher limits than current) was sufficient due to a simple rule: limit scope to one small change, then plan, build, test and deploy. Improvements in model capabilities resulted in scope creep within my prompts. Realising the error, I changed my approach. Utilising the improved reasoning ability of Opus and GPT (Xhigh), I started generating detailed implementation plans using the below prompt:
Now that we have identified all issues, let’s use the /to-prd skill to develop detailed implementation plans. The implementation will be done by smaller models (Sonnet, Kimi 2.6, or GPT-5.4 Mini). Hence the PRD needs to have complete details, with limited need to make decisions.You need to make those decisions now and if any are pending, ask me, don’t assume. Work with the assumption that the implementation agent has around a 150K context window and limit the need for compaction during execution. So, feel free to break down the pending issues into even smaller issues to meet the above constraint. Discuss with me before writing the plan. Don’t assume. Ask me for clarifications. We build tests before writing any code. Include a clear testing and review protocol to allow the agent to check its own work. Review work needs to be outsourced to a sub-agent once work is completed.
If either GPT or Opus was about to hit usage limits (~10%), I pause and create a handoff document. The twenty recommendations were converted into smaller twenty eight plans. Each plan was designed to be implemented in one shot. Over the next couple of days, I implemented each plan, reviewed it and after testing, I deployed the changes.
Every review session is done in the same planning session. When the session hits 60% context limit, I ask the AI to build a detailed handoff document to continue in a new session. The goal of keeping review and planning in the same session is to see if similar errors are repeating across different plans. If similar errors are recurring, then my plan needs to be fixed before blaming it on the implementation agent.
Only after my code passes all tests, builds without any errors and my review agent confirms, I consider the issue is closed. UI changes are easy to observe but the backend is tricky so I use Unit Testing and E2E tests to validate the changes. Codex Security automates security scans, so I resolve them as they appear.
One could argue that If I upgraded to Max plans of either Anthropic or OpenAI, I could have been done much faster with GPT-5.5 or Opus-4.8 (Xhigh). However, I wasn’t comfortable spending ten times more based on a hunch. I did not want to work under a constant threat of hitting my weekly usage limits.
My entire process does rest on two major assumptions: (1) I can afford to subscribe to multiple providers. (2) Open-source models keep improving with each release. Improvement in coding ability of open-source models is beyond my control but so far they have been doing a great job.
I would recommend Claude Code and Codex if you are just starting out. Be aware that they include around 12-20K of context overhead unlike Pi, which is around 1K tokens. However, Pi requires you to spend time to develop your own process else failure risk is higher. My current context overhead for Pi is around 5K tokens (ask Pi to build yours).
I learned early on that if I don’t run a tight ship, I risk failure due to context rot. Once you cross around 60% context limits, even the best models perform poorly. Hence, I include a 150K context window limit when building my plans.
Over the last three weeks I’ve moved from using the latest and greatest to using whatever does the job inside a single 5-hour session. Weekly limits also limit how many such sessions I can run in a week. Currently, I am able to get five or six in Codex, eight to ten in Claude Code, ten to twelve on Ollama. When my weekly limit for a plan drops to 10%, I shift to other providers. Most of O9X code was built when limits were more generous, so I don’t need to worry too much about the existing limits.
I still haven’t moved my planning conversations to open-source models, nor do I start a fresh Pi session without initial work in Codex or Claude Code. I’m being conservative about open-source models despite the benchmarks and the claims. A few months from now I may change my stance. For now I’d rather be safe than sorry.