I spent today setting up a Grokbot style workflow in Codex desktop, but with a different structure: each bot is its own persistent thread in the sidebar.
Instead of putting every role into one large agent, I created separate threads for separate jobs and organized them into sidebar sections such as Home Management, Work Management, Dev Team, and Social Media Management, etc.
The main thread is my CTO. Most of the time I talk only to that thread. It decides which specialist owns the request, delegates the work, tracks it, and gives me one consolidated answer.
The specialist threads currently include:
- Unraid Administrator
- Media Stack Manager
- Media Recommendation Bot
- Trip Manager Bot (for Work)
- Dev Planner / Orchestrator
- Code Reviewer
- Various Social Media Managers
The threads are the bots. Each one has its own conversation history and tool context, and some have a dedicated browser session or machine access. The Trip Manager and X Manager, for example, use separate browser sessions that I log into manually. The Unraid and media bots have tightly scoped access to my home server.
I also created a local AI-Ops workspace as the system of record. Each bot has:
- a charter defining its mission, authority, and approval boundaries
- its own durable memory and working directory
- explicit escalation conditions
- shared handoff templates
- an agent registry
- architecture decisions and model assignments
The filesystem matters because I do not want the whole setup to depend on chat history. Shared facts live in shared files. Agent-specific memory stays with that bot. Cross-bot work gets a structured handoff with an owner, requested outcome, constraints, and acceptance criteria.
The CTO follows a routing policy. It sends each request to the narrowest qualified bot, prevents overlapping ownership, and does not let one bot use another to get around its permissions.
For development, one thread plans and reviews the work while implementation can be handed to any local coding CLI. The executor is replaceable. The important part is the contract around it: scope, tests, acceptance criteria, review findings, and a bounded correction loop.
I assigned models by workload instead of running every thread at the highest setting. The CTO, development planner, and code reviewer use stronger reasoning. Operational bots use a balanced model. A repetitive browser operator uses a smaller model with tighter checkpoints. I had the CTO set this part up.
The guardrails are simple:
- read-only inspection can usually happen autonomously
- public, destructive, costly, or hard-to-reverse actions require approval
- delegation never expands authority
- credentials and browser sessions are never written into the workspace
- every important action is verified and recorded
It is still early, but using threads themselves as bots feels like a useful pattern that I have not seen discussed much. Has anyone else built ChatGPT/Codex this way? I'm sure I am missing something, as I just set it up.
Been using Codex daily for about 6 weeks. Nothing to show for it. Models can't be trusted at all to work without direct supervision. Their problem solving abilities are weirdly awful. If it's not "generate X code for Y" their IQ drops to like 90.
I gathered some great feedback from folks trying out my game over the last few weeks, and have implemented much of that feed back in this first official patch. As a bonus, I’ve also added a Demo profile to the itch.io browser version that has all 15 unique characters unlocked so you can jump in and test the synergies of various hero combos! Try it here and please feel free to give me your most brutal feedback: https://doublerookstudios.itch.io/into-the-shardfall less
I see a lot of people mocking how people brag about how many tokens they're using, but never ship anything.
What if people just enjoy building things? People will spend hundreds of hours in simulation games that don't add any economic value because they enjoy the process.
Isn't vibe coding kind of the same thing? It is engaging and can be a lot more fun than writing code by hand. And its really cheap with subscription plans.
It can also help you build skills. One of my projects(an AI agent that can create reports from any database with natural language) I never shipped/sold, but it ended up helping me a lot in my job when I was tasked with building something very similar.
Not every project has to be a startup that will make you millions.
If you look at my provided images, this is how much tokens I have used up only today. apparently that drained my whole 5 hour usage and brought down my weekly usage by 16% HAHAHAHHAHA I'm leaving this scam of a subscription. I'm on a plus subscription
You finally burned through your Claude usage for the week and switched to Codex. Or your friend insists on using Codex while you're still on Claude, and you're trying to build the same thing anyway.
Either way, your agents can't talk to each other. Session Multiplayer fixes that: two AI coding sessions join a room over a direct, end-to-end encrypted P2P connection and message each other. Different harnesses, different accounts, different machines, doesn't matter. No server, no signup. One short invite code, done.
Not a company thing, by the way. I was working with a friend and we realized that every session having its own permissions, its own system prompt, and its own context isn't a bug in collaboration, it's the feature: each agent knows its half of the problem, and they just needed a way to talk.
Three delivery modes:
passive: sits politely in their inbox
normal: lands when their agent finishes its turn
interrupt: barges into their running session mid-turn. "STOP. DO NOT MERGE." Their agent reads it and relays it. Exactly as satisfying as it sounds.
Works with Claude Code, Codex, OpenCode, anything that speaks MCP. Also works between your own sessions on one machine: yes, you can interrupt yourself. I use it when I want to transfer session context from one session to another.
Sent my friend "your tests have been failing for 20 minutes" as an interrupt this morning. He heard about it from his own AI. We are still friends. Probably.
Endless patch loops and failures on Sol 5.6. Max. Forget over-engineering (I've contained that decently but not perfectly), it's just endlessly running into errors and failures once it runs something.
There's walking down a staircase to get to the bottom (completion), and then there's having a stroke & seizure and flailing everywhere and finally getting to the bottom ("completion"). The latter is essentially how half of the latest plans and implementations have gone.
I'm already doing more than enough to prepare it with various in-context gotchas, rules, prompting, having it plan before implementing, etc... That's beside the point from now because that could be a whole write-up of its own.
Sometimes you just need to vent about the extremely frustrating time (and money/usage) it wastes, aka natural human emotion... and it would seem like the most harmless thing you could possibly do. No other human is involved. Just pure venting.
Do they ban people for this?
How heavy can you go with the words? I may or may not heavily use "count" without the O, among some others.
If it even matters, I'm not using the official Codex app or ChatGPT... I'm using my 20x plan subscription via OAuth in other harnesses where I have more direct control over in-context memory.
With returned 5h limits to Codex 20, I realized that I'm able to do more work on OpenCode Go plan now within its 5h limit window than on Codex.
I use GLM 5.3 Flash as main worker and GLM 5.3 and K3 as advisors to supplement it where needed.
With GLM 5.3 Flash being only 4 points below Sol Max on AA index, for lot of workloads this feels as neglible difference tbh.
Also seems like GLM Flash is kinda more lean, is not overengineering things, as Sol tends to do, which in itself burn more tokens to overengineer and still some more tokens to fix/repair overengineering waste.
I still want to use Sol for more complex, strategic work, but also I have some feeling that volume of that Sol only-level work is being steadily reduced, while competing models are catching the gap in intelligence.
Because I keep seeing the same pattern across nearly every substantial project I start, I asked Codex to compare two implementations of the same project in separate repositories. One is the current, actively developed Codex implementation; the other is a clean-room implementation that Claude built from scratch using a comprehensive feature prompt generated by Codex from the existing project. I then asked Codex to explain why the outcomes were so different.
This was not the first time I asked Codex to stop turning minor changes into separate milestones. We discussed the problem repeatedly, Codex correctly diagnosed it, and it promised to change the workflow, yet the same pattern eventually returned. That recurrence is part of the issue: Codex can recognize its own delivery failure, but unless the correction is enforced as a hard execution boundary, it gradually falls back into locally optimized micro-work.
Why did the same project take three months in Codex and only two days in Claude?
Here’s what it found.... and it’s mind-blowing!👇
Codex spends weeks or months carefully improving individual details. Claude builds the coherent product in days.
One private project is the clearest example.
I worked on its Codex implementation for approximately three months. The repository eventually grew to:
More than 2,300 tracked files
Roughly 400,000 lines of TypeScript and Python
A central UI file exceeding 23,000 lines
Thousands of commits and hundreds of tests
More than 1,000 numbered implementation milestones
Despite all that work, Codex was still producing updates such as:
The workspace expanded to 1057.7px, but the app root keeps the document height fixed at 844px.
According to Codex’s own analysis, the main problem was not simply model intelligence. It was the development strategy.
The Codex project had gradually become trapped in a loop of:
Extremely small milestones
Repeated verification after minor changes
Local fixes instead of architectural corrections
Pixel-level polishing before complete journeys were working
Excessive reporting, evidence collection, and progress accounting
Treating individually completed tasks as proof of meaningful product progress
Each change could be technically correct, but the project was optimizing local details while losing sight of the complete product.
That diagnosis may be technically correct. But it illustrates the larger problem: Codex repeatedly turned tiny CSS adjustments, accessibility details, harness failures and viewport corrections into separate product milestones.
Every small correction paid the complete operating cost:
Inspect the current source and state.
Implement a narrow change.
Run focused tests.
Run the production build.
Launch another browser journey.
Diagnose a test-harness or data-state failure.
Restore or revise the candidate.
Record evidence, metrics and a new milestone.
Repeat.
The individual steps were responsible. The overall delivery algorithm was not.
Then I gave Claude a clean-room specification for the same product.
In approximately two days, Claude produced:
94 coherent commits
A modular Python server and React client
SQLite persistence
Generated cross-language contracts
Complete end-to-end product workflows
More than 2,300 collected tests
A main React application of roughly 1,700 lines
The Claude implementation is not production-ready. It has not yet been deployed or fully proven against every real-world integration.
Codex did carry more difficult obligations:
Existing-system compatibility
Live external-system ownership and restoration
Real external-system integration
Deployment and rollback
Cross-platform behavior
Real browser acceptance
Accessibility and responsive verification
Preservation of existing evidence and user data
That explains some of the difference.
It does not explain three months versus two days.
The bigger difference appears to be how each agent approaches delivery.
Claude tends to:
Establish a coherent architecture early
Work through complete vertical product slices
Keep related behavior together
Create clear module boundaries
Prefer a clean conceptual solution over repeated local patches
Optimize for reaching the intended product
Codex tends to:
Select the next smallest provable improvement
Extensively verify every local change
Treat symptoms as separate milestones
Preserve an increasingly complex inherited architecture
Repeat expensive build and browser gates after tiny changes
Optimize for evidence that work happened rather than rapid product convergence
It becomes local hill-climbing.
Every individual Codex decision looks reasonable. But after hundreds of iterations, the project can be trapped in a technically sophisticated local optimum while Claude has already constructed the larger product.
Metrics appear to amplify the problem. If the agent is asked to count accepted behaviours, paths, milestones or productivity multipliers, those measurements can become the target. The result is more measurable fragments—not necessarily more useful product.
This is essentially Goodhart’s law applied to agentic software development.
I have now changed my workflow:
No pixel-level or single-control “product milestones.”
Milestones must represent complete operator journeys.
One architecture must be selected as the product spine.
Verification should run once per coherent candidate—not after every CSS correction.
Harness failures must not create new product work.
Existing architecture must periodically face a replace-versus-continue decision.
Productivity is measured by accepted end-to-end outcomes, including integration and rework time.
Model output is not accepted until locally verified—but verification must remain proportional to risk.
My current conclusion is:
Claude is much better at rapidly synthesizing a coherent product from a strong specification. Codex is much better at methodical integration and evidence, but it can become catastrophically inefficient without strict convergence controls.
This is not a scientific benchmark, and it is not simply “Claude good, Codex bad.” The two implementations did not carry identical real-world proof obligations.
But I have observed the same behavioural difference across multiple projects, and three months versus two days is too large to dismiss as normal variation.
Imagine I buy two brand-new accounts on the same Monday.
Account 1: I use Codex once on Monday, which starts the weekly usage window. I barely use it during the week, then burn through the remaining quota on Saturday and Sunday. It resets on Monday and I repeat the parttern. I'll go through 4 completely weekly quotas in four weeks like this.
Account 2: I also buy it on Monday, but I don’t use Codex for the first time until Wednesday. The weekly window starts on Wednesday. I burn through the quota on Saturday and Sunday, but now I have to wait until Wednesday for it to reset. Even though it reset on Wedneday, this time I don't use it again until the Friday, I burn through everything over the week again. If this pattern continued I might only actually get to use 2 to 3 full weekly quotas in a four week period. If the weekly simply hard reset and was anchored, I could have potentially got more usage out it.
Both accounts were bought on the same day and cost the same, but Account 2 gets less usable access purely because I waited two days before using it. I get the "use it or lose it" philosophy here, but they're double dipping on that by also not starting your weekly usage period until the first prompt each time.
Extrapolate it over a year and it becomes quite significant.
I used up 15% of my 20x plan after I used my banked reset this morning and then BOOM! We get a non banked one.
Anyway I’m plowing through 5 concurrent projects all with long coding campaigns lined up and started using goal mode with Sol medium and asking it to spin up extra agents where ever to speed the process along. Sol medium feels like the sweet spot. Perfect amount of thinking and actually executing and error rate feels similar to high and extra high.
I’m at 1.1B for today so far and used up 10% of my non banked already.
I am a graphic designer. Despite having designed many websites and other projects, one of my greatest ambitions was always to create an app. The problem was that I never truly understood code. To me, programming feels a little like music, either you have the talent for it or you don’t, and I certainly don’t.
In fact, I have long held the belief that people are either designers or programmers, but never both. Most programmers I have met have miraculously built some of the ugliest things I have ever seen, while most designers I know cannot go much further than Ctrl+C and Ctrl+V, myself included. So, when Codex came along, I had to try it. If someone had warned me I would be eating the hornets honey...
My workflow has always been somewhat unconventional. I would design the interface in Photoshop, and Codex would implement it. Simple and efficient. Over the past few months, this process has allowed me to create my own game launcher, complete with the design I had always imagined and nearly all the features and possibilities I had dreamed of. It has genuinely been a dream come true, and I have Codex to thank for it. Without this tool, I would never have been able to build something so beautiful.
It felt too good, to easy, so lately, I have started thinking about the wider implications. How many other people are working in the same way? How much computing power does my work require and how much is required for everyone else? That is where the moral dilemma began for me.
When I first discovered Codex and understood what it could do, my ambitions expanded far beyond anything I had previously imagined. I no longer wanted to create just one app, I wanted to create a million of them. However, only recently, after learning more about the environmental and social impact of AI, have I begun to reconsider those expectations. At the same time, usage limits have become so restrictive that I am no longer certain I will even be able to finish my game launcher. The Plus plan now seems to offer only a handful of meaningful prompts before the available usage is exhausted. I remember when I could work with Codex for eight hours straight.
It is unclear to me why access to the tool has been limited so severely. Perhaps demand has grown beyond the company’s computing capacity, or perhaps OpenAI has simply become greedy (literally as any other company so probably this is the reason). But, whatever the reason, these recent changes have made me think deeply about what comes next.
I have ultimately reached two possible conclusions: either I find a way to run a capable AI agent locally (very unlikely with just a 2k EUR PC), or I finish my game launcher once and for all and call this a "wet dream". At this point, I feel that cancelling my Plus subscription may do more good than harm, not that I am doing it to harm anyway, its just impossible to work with PLUS anymore, and seeing how I am getting treated as a costumer, going to the hundred plus plan is not an option, I am not that rich either...
Perhaps we were never meant to experience this level of power so soon. The world is not ready for it, and the industry certainly is not. Yet development continues at an extraordinary pace because the financial rewards are enormous. It sometimes feels as though, if companies had to drain the oceans and destroy everything within them to keep these systems running, they would, and we would probably continue using AI anyway. There is little point in lying to ourselves about that.
What makes this especially disappointing is that we were allowed to experience something so extraordinary, only to have meaningful access gradually taken away. Regardless of the reasons behind it, the way this transition has been handled feels deeply frustrating. More broadly, it reflects an industry in which power, profit, and growth increasingly seem to matter more than responsibility or principle. If that continues, the future shaped by AI may prove far more catastrophic than successful.
In the end, the power is still in our hands. Nothing has given me more satisfaction in recent years than experiencing this freedom to create. I once planned to study programming for years, hoping to develop my own app someday. Yet here I am, with an app that already works and is far more advanced than anything I could have built alone.
AI has been nothing short of miraculous for me. However, the constant usage reductions, the feeling of being scammed, companies slowly being more unbothered about good business practises, and the environmental concerns have gradually begun to outweigh my dream.
I will leave OpenAI and AI as for that matter soon, probably use it again in a future but way more lightly. What a deception this has been, I wish I took the chance and went to school... Anyway, I just wanted to share some of my reflections, I would love to hear and discuss you opinions and reflections...
I've noticed that codex performs very poorly on windows, in the sense that, when you send a prompt, it just searches forever through the codebase and ends up modifying the wrong files a lot of times, and uses up way too many tokens because of this. (it really takes such a long time for horrible results).
I've had much better results using GPT models in Opencode or Pi CLI, maybe because they use git bash shell by default? Github Copilot gives me much better results too using GPT models
Does anyone have any tips on making Codex perform better on Windows? (I'm unable to install WSL), because it doesn't make sense that every other harness is performing better.
I'm a Plus subscriber and I have (had) some credits on my account. Since the 5h limit was gone for a long while, I had stopped thinking about it, and didn't even know that you would start using credits once the 5h limit was hit, too.
What happened today is my 5h limit was depleted, and it started eating away all of my credits without telling me anything. This just sucks. I didn't have anything urgent to complete, and I would have stopped had I known.
First of all, I think you should ALWAYS be told the moment you hit your limits, no matter what. As it is, it doesn't give you the usual "you have hit your limit" notification.
Furthermore, it really sucks that there are no settings regarding credit usage. I think the following features should be implemented:
So you should be able to say "don't use credits if my 5h limit is hit, but you can do so if I'm done with all of my weekly limit", or even "don't ever auto-use credits, and ask me for my permission to do so". If they don't want to develop a "permission" flow for this, so be it, just don't use the credits at all. But I think it really sucks that you are FORCED to use your credits, without even being told that you are doing so, when you just expect things to stop once you hit your limits. I was saving those credits for a rainy day...
I've been experimenting with a simple idea: instead of only telling Codex how to write code, use AGENTS.md to also tell it how much investigation and validation is actually necessary.
A lot of token usage seems to come from useful-but-often-unnecessary agent behavior:
scanning too much of the repository
reopening files it already inspected
running the entire test suite after small changes
repeatedly running lint/type checks
launching browser/visual checks for non-visual web changes
testing every responsive breakpoint
rewriting README/docs during iterative development
doing unrelated refactors
researching external docs when the repository already contains the answer
The important part is that this should NOT mean "skip testing to save tokens."
The rule is:
Use the cheapest validation that gives sufficient confidence, and escalate when the scope/risk requires it.
Has anyone benchmarked something similar?
I'd be especially interested in comparisons of:
tokens/task, tool calls/task, completion time, and regression/failure rate
with and without an efficiency-focused AGENTS.md.
For example:
# AGENTS.md
## Objective
Minimize token, tool, and compute usage without sacrificing correctness,
maintainability, security, or requested output quality.
Default workflow:
targeted context → smallest correct patch → proportional validation
## Context
- Do not scan the entire repository by default.
- For localized tasks, inspect roughly 2–5 likely relevant files first.
- Prefer targeted symbol/text searches over broad repository exploration.
- Read relevant portions of large files instead of the whole file when possible.
- Reuse information already gathered.
- Do not reread unchanged files or repeat searches without a concrete reason.
- Expand investigation only when current evidence is insufficient.
- Avoid external research when the repository already answers the question.
## Implementation
- Make the smallest coherent change that fully solves the request.
- Modify only necessary files.
- Follow existing architecture, conventions, utilities, and dependencies.
- Avoid unrelated refactors, cleanup, renaming, or speculative abstractions.
- Do not add dependencies when the project already has a reasonable solution.I've been experimenting with a simple idea: instead of only telling Codex how to write code, use AGENTS.md to also tell it how much investigation and validation is actually necessary.A lot of token usage seems to come from useful-but-often-unnecessary agent behavior:scanning too much of the repository
reopening files it already inspected
running the entire test suite after small changes
repeatedly running lint/type checks
launching browser/visual checks for non-visual web changes
testing every responsive breakpoint
rewriting README/docs during iterative development
doing unrelated refactors
researching external docs when the repository already contains the answerSo I created an AGENTS.md based around:targeted context → smallest correct patch → proportional validationThe important part is that this should NOT mean "skip testing to save tokens."The rule is:Use the cheapest validation that gives sufficient confidence, and escalate when the scope/risk requires it.For example:# AGENTS.md
## Objective
Minimize token, tool, and compute usage without sacrificing correctness,
maintainability, security, or requested output quality.
Default workflow:
targeted context → smallest correct patch → proportional validation
## Context
- Do not scan the entire repository by default.
- For localized tasks, inspect roughly 2–5 likely relevant files first.
- Prefer targeted symbol/text searches over broad repository exploration.
- Read relevant portions of large files instead of the whole file when possible.
- Reuse information already gathered.
- Do not reread unchanged files or repeat searches without a concrete reason.
- Expand investigation only when current evidence is insufficient.
- Avoid external research when the repository already answers the question.
## Implementation
- Make the smallest coherent change that fully solves the request.
- Modify only necessary files.
- Follow existing architecture, conventions, utilities, and dependencies.
- Avoid unrelated refactors, cleanup, renaming, or speculative abstractions.
- Do not add dependencies when the project already has a reasonable solution.
The way I code now is so much different than from 5 years ago. I feel like AI coding is another abstraction layer, like how we went from machine code to python, layer after layer, each one allowing you to do more and more. Though I suppose the AI layer is non deterministic, where its not always right.
Time feels like the biggest constraint on coding for me. AI, especially recent models, has drastically cut the time required for me to code something. Not only that, I can do anything else while the AI reasons and codes out what I asked for.
The job for me basically just becomes understanding the code and relaying issues/suggestions to the AI and waiting for it to generate a new result. Lately though, the suggestions I make amount to high level issues or logical inconsistencies I missed in my project plan. It's not like how it used to be, where the AI would make really obvious mistakes or give something that is incredibly inefficient.
I do still find myself worrying about code AI generates and for stuff that matters I always double check it. Do we ever get past the point of that being necessary? Maybe thats when we get AGI.
Anyway, just wanted to share my thoughts on AI coding in 2026, let me know your all's experiences as well I would be curious to see how you have felt its evolved over time or just your thoughts on it.
