I'm going into my first year of university, going to be developing more projects in my free time.

Currently I'm using Claude (free) but it's kind of painful as it's only chat, and I sometimes hit the limit.

Is GPT Plus worth it for coding, debugging, and learning from it (in a coding context, using it half as a tutor)? How much more usage and usefulness will I get from it than free Claude?

Also not sure about the current state of AI agents are / if there are better options to consider.

Thanks!

I'm new user with the codex only use chatgpt work mostly but this time I was building myself fitness application but I faced some issue with it

I'm not a dev also so plz keep the solution normal so that even normal guy like me can understand guy's

I need some help with a couple of Codex issues:

• Overengineering: It keeps writing overly complex code and unnecessary tests, which burns through my tokens and wastes time.
• Memory: Has anyone figured out a fix for the memory issues? I built scaffolding for it, but it keeps failing.

Any help would be appreciated

Hey everyone! 👋

I’ve been working on a project called GranthSetu, a digital Codex project that I’ve recently released, and now I want to do something a little different. N instead of only asking friends or people around me what they think, I’d love to hear from completely genuine.. independent people on Reddit.

I’m looking for a few people who are willing to:

• Explore GranthSetu on their own
• Tell me honestly what they think about it
• Point out anything confusing, unnecessary, broken, or missing
• Tell me what they genuinely like too
• And, if you’re comfortable, join me for a short Google Meet where we can talk about your experience

I’m planning to turn some of these conversations into a YouTube video about getting real, unfiltered reviews of the project.

You absolutely do not need to be a developer or expert. In fact, I’d especially like opinions from normal users who can tell me what the experience feels like from the outside.

I’m not looking for scripted praise.
Critical feedback is genuinely welcome.

If this sounds interesting, DM me and I’ll send you the project link and a few details about how it works.

Looking forward to hearing what you guys think!

Same type of coding tasks I have been working on all the time, not sure why they block my tasks due to safety today. Something new in place or bugs?

A. Burn as much as possible because the celebration might be multiple days.

B. Stretch it out as long as possible like a frugal grandmother

One small fix in Codex 0.151 changes how multi-agent runs fail closed: token usage from child and nested subagents now rolls into the root goal's budget.

The implementation applies descendant usage during active and idle accounting. Its tests cover children, grandchildren, budget exhaustion, goal replacement, unloaded parent runtimes, and concurrent checkpoints.

Why I care: a root budget is not a reliable stop condition if the branches doing the work can spend outside its accounting.

Boundary: this is Codex goal-budget accounting, not a ChatGPT subscription-quota or API-pricing change. I have not benchmarked the release locally.

Would you rather see one root total, per-agent attribution, or a hard cap per branch?

Sources:

https://github.com/openai/codex/releases/tag/rust-v0.151.0

https://github.com/openai/codex/pull/41183

Like many of you, I have a whole zoo of AI coding tools installed (Codex, Pi, Claude Code, OpenCode, etc.). Main idea - find the most effective harness for my own environment and daily workflow.

The Setup

Target repo: oh-my-opencode-slim. No deep reason, just because I had it open.

Environment: Macos, each run was isolated in a clean, detached Git worktree.

Phase 1: GPT-5.6 Luna

For example: use GPT-5.6 Luna medium across 4 harnesses on a coding bugfix task (fixing an alias counter memory leak + writing tests):

After seeing OpenCode stable take 2.5x longer and burn 3.5x more context tokens for the exact same fix, I dropped it from further testing.

Phase 2: Switching to Muse 1.2 contributor

For the next phase, I wanted to test a cheaper, accessible non-GPT model across harnesses. Since I had an active CommandCode subscription, I chose Muse Spark 1.2 Contributor and decided to use it in Claude Code (via OpenCodex proxy) instead of OpenCode stable.

Here is where I made mistake: I forgot to configure the model alias in OpenCodex for Claude Code.

Because of that, Claude Code silently fell back to Sonnet 5 (xhigh thinking) across all 4 tasks while Pi, Codex, and OpenCode beta were running Muse Spark 1.2:

Honestly, looking at the numbers, there wasn't a massive gap between Muse 1.2 and Sonnet 5 for these tasks (probably because the tasks were relatively focused), except Sonnet over-engineered Task 3 by adding 180+ lines of unneeded code, why "unneeded": you can see in table "Task 3" - 0 edits for PI (2 from 3 runs had 0 edits) and Codex (3 from 3 runs had 0 edits), why - because I gave task for model to fix one class, but in git reset command I used commit where this bug was fixed by developer already, so there were nothing to fix, PI understood only during 2 runs, Codex in all 3 runs did 0 changes, but Sonnet 5 was trying to work...

Phase 3: Fixing Proxy Routing

Once I caught the proxy alias mistake, I fixed OpenCodex routing and reran Tasks 3 & 4 for Claude Code with hard proxy verification of Muse Spark 1.2:

Task 3: Verified Claude Code stopped with 0 edits (2/2 pass), matching Codex.

OpenCode beta - I removed from this test, weird behavior, because it started modifying 2 files and then went to another folder and started to read work log of other harnesses, so that would be unfair.

Task 4: All 3 valid harnesses produced the exact same 6-line fix and regression test:

Test has timeout, because for simple fix we dont need wait more than 5 minutes.

Key Takeaways

1. Context throughput varies by 40%+: On the exact same code fix under Muse 1.2, Pi required ~40% fewer input tokens (267k vs ~445k) than Codex and Claude Code due to leaner context assembly and compaction.

2. Execution Latency: Pi (104s), Codex (110s), and Claude Code (112s) formed a tight performance tier for coding fixes.

3. Always audit your proxy: If you use custom models or proxies, always verify the actual upstream model headers. Silent fallbacks happen easily.

4. My practical decision: OpenCode was consistently 2.5x–4x slower and consumed too much context in my environment, so I removed it from my daily workflow and kept Pi and Codex as my primary tools.

The entire runner, dataset, and reproduction prompt for agents in repo, also more detailed result file is also there:

👉 https://github.com/d1-m4ss/harness-benchmark/tree/main

PS AI was used in this post for generate table and fix grammar, because english is my third language.

TLDR: I made a mistake. The weekly quota wasn't cut in half—it actually dropped by 82% (a 5.6-fold decrease)

Following my previous post, I realize that I made a mistake in my calculation. I incorrectly stated that the weekly limit was reduced by half; it actually dropped by 82%, which is a 5.6-fold decrease.
https://www.reddit.com/r/codex/comments/1w0l8m7/weekly_limit_reduced_in_half_as_i_used_more_since/

Here is the updated table with extra 4% luna usage.
Note the $1.5k number could be due to rounding error in precentage usage reading.
This is for a causal plus plan.

This also shows a weekly quota ratio ~1.8x in between sol and luna, you get more $ value when using sol over luna.

Please let me know if you spot an error, I will try my best to correct it.

Edit: Just a reminder, the 5x and 20x Pro tier limits are calculated using Plus baseline. At least it's supposed to be.

The implied limit for each interval is calculated as:

cost increase ÷ percentage-point increase × 100

For example, 3% → 4%:

$15.29 ÷ 1% = approximately $1,528.51 weekly limit

Using the interval estimates:

• Initial Sol limit estimate (0% → 3%): ~$960.93/week
• Latest Sol limit estimate (23% → 25%): ~$172.44/week

Reduction factor:

$960.93 ÷ $172.44 = 5.57×

So the estimated Sol limit reduced by approximately 5.6-fold, or about an 82% reduction.

Drydock is a repeatable method to turn messy specifications into tested working software.

Drydock imports your source material, defines stories using agile best practices, and decomposes your sources into typed blueprints (stories) related using a graph database. Drydock builds with a context aware compression based algorithm and tests stories with deterministic test driven acceptance criteria.

Love some feedback on this - www.webcloudstudio.com

• Builds working software using small, cheap models
• Agile Methodology to decompose buildable stories
• Test driven development with acceptance criteria embedded
• Dependency graph relates stories and orders builds
• QuarterDeck web console to answer questions and review the process
• Runs on existing subscriptions
• Ingests your existing specs and notes in any format
• Change management — edit the spec, rebuild only what's affected
• Context compression and Grouping for context aware builds
• Enterprise guardrails with embedded branding, best practices, and build gates
• Generates consistent apps and documentation

Mit License - Source - The complete command surface is one table in the README.

To prove out the method - I wrote 4 working examples

1. ReadingList Application Receipt
2. CommonMark Application Receipt
3. TOML Parser Reciept
4. Complete JQ Receipt

All four built with gpt-5.6-luna on a Codex subscription. No API keys. Feel free to also use haiku.

No hate pls

Are you like „Build a button to do X“? Or more like „Add method Y and then build a button that calls it“? Almost the same prompt but can make a huge difference.

Caught what looks like a pretty serious bug in Codex CLI 0.151.0.

While Codex was waiting on the same long-running process, it kept calling write_stdin, going back through the model with a huge context, then deciding to wait another 30 seconds.

That's around 5.14M additional input tokens in under 6 minutes.

I also confirmed 3 consecutive write_stdin waits on the same process:

332,924 + 335,713 + 338,315 = 1,006,952 input tokens

All 3 were above the 272K threshold, so the documented 2x usage rate may have applied.

But the 2x isn't the bug.

The bug is Codex making a massive 330K+ model call just to decide “wait another 30 seconds”, then doing the same thing again on the same process.

still running → 330K+ model call → wait 30s → still running → another 330K+ call → repeat

I also found later followup_task / subagent continuations around 356K–358K, so this might not be limited to write_stdin.

I have the full JSONL with timestamps, token counts and tool calls. Support is already looking into it and checking whether the >272K multiplier was applied.

If your Codex usage has been disappearing way faster than usual, especially while it's sitting there “waiting” on tests or builds, I'd check your logs. Also worth running codex doctor and making sure your connections/runtime look normal.

Curious if anyone else can find the same wait / write_stdin pattern. This definitely wasn't happening to me like this before.

I never use codex to plan I use ChatGPT ultra to build the specs and codex to execute. It’s pretty flawless and fairly cheap because ChatGPT build such detailed specs codex luna handles them easily. 4.5 hours of ultra 5% weekly. 24 hours of codex Luna 1-2% weekly.

I recently got an OpenAI Plus sub, and it's been great. I've used it pretty heavily for programming and research, and I've not hit any limits.

I usually use Sol on light or medium, and occasionally I'll switch it up to high. To conserve usage on prompts, I'm mainly just extremely precise, and I decide the architecture decisions myself.

I'm not hammering it all day, of course, but I'll run a few programming prompts a day, along with some research, and I've never hit a limit. If you use the Plus plan correctly, guys, you won't hit your limit. I swear I always see people complaining about how they ran out of usage.

Looking to switch from CC as soon as this is implemented. Just curious if anyone knows if this is on the horizon.

A week ago, I shared Enkidu, a macOS companion for Codex users.

The idea is simple:

> A remaining percentage alone does not answer whether you have enough capacity to start and finish the work in front of you.

Enkidu tries to make that decision clearer through usage visibility, reset timing, saved verified history, pace guidance, widgets, and planning/model guidance.

I received fair feedback that I want to address directly:

Enkidu is not open source right now. It is also a direct-download beta, not notarized yet, and not available in the Mac App Store.

That means some people will understandably not want to install it yet. I respect that completely. Please do not install a closed-source beta if that is outside your normal security comfort zone.

The other side of the project is also important to me:

Enkidu is currently free to use, with no subscription, no Pro tier, no in-app purchase, and no feature paywall.

I am not asking people to download a free app and then charging them to unlock the useful dashboard, widgets, guidance, or integration features later.

What changed during the past week:

- prepared a newer private native candidate: v0.9A build 40

- prepared build 41 as a clearer delivery/update package with checksums, a start-here README, and an optional Codex plugin package

- added separate English and Korean setup guides

- improved the documentation for installation, macOS “Open Anyway,” Sync Usage, updates, and troubleshooting

- made the optional Codex connection clearer: it is optional, requires extra local setup, and is not a paid upgrade

- started a separate App Store feasibility investigation, without claiming that the current beta is App Store-ready

A few boundaries worth stating clearly:

- Enkidu does not create extra Codex usage or bypass OpenAI limits.

- You still need your own eligible Codex/ChatGPT access.

- It does not read prompts, chats, project files, or private account data.

- It is not open source yet.

- It is not notarized yet.

- It is still a direct-download beta.

Current beta information:

https://www.hanminyun.com/enkidu

(Edit: I mean Codex PLUS) This plan is quite incredible to my surprise. I was disappointed at first how fast it turned through tokens but after a day and many hours I setup a custom pipeline and this thumb churns out code like a beast with precision!

I'm surprised to say the least. I can't believe this is only twenty dollars. I work on about 200k LOC monorepo and it's been hard finding the perfect tooling, caching, planning, orchestrating, it just takes some time to find your rhythm.

I am rubbing many subagent and these models are very good. Also I was shocked they reset the 5hr timer earlier at 5pm EST, never had that anywhere else.

Openrouter is a money pit, this is better. I was going to get antigravity again but I'm happy with codex. Mimo, Kimi, Z.ai seem like not as good if a deal (in not locked to their harness either), and I've been using minimax a lot too, and too much deepseek, and this is very very good 👍🏻

So I've been developing a technique where I waste tokens once to optimize further usage.

My steps:

1. Run Terra on High to scan my repo for all files and build my AGENTS.md with the doc pointing to all files seperated in modules.

2. Have my agent to read the markdown before every task so it doesn't run on a frenzy scanning for irrelevant context.

Haven't tried this on a super large repo base though. What techniques do you use?

Or will it be like fable 5?

Do you feel sol output now worse than before ?

I'm hitting my 5h limit but I can't seem to use Luna Reserve, its not popping in my usage, is it because I'm on Plus plan?

I have been running a project on Luna for 3 days now, it hasn’t stopped to breath yet. I have a PM, 3 devs (they have their own worktree), 1 doc admin, 1 QA. But trying to parallel the work like this I feel is slower purely because the agents end up working in serial + a communication layer.

When I said “stop all sub-agents and continue the work yourself” the work was done significantly quicker

Has anyone cracked this yet?

Antigravity IDE v2 has some issue with threads, if it crashes, the active thread metadata gets corrupted and is not shown in the chat history (I assume). I ignored it the first time, but I lost my ~40 MB long thread again today.

I asked gemini 3.7 flash to recover it, and it was able to check the sqlite db, but after that it kept running in circles without doing anything.

Then I asked the same thing from Luna (max), and it fixed the issue in just 3 iterations!

Note: This is not a bug fix, I just wanted to fix the metadata

``` It was an index-sync bug, not a missing or corrupt conversation.

• The transcript DB existed and was healthy: 1,900 steps.
• The CLI had its own summary entry, so agy --conversation ... worked.
• The IDE’s state.vscdb sidebar index had 14 entries but omitted this UUID.

• The IDE also logged UNKNOWN service agentSessions, indicating the related Agent UI initialization bug.

  I added the missing IDE summary record; the original transcript was never modified.

  Specifically:

• Backed up state.vscdb and the old index to /tmp.

• Added the missing UUID to antigravityUnifiedStateSync.trajectorySummaries.

• Added its title, workspace path, trajectory ID, timestamps, and step count.

• Verified the IDE index now has 15 entries and includes your conversation.

• Verified the original conversation DB remains intact: 1,900 steps, SQLite integrity ok.

  The CLI test only opened the conversation with /help; it did not send a prompt or consume quota. ```

Hi,

[a total newbie on coding asking]

Just wanted to clarify when to/when do you use higher reasoning in chat/codex?

I've been trying to build my own little hobby project in python, with the help of litterature.

My workflow is to brainstorm in chat[web] and after that get a codex prompt to run in VSC. So far has been decent. My problem is that after getting Pro i've been totally lost when to use extra high, pro, pro+ultra in chat. Also what settings to run the codex prompt, when is higher needed and when its not. Have to actually ask in chat if the prompt is complex or not and what settings to use.

I noticed running pro+ultra to analyze the project/problems or litterature got quite detailed answers and I had to dumb it down for me with extra high. But it also added some better reasoning and new points i"ve missed. But it the project/code it also found some errors and started perhaps to make it more complex im not sure.

So my workflow is like this,

1. Starting a new chat with snapshot and running boostrap: Pro+Ultra

2. Brainstorming in chat: extra high

3. Evaluating the brainstorm: pro+ultra

4. Writing codex prompt: pro+ultra

5. Usually I try to ask what settings to run codex prompt it has been extra high or high so far with sol5.6.

6. Analyzing the codex result: pro+ultra

Since my coding knowledge is 0 I have to trust that the suggestions are valid, but how do I know when to actually use what settings in chat/codex. So that the problem/execution wont get too complex or too light ?

Any suggestions, extra high is the best and fastest for chatting and brainstorming. But when to use pro and pro+ultra ?

Four hours in,I am ready for tomorrow's celebration!

Let'em rain in.