My Thoughts on AI the Week of May 25
The AI product climate this week was weirdly clarifying. I am still not ready to move my development workflow back to Gemini after the rate-limit frustration, but I also have to admit that Google shipped a few things that made me pay attention again.
At the same time, OpenAI reminded me that even the best developer tooling can feel unnecessarily confusing when the billing model sprawls across too many surfaces. Then OpenRouter raised a serious round of funding and made the case for a future where developers do not have to bet everything on one model vendor.
That is the pattern I keep coming back to: the tools are getting better, but the surrounding product experience still matters just as much as the model.
Gemini Is Back in My General-Purpose Rotation
I have complained plenty about Gemini rate limits. The stricter enforcement hit the wrong nerve for me because it made the product feel unpredictable at exactly the moment I wanted to rely on it more. Once a tool makes me ration my thinking, I start looking for a different tool.
That is a big reason I moved my development work to Codex. For coding, I want a tool that can stay with the repo, preserve the thread of the work, and keep going through implementation and validation. Gemini no longer owns that lane for me.
But credit where it is due: the new Flash model feels much better than I expected. Google says Gemini 3.5 Flash is now the default model in the Gemini app and AI Mode in Search, and it is clearly aiming for the everyday assistant lane rather than only the coding assistant lane.
Daily Brief is the more interesting shift for me. The feature points Gemini toward the role I actually want it to play now: less pair programmer, more morning context engine. I do not need every AI tool to be my IDE co-pilot. Some of them are more useful when they help me understand the day, triage the noise, and surface what is worth paying attention to.
So Gemini is not out. It is just moving to a different job in my stack.
OpenAI Billing Still Feels Too Fragmented
OpenAI has become the center of gravity for my development workflow, but the billing experience still feels harder than it needs to be.
Part of the confusion is structural. OpenAI documents ChatGPT and the API platform as separate billing systems, and the API is billed separately from ChatGPT subscriptions. That may make perfect sense from an internal product architecture point of view. From a customer point of view, it can feel like three different doors into the same building, each with its own card on file.
That is where my frustration comes from. I have a monthly subscription for the tools I use directly. Then there is API billing, which is a separate developer platform. Then there are pay-as-you-go and authorization flows that can look like new charges if you are not reading the fine print closely enough.
OpenAI's help docs do explain pieces of this: API billing is separate from ChatGPT plans, API usage can be managed through the platform billing page, and a temporary card authorization can appear when adding an API payment method. The problem is that customers should not have to assemble the mental model from several help articles after a charge shows up.
My recommendation is boring, which is usually a good sign: fold the product billing experience into one clear account view. Show ChatGPT subscriptions, API usage, pay-as-you-go setup, authorizations, limits, and receipts in one place. Let customers drill into details, but do not make them guess which product surface generated which charge.
This is not just a billing complaint. It is a trust issue. If I cannot quickly understand what I am paying for, the product starts to feel more expensive than the line item says.
Codex Remote Connections Have the Promise and the Friction
Codex is still where I want to do development work. It fits the way I think about software: read the repo, make a focused change, run the checks, explain the proof.
The remote connection story is promising, but it still feels like a developing feature. When a session loses connection or hides too much of the build context, the user has to reconstruct where the work actually is. That is the exact kind of friction an agentic coding tool should remove.
The core product direction is right. The missing piece is continuity. I want the remote environment to make the development cycle more legible, not less: current branch, current diff, running commands, failed checks, last successful proof, and what remains. When that context is visible, the user can supervise the work instead of babysitting the connection.
That is the difference between an impressive demo and a tool I trust in a real project.
OpenRouter Looks More Important Than Ever
OpenRouter's latest funding round caught my attention because it validates a pattern I already like: one API surface, many model choices, and the ability to route work based on cost, quality, latency, or availability.
The company announced a $113 million Series B led by CapitalG, with a long list of infrastructure and enterprise investors. OpenRouter also said its weekly volume grew from 5 trillion to 25 trillion tokens over the last six months. Those numbers matter less to me as bragging rights and more as a signal that multi-model infrastructure is becoming a serious layer in the stack.
I used OpenRouter while testing Zone 2 Trainer, and the appeal was immediate. Instead of wiring every provider separately, you get a standard API shape and a lot more flexibility. That does not remove the need to understand model differences, but it lowers the switching cost.
That flexibility is going to matter more as model providers keep changing prices, limits, product names, and access tiers. If the frontier keeps moving this fast, the winning developer experience may be less about picking the one perfect model and more about keeping optionality.
Where I Landed This Week
This week did not make me less committed to Codex for development. If anything, it clarified why I moved there.
But it did make me less dismissive of Gemini. Flash and Daily Brief make Gemini feel useful again as a daily assistant, even if I do not want it driving my repos. It also made me more convinced that OpenAI needs to simplify its billing story before the confusion becomes part of the brand. And OpenRouter continues to look like one of the more practical bets in AI infrastructure.
So my stack is settling into something more nuanced:
- Codex for development.
- Gemini for daily context and general-purpose assistance.
- OpenAI API when I need direct product integration.
- OpenRouter when flexibility and model choice matter.
That feels healthier than trying to make one AI product do every job. The more these tools mature, the more I want each one to be clear about what it is best at.
Comments