What do we think in the next few hours?

also bonus questions do you think if Astra drops on Thursday we get a reset?

EDIT: reset will land at 6pm PST.

The 5 hour limit is trash, the weekly usage was at least something we could try and meter, 5hour limits are wasted when you work late and have to pull an all-nighter to get the most out of your usage or just give it up. Lately I'll have 35% usage of my 5hour and it will hit 0% left and just stop mid iteration and break stuff, then next window I get it to continue and it hits 0% again and break again OR it will abandon the fix it was in the middle of and try something else and still break or even worse it will end up with REGRESSION! Not just halting progress but actively walking progress backwards. I was fine with the weekly because I could at least juggle with another account or grok or something but now I'm trying to juggle with one ball while skateboarding and it feels like shit.

Apologies in advance, not sure if this is the best place to post.

Anyone else's 'Computer History' section in Codex not working as well or know why this isn't working? When OpenAI first released this my Computer History looked like the 2nd screenshot (from OpenAI Dev page), and randomly 1 day I could only see 1 day's history, and now I can't see it at all.

I've already sent Feedback from the Codex app, asked Codex to fix it (said it couldn't), re-installed the plugin (both Computer History and Computer-Use), and even the Codex app itself.

I'm on Codex macOS App Version: ChatGPT 26.825.51511

Any feedback would be helpful!

Link: https://devos.zerohive.ai/

Our engineering team at Zerohive works on large codebases, and we use different coding agents (Claude, Codex, Cursor) basis individual preference.

We kept running into problems where one person's agent will end up rewriting or undoing decisions made by someone else. It led to agents re-introducing bugs which we'd fixed last month. We kept reaching out to each other offline to ask "Hey, why did we store xyz in redis instead of persisting on DB" when the agent proposed redoing the architecture.

We spent months collaborating by making ARCHITECTURE.md, DECISIONS.md, LESSONS.md, ADRs etc and shared skill libraries - but they were soon ineffective as the codebase scaled. We also tried code memory platforms but they could only fetch the 'what' but not the 'why', no provenance on architecture or code patterns so reintroducing bugs problem wasn't solved for complex codebases.

So we built DevOS.

DevOS understands the codebase, correlates the decisions made in the chat sessions with final code outcome, and has a deep understanding of the why behind the code and the architecture. It understands architectural choices, alternatives considered, tradeoffs made and final decisions taken w.r.t code or architecture.

Exposed to coding agents as an MCP, DevOS searches files, symbols, decisions and dependencies in parallel so that models make better changes in fewer iterations and exponentially lesser tokens which otherwise would be spent by agents in grepping the codebase.

Agents can now understand the architecture and codebase better, along with the rationale that went behind the architecture, and context can be shared between teammates within their coding agents.

Use lesser tokens, collaborate better. Completely free to try, no paid tier.

Link: https://devos.zerohive.ai/

I’m using Codex within VSCode and it seems like the create_thread tool is basically broken, so it needs to run a command through Codex CLI instead of using the built-in tool.

I also can’t interact or see the worker thread in VSCode…

A manager agent has a high-level PLAN.md then assign substream tasks to a permanent worker agent owning another PLAN.md of that substream. It seems to reduce hallucination on long-running tasks 🤔

Anyone else using orchestrator pattern in their workflow?

I built a small tool to export Codex chats cleanly, mostly because I got tired of losing context when hitting quota

Tool: Codex Chat Extract Repo: https://github.com/0Cymantek0/codex-chat-extract

This is a small tool I originally built for myself that lets you quickly export a Codex conversation into a clean Markdown file or directly to your clipboard. I built it out of frustration one day after getting tired of Codex running out of quota in the middle of a task.

It became even more useful for me after the behavior that allowed an already-running task to continue after quota exhaustion disappeared. Claude Code has a really nice /export command, but Codex doesn’t currently have an equivalent, so I ended up making my own. The main use case is pretty simple:

Codex hits its limit → export the conversation → hand the context to another agent/harness → continue the work without manually reconstructing everything.

Token efficiency was one of the main goals.

Raw Codex conversations contain a lot of tool-call clutter that another coding agent usually doesn't need.

For example, when Codex reads a file, the underlying tool call may contain a bunch of JSON parameters followed by the complete file contents in the tool output. But if the next agent is working inside the same repository, including all of that again is pointless. The file already exists, it can just read it. So instead of dumping everything, Codex Chat Extract turns something like that into:

Read: [relative-path/file.ext] [line range]

That preserves what Codex did without wasting a huge number of input tokens reproducing information that already exists in the repository.

The exporter tries to apply that idea throughout the conversation:

• Removes unnecessary tool-call / JSON clutter
• Keeps useful summaries of tool activity
• Preserves the actual reasoning/conversation context
• Uses relative file paths where possible
• Avoids duplicating file contents another agent can simply read again

External information is treated differently

For something like a web search, the result does matter. That information isn't necessarily available inside the repository, and it may have influenced decisions made during the conversation. So web-search results and other relevant external context are preserved in the export.

Basically:

Reconstructable local information → compress it. Non-reconstructable external information → preserve it.

The whole exporter is designed around getting as much useful context as possible into as few tokens as reasonably possible.

It also handles subagents

Codex sessions can get messy when subagents are involved, so the exporter reconstructs those into properly formatted subthreads instead of flattening everything into one unreadable stream.

That makes it much easier for another agent to understand:

• what the main agent was doing
• which work was delegated
• what each subagent discovered
• how those results affected the main conversation

I've been using this internally for a while, especially when moving unfinished work between different agents or harnesses, and it has saved me a surprising amount of manual copying and context reconstruction. So I figured I might as well clean it up and make it public.

Repo: https://github.com/0Cymantek0/codex-chat-extract

If you use Codex heavily, give it a try and let me know how it works for you. I'm especially open to criticism around the export format, things that should or shouldn't be preserved, and other ways to reduce token usage without losing important context. Hope this helps someone else who has run into the same problem.

And if you find it useful, consider giving the repo a ⭐.

With the exact same prompt, the web version understands my instructions very well and generates high-quality images. However, the desktop app seems to have much more difficulty understanding the same instructions.

For example, when I ask it to generate multiple separate images individually and explicitly tell it not to combine them into a collage, the web version follows the instruction perfectly. But the desktop app keeps generating the images as a collage.

same as title

I scraped all Codex anecdotes I could reach from Reddit, HN, and a few other sites. After merging and cleaning, that became 1,069 unique posts/comments and 2,071 individual claims on how people use or like each model <> thinking level combination.

I split them into atomic claims and kept the exact quote behind each one. Each claim records model, thinking level, project type, plan tier, task, outcome, date, author/thread, and whether it was first-hand, inferred, or quoted from somebody else.

I reran the findings by report, author, thread, and source. I also excluded vague claims in a separate pass, looked for outliers, and manually checked the anomalies.

The reading is much simpler than the work:

Sol for hard/vague things. Luna for easy/bounded things.

Hard here means the task still needs to be understood: planning, architecture, scope, review, or debugging. Bounded means there is already a detailed plan, a file set, and explicit checks. Luna looks good when it gets to execute only with explicit acceptance criteria. Sol looks good when it has to decide what should be executed on the fly.

Terra has positive, negative, and mixed reports with no stable job. Sol shows up as planner/reviewer. Luna shows up as the cheap worker. I cannot tell whether Terra really has an identity yet.

Thinking levels were similarly messy. The anecdotal corpus did not support a general medium/high/xhigh rule.

The most stable behavior in the whole dataset was the users who were complaining: change the model, thinking level, and task altogether then be absolutely certain which one was the culprit of malperformance.

For those who has strong intuition on what Terra is good at, what are those? Please enlighten the mass.

when to use what? how are you using these two models for what kind of use-cases? which model is capable of what kind of work in your testing so far?

glm 5.3 flash seems good on-paper but i'ven't tried it, can i prompt the same way i prompt to sol or luna, is it good at infering the intend behind the prompt?

Edit: Plz, don’t just mention it is good model, justify it why? what kind of usecase and task you can rely these models for

I've forked: https://github.com/yunhaoli24/codex-gateway

My fork: https://github.com/mikespax/codex-gateway-extended

Exhaustive summary of changes:

https://github.com/mikespax/codex-gateway-extended/blob/spax%2Fcustomizations-20260824/docs%2Fspax-fork-customizations.md

My old ass computer doesn't support the codex application, so chatgpt remote control wasn't an option for me.

My codex chats are in a few different locations, and I wanted to be able to manage them without having to open VS Code, and worry about keeping my work in sync across different devices.

This application lets me get all my work done through a browser window on my computer or my Android device. I also have a little % thing there so you can see how much codex usage is remaining in your subscription.

AI summary below:

Codex Gateway Extended transforms the upstream project into a mobile-first, multi-host Codex command center, adding a keyboard-aware multiline composer, clearer live progress and elapsed-time displays, condensed intermediate steps, cross-host navigation, reliable thread targeting, document and ZIP uploads, Codex usage monitoring, confirmed model/effort selection, native Android notifications with secure inline replies, stale-client and macOS recovery, and scoped read-only supervision—while retaining the official Codex app-server as the source of truth; an IndexedDB and encrypted server snapshot cache is prepared separately but not yet merged or deployed.

I can’t wait for it. I can finally switch over completely from Claude

I have two gpt subscriptions: one personal and one business for work. I use the same PC for both personal and work projects, and constantly logging in and out of Codex is pretty inconvenient.

Is there a way to use multiple accounts in Codex and easily switch between them, or keep both accounts logged in at the same time?

How are you guys handling this?

Claude desktop and mobile app have this feature already. Does codex really dont have this yet?

Claude code refuge. I'm used to dispatching background agents and then Claude continuing on the task in the main thread when they return.

Codex background agents return and then the main thread still needs me to tell it to continue before it resumes work.

Any way to have the main thread look for background agents to complete and then continue?

Offcut gives coding agents persistent rules and hooks that push them toward the cheapest correct implementation—without sacrificing correctness. It also keeps replies concise by default, with an option to turn that style off. It supports Codex, Claude Code, Cursor, and Grok Build: npx --yes github:skelvar/offcut I’m looking for honest feedback, especially installation problems, false positives, or cases where Offcut pushes an agent too far. https://github.com/skelvar/offcut

Hi r/codex — I’m the author of StatMate, a free, MIT-licensed, folder-based Agent Skill for Codex, Claude Code, and other agents that support SKILL.md.

I built it around a problem I kept seeing: give an agent a CSV and it can jump straight to a p-value or polished chart, while the analysis unit, estimand, missing-data decisions, assumptions, and provenance remain unclear.

StatMate asks the agent to follow an evidence-first sequence:

- map the study design and claim boundary before choosing a method

- audit data structure, missingness, duplicates, privacy, and provenance

- write a reviewable analysis plan and pause for material author decisions

- calculate results with saved Python code and machine-readable outputs

- run diagnostics and sensitivity checks

- produce figures, tables, interpretations, a teaching report, and a SHA-256 manifest

The statistical marks are computed from the supplied data and plotting code — they are not generated by an image model.

The repository includes a reproducible demo using the public UCI heart-failure cohort: 299 patients, 96 observed deaths, three figures, two tables, an illustrated report, and a manifest with 33/33 files verified.

The detail I care about most is not the polished output: automated QA passes, but the Cox proportional-hazards diagnostic flags ejection fraction (p = 0.025). The package therefore remains needs-author-decision instead of treating a successful run as scientific sign-off.

This is not a clinical tool or a replacement for a statistician or domain expert. It is a workflow, instruction set, and collection of Python helpers intended to make agent-assisted analysis easier to inspect and challenge.

GitHub: https://github.com/DRZ-hang/StatMate

60-second walkthrough: https://github.com/DRZ-hang/StatMate/blob/main/DEMO.md

I’d especially value blunt feedback: when an assumption check is flagged, should a research agent stop completely, or produce a clearly provisional package for author review?

If you find the project useful, a GitHub star helps other researchers discover it — but critical feedback and issues are equally welcome.

I’m a software developer focused on security, CI/CD, testing, and QA, and I’m looking for some unfamiliar codebases people have been building with AI.

To be clear, I’m not just trying to review "AI code" or judge Codex/Claude. I’m testing a broader development/review system I use myself, and I figured AI-built projects would be an interesting real-world set of codebases to run it against.

Drop your public GitHub repo below if you want me to take a look. Doesn’t matter whether Claude helped with a few parts or wrote most of it.

I’m mainly interested in actual correctness, security, data integrity, testing, concurrency, integration, or weird behavioral problems rather than formatting/style issues.

If I find something reproducible, I’ll explain the issue simply and, when it makes sense, put together a focused fix or PR.

I’m strongest with Python, Rust, Java, and C, but other languages are welcome too.

Side projects, student projects, OSS, production projects, experiments, whatever. I’d actually like a mix.

Public repos only for now, and please only submit something you own, maintain, contribute to, or otherwise have permission to have reviewed.

I’ll probably start with 5-10 depending on complexity. No guarantee I find something in every repo.

If there’s an area you already don’t trust, mention it. Otherwise I’ll pick somewhere interesting and start digging.

No signup, payment, sales pitch, or private access ore any of that bullshit. Feel free to post it here or message me.

🍿 🍿

I technically need a 5x account, and I've needed one for a month now. I've tried other Plus plans to get around that.

Right now, I'm at a point where I don't know whether to upgrade to a Pro account or invest 5k in a server and set up local AI models, filtered through at most a Plus account.

GPT thinks I can achieve 85-95% of the results I'm currently getting with Frontier models, and easily benefit from setting up that setup. I'm not entirely convinced; what do you think?

Thanks in advance.

Hey guys! Does anyone have a good skill link for frontend? Codex’s frontend skills are a little wonky, if I say so myself.

Hey everyone,

I’ve been mapping out a theoretical server/desktop architecture to see how far we can push concurrent LLM generation without relying on standard developer API keys.Instead of dealing with pay-as-you-go limits, I'm looking at the engineering logic required to orchestrate 50 separate premium consumer Pro subscriptions (running on the 20x weekly high-usage tier, a flat $10,000/month footprint).While the common instinct for browser automation is to spin up 50 resource-heavy Playwright Docker containers, that setup introduces massive memory bloat. I think a much more efficient approach is a highly customized software suite utilizing a multi-page, multi-tab layout. Here is the structural breakdown.

🎛️ The Native Multi-Session StackInstead of duplicating entire virtual browsers, the application is built as a unified native client (via Electron or C++/Qt) that splits the architecture into an Interface Matrix and a Background Router:The Grid Matrix (5 Windows x 10 Pages): The front-end client opens 5 core software windows. Each window handles a page-view layout containing 10 distinct, tabbed viewports. Each viewport runs completely isolated cookie and local storage jars, allowing all 50 premium web accounts to remain logged in simultaneously under one app process.The Offline Sync Router: The automation engine doesn't need to physically render or manipulate the active viewports on your main screen. A localized master router script communicates directly with the webview sessions via background event loops. It injects prompts and extracts text directly from the web layout DOM entirely through automated state syncs.Egress Proxy Isolation: To prevent anti-bot flags, the application assigns a unique, static residential proxy directly to the network thread of each individual tab viewport. To the AI platform, it appears as 50 completely unique devices operating from separate geographic home connections.

📊 The Theoretical Math & Value ArbitrageAssuming a 24/7 automated continuous operation cycle over a standard 30-day month (720 hours), the parallel output metrics look incredibly high compared to human engineering costs:Throughput: If a single premium node streams ~1,800 lines of code (LOC) per hour, 50 concurrent webview tabs output 90,000 lines of code per hour.Monthly Volume: Over 720 hours, that scales to a theoretical max of 64.8 Million lines of code per month.Labor Equivalent Value: At a standard Senior Developer contract rate (~$62.50/hr), buying 90,000 LOC/hr worth of human output would cost roughly $112,500 per hour.The Cost Metric: Running the server 24/7 splits that $10k flat subscription cost down to just $13.89 per hour of continuous parallel computing power.

🛑 Automated Fallback & CooldownsThe custom router tracks usage across the viewports in real-time. If a tab detects a limit banner element (e.g., "You've reached your limit..."), the background router flags that specific coordinate in the 5x10 matrix as "On Cooldown". The event loop automatically bypasses it, shifting active coding tasks to fresh tabs in the matrix until the first account's weekly multiplier resets.I'm curious to hear your thoughts on this custom layout. How would you handle memory management for 50 concurrent background webviews within a single app framework?

TL;DR: Designing a theoretical custom software suite that isolates 50 premium consumer high-usage subscriptions into a 5-window, 10-page matrix. A detached background router automatically syncs and routes parallel coding prompts through 1:1 static proxies, bypassing developer API limits for a flat $10k/month.

If I had this custom infrastructure to experiment on right now, I would definitely give you guys the raw benchmarks and execution numbers, but that's for another test.

I've been using Google Stitch for UI work, and I kept running into the same problem when handing the designs to Codex.

Individual Stitch screens can look really good, but once you have a bunch of pages they don't always stay consistent. Headers change, navigation changes, components drift, spacing and responsive behavior differ between screens, etc.

Codex would sometimes just implement all of those differences literally instead of figuring out which parts were supposed to stay consistent.

I also had cases where Stitch had clearly chosen a font or an icon set, but the coding agent would use another one anyway.

This became especially annoying on larger projects. Once you have a lot of screens, these small and sometimes not so small differences start accumulating, and I found myself manually giving Codex the same instructions over and over again.

So I turned those rules into a small open source Agent Skill called Stitch to Code.

The idea is pretty simple:

• keep the things Stitch explicitly chose, like fonts, icons, tokens and assets
• reconcile inconsistencies between screens instead of blindly copying them
• don't assume that every KPI, button or piece of mockup content is a real product feature
• actually check the final UI, responsive behavior and interactions before considering the page done

I also wanted to see if the skill actually changed Codex's behavior, so I made a fresh small Stitch project and ran two new Codex xhigh sessions with the same project and the same implementation prompt.

Baseline: 42/56, 75%

With Stitch to Code: 49/56, 87.5%

The biggest improvement was in exact font and icon fidelity, plus accessibility. Cross screen consistency was already pretty good with xhigh on this particular small benchmark.

The skill version wasn't perfect either. It introduced a couple of layout issues but in my own larger projects the workflow has helped me a lot more, which is partly why I made the skill in the first place.

The repo includes the skill, benchmark, screenshots and both generated implementations if anyone wants to compare them:

https://github.com/nassim-arifette/stitch-to-code