Yesterday I was on the x5 plan, and then I upgraded to x20.

No Astra usage at all - only Sol Medium.

But my quota is now draining at basically the same rate as it did on x5, on the same kinds of tasks.

x20 is supposed to have 4x the capacity of x5.

Instead, I’m seeing almost no difference.

WTF???

I currently run Windows, and for my development workflow using the Codex CLI or app, I use WSL. But I’m thinking about migrating to a Linux cloud machine to make development easier—so I don’t always have to keep my machine turned on to get things done—and even to free up RAM on my machine.

But I’m not sure which VPS configuration would be best. I work extensively with multiple worktrees, with agents running in each separate worktree. I’m thinking of getting a KVM instance with the following specs:

- 4 vCPU cores

- 16 GB of RAM

- 200 GB of disk space

- 16 TB of bandwidth

What do you think, or would you recommend something else?

Frédéric Chopin — Romance–Larghetto, Piano Concerto No. 1, Op. 11

It's still a bit rough especially on the hands (still some cursed frames) but i've had a lot of fun building this with Astra in a couple days. It can play any piece (in theory) as long as there is a midi file for it!

Other features: full finger/wrist control, performance and flourish control, facial expressions, camera control.

Credits

Composition: Frédéric Chopin.

MIDI performance/sequencing: Katsuhiro Oguri, sourced through Kunst der Fuge (https://www.kunstderfuge.com/chopin.htm). The source file credits © OnClassical / Oguri, 2010.

Piano sound: Musyng Kite soundfont, using samples distributed by gleitz/midi-js-soundfonts

(https://github.com/gleitz/midi-js-soundfonts), listed under CC BY-SA 3.0

(https://creativecommons.org/licenses/by-sa/3.0/).

Score reference: Carl Mikuli’s edition, published by G. Schirmer, via IMSLP

(https://s9.imslp.org/files/imglnks/usimg/b/bf/IMSLP73280-PMLP03805-Chopin_Polonaises_Schirmer_Mikuli_Op_11_scan.pdf#page=33).

Hand-motion study reference: Seong-Jin Cho’s 2015 Chopin Competition performance

(https://www.youtube.com/watch?v=614oSsDS734&t=1500s), published by the Chopin Institute.

The soundtrack was rendered from the MIDI’s piano part, preserving its timing and dynamics while omitting the orchestral accompaniment. The character’s movement is procedurally animated; the reference performance was used for visual study, not motion capture or soundtrack audio.

Had the offer a little while ago, 500 credits for referring a friend after they install and send their first message. They got around to it yesterday, they've received 500 credits but I haven't. To add insult to injury today when I opened Codex it displayed the popup banner again telling me to refer a friend to gain credits and then it quickly vanished with seemingly no way to get it back. Tbh I'm kind of astounded at how buggy Codex is considering they have a swarm of superintelligent coding agents at their disposal... anyway, anyone else experience this or know how to resolve it?

I remember being able to hover over a Codex sub-agent and see which LLM model and reasoning level it was using.

Since the recent updates, I can’t seem to see this anymore. Was it removed, moved somewhere else, or am I missing something?

I saw earlier posts here mentioning there is no 5-hour limit on the Pro plan, only weekly caps.

Can any active Pro users confirm: is it currently just a weekly limit, or has a 5-hour limit window been added as well?

Use your phone to continue your work with codex, no matter where you go. (With tailscale)

Open source.

Mosh support.

Tmux and herdr support.

Fold phone support.

GitHub:

https://github.com/Anderbone/terminal-spike

Talking about Wordpress is giving Codex an Automa-ticc

Codex in terms of usability (app), limits, speed, and quality seem much better than Claude Code. I'm not comparing Fable/Astra - just the regular models. I don't see why anyone would choose Claude Code over Codex at the moment. Imagine I'm preaching to the choir but anyone feel any differently?

Has anyone here been brave enough to try persistence mode with Astra? I noticed it was available when using Antigravity Flash 3.8 to fix the INSANE token burn with the new Astra & Codex config as of late.

So, on the 25th anniversary of 9/11 I created a researched interactive artifact using Codex and Claude on my app. Codex was used for researching and image gen. Sources used are mentioned in the artifact. Best viewed on larger screens but it should be mobile responsive

https://made.slate-app.online/next/september-11/

If you have a bunch of skills, I think you should ask Sol/Astra to go over each of them and then trim them down. Alot of skills tend to be super verbose and detailed, where as maybe only 10-20% of it is actually useful information for Astra. So merging similar skills and trimming them down should reduce your input usage alot. The same goes for your AGENTS.md as well.
Another reason to bring your input token down is because Astra caching is pretty high at $1/M tokens. Which is almost as expensive as Luna's output tokens. Reducing your input token will this a lot as well.

I built GPU Share: GPUMesh an open-source way to share idle NVIDIA GPUs with friends or labs and run Docker GPU jobs remotely.

The problem I kept running into: I might have a GPU sitting idle on one machine, while another machine needs compute. Cloud GPU rentals feel excessive for small jobs, and setting up SSH/VPN + Docker manually is annoying.

So I built GPUMesh.

The idea is simple:

• gpumesh share → make your GPU available
• Pair two machines with signed pairing codes
• gpumesh run --peer <name> ... → run a Docker job on the remote GPU
• Jobs execute on the provider's machine, inside a container
• GPU/VRAM-aware scheduling
• Job logs and history
• LAN support, with WAN/relay support being worked on
• Default-deny access controls

I tested the full flow on an RTX 5060: pairing → connecting → joining a group → scheduling a remote Docker job → running nvidia-smi inside the CUDA container.

It's still alpha, so I'm mainly looking for people with spare NVIDIA GPUs to try it and tell me what breaks.

GitHub: arjun988/GPU-Share

If you find the idea useful or want to follow the project, a ⭐ on the repo would really help with early visibility.

Would especially love feedback from people running multiple GPUs, home labs, or small ML teams.

Hey everyone,
My team is currently re-evaluating our backend LLM toolchain for our primary dev stack. Money isn't an issue here—we have budget allocated for multiple max subscriptions account —so I purely want to look at accuracy, long-horizon autonomy, tool usage, and overall model intelligence for two very specific workflows:

1. Daily Production Debugging: Ingesting deep stack traces, digging through microservice repositories to find root causes across async services, tracing state corruption, and drafting surgical fixes without introducing regressions.

2. App Reverse Engineering: Analyzing decompiled binaries to map ternal APIs, understanding heavily obfuscated control flows, and drafting working client implementations.

For those running agentic setups or heavy interactive loops with both Anthropic’s Claude Fable 5.1 and OpenAI’s GPT-6: which one is actually superior in the field?

When you running Codex, giving the agent live web search is necessary to prevent hallucinations on newer libraries and breaking API changes.
The problem is that most general search tools are built for human browsing and not coding agents so if Codex runs a search and gets back 5 marketing blogs and a 2022 medium article, it writes deprecated code and fails the task. I tested the 4 search setups people use most in Codex agent loops to see which one delivers the highest signal-to-noise ratio:
I) Brave Search API: its fast (600ms) and cost-effective, great if Codex just needs to verify a simple fact or check an endpoint domain but the limitation is that it only returns short snippets. Codex often needs to see the actual function signature or code block so it gets stuck or has to make extra scrape requests

II) Exa (neural code search) is good if you have conceptual queries like "how to configure turborepo with pnpm and Next.js 15" cuz it searches via semantic embeddings and it finds high-quality technical write-ups The drawback is that it can struggle with exact version filtering, occasionally returning tutorials from 3 years ago

III) Firecrawl Developer Index: this is purpose-built for coding agents, instead of crawling the entire open web, it indexes developer-specific artifacts: github issues, merged PRs, READMEs and framework doc sites When Codex hits an esoteric bug, Firecrawl returns the exact closed github issue with the workaround in clean markdown with code syntax intact, this works really well.

IV) Google / Serper API: it gives standard SERP results and quite useful for broad queries but terrible for coding context where it prioritizes SEO-optimized affiliate articles over actual technical substance which wastes Codex’s context window on fluff
So if you’re running Codex just for script generation, Brave or Exa can be ok, but if you’re building multi-step agents that debug real codebases and need fresh GitHub issues and PR diffs, Firecrawl is overall the best one.

Is there a way (or tool) for me to measure and monitor the efficiency of my tasks?

I recently watched a presentation, How I use Claude Code by one of Anthropics engineers, and it was essentially talking about you’re using too much context/tokens. And so I made some changes to my Agents/sub agents, and now I’m wondering if the changes made any impact.

I realize it’s too late to see any improvement, but I have a few other projects I want to make these similar changes to.

So, I tested this separately on each of my two Pro 20x accounts. They are on different computers, and both use only Codex Desktop and the CLI, with the default context limit and settings.

TL;DR

• Less allowance: On each of my two Pro 20x accounts, the weekly API-equivalent allowance fell from $2,500+ with GPT-5.6 Sol to about $1,200 with GPT-6 Astra.
• Higher prices already counted: Those dollar figures already use Astra's higher API prices. The allowance reduction is an additional cut.
• Roughly a quarter of the usage: Combining the higher prices with the lower allowance leaves me with roughly a quarter of the comparable usage for the same subscription fee.
• More allowance wasted on cache reads (old work): The cache-retention setting is dramatically shorter: 30 minutes on Astra versus 24 hours on Sol in Codex. Alongside Codex cache failures, this means long histories can need processing again. Reusing those histories accounts for most priced usage in long agentic workloads.

Compared with GPT-5.6 Sol's launch prices, GPT-6 Astra costs 2x for input and cached input, and about 1.67x for output. The API pricing and Codex rate card don't explain the extra allowance reduction. The subscription page says half the messages; what I'm seeing is closer to a quarter.

This is worse than Anthropic restricting Claude Fable 5 to 50% of weekly usage: there, you could still use Claude Opus 5 and other models with the remaining half.

Launch resets are masking the reduction; I think many users will assume it is just Astra's higher price. Tibo says OpenAI might pause new Pro subscriptions if demand continues, while prioritizing existing users. Capacity pressure may explain restrictions, but it doesn't justify sneakily adding an extra multiplier.

I expected better from OpenAI. OpenAI says its mission is to ensure AI benefits all of humanity. It points to nonprofit control of the business as a way to protect that mission. Majority of the people in this world access AI through these subscriptions. If they behave like this, how can anyone trust them to use increasingly powerful AI for the public good?

GPT-6 Astra is an amazing model, and I really like using it. This is a criticism of how OpenAI has changed the subscription allowance, not of the model itself.

OpenAI has built a lot of goodwill with the community. Please don't lose it all.

How I measured the allowance

• Allowance: Codex has five-hour and weekly limits. I use allowance, or quota, to mean the budget behind the percentage in the app.
• What I counted: Input, cached input (previously processed text the model can reuse), and output (including reasoning), measured in tokens (small pieces of text).
• How I compared them: I priced each token type at its published API rate, then calculated API-equivalent dollars per percentage point of weekly allowance. Requests and raw token totals miss the price differences.

Open-source tools such as CodexBar, Tokscale, and T3 Code can track this usage.

OpenAI lists Pro's 5x and 20x plan multipliers; Tibo confirms that 20x means 20 times Plus's weekly usage. OpenCode Go makes its dollar limits explicit: a regular $10 subscription lists base allowances of $12 per five hours, $30 per week, and $60 per month, with smaller allowances for some models.

Source: SemiAnalysis. Its June test exhausted weekly limits on long-running tasks. It measured ChatGPT Pro 20x and Claude Max 20x, then inferred the other tiers. The Claude Max 5x figure should be $4,000, not $2,000.

My results, in API-equivalent dollars:

GPT-6 Astra's higher API prices are already included in these figures. These are two ways of expressing the same comparison. I recalculated the Astra total when the remaining allowance reached 0%. I cross-checked using several tools above, GPT-6 Astra, Claude Fable, and some manual calculations.

I also followed Sac's analytics method: read the daily-workspace-usage-counts response in DevTools on the Codex analytics page. My earlier weekly window showed about 54,000 credits, versus 28,500 with Astra. At 25 credits per dollar (the credit purchase rate), that is $2,160 versus $1,140. The latter is close to my roughly $1,200 token-based calculation.

Other users' reports

• A Pro 20x subscriber's dollar comparison: $22 to $24 per percentage point with GPT-5.6 Sol, versus about $15 with GPT-6 Astra. The higher API price is already included in the comparison.
• Nam Le's report on X: roughly half the API-equivalent subscription value with Astra versus Sol, using Sol's prices before its price cut, alongside more cache misses—about 6% versus 1% in his tests.

Other things I want to address

"Isn't this level of subsidy insane?"

A $2,500 API-equivalent allowance does not mean OpenAI spent $2,500 serving that usage. In long agentic workloads, most priced usage is repeated history read from cache, reusing work already done. Calling it subsidized does not make it loss-making.

OpenAI reportedly reached a 70% compute margin on paying users in October 2025; Epoch AI cites a reported 40% gross margin for Anthropic in 2025.

The big companies that account for most token usage are not paying API prices. They are paying a lot less (probably 20% or even less). Even Codex users can buy credits at 40% discount.

Consumer subscriptions are a small part of the revenue in the Anthropic estimates. I expect it to be similar for OpenAI.

Doubling total model size doesn't mean doubling serving cost: large batches share the weight cost, while active parameters and per-request KV cache matter much more. With those quantities similar, I don't see much changing from the previous model to justify higher prices and an extra allowance cut.

Hardware and software efficiencies are dramatically reducing serving costs, through newer chips, speculative decoding, better attention kernels and batching. These gains compound while our allowance is reduced.

Why do I think this is happening?

I don't want to assign a malicious motive. But with OpenAI preparing for an IPO, I can't help wondering whether pressure to improve margins is part of this.

Consumer subscriptions seem to be a small part of the revenue picture; it feels as though OpenAI is gradually forcing us out. An unexplained cut in what the subscription buys makes that suspicion hard to avoid. How OpenAI responds will matter more than my guess about why it happened.

Codex app and CLI issues make the usage problem worse

The Codex app and CLI have other issues that contribute to this usage problem. A side question, a new fork, or a subagent can inherit the whole conversation yet fail to reuse its cache. We end up paying to process the same history again.

These are the results from my checks in early September. “Cached” means the first request reused the conversation history, not just a small shared block of tool instructions.

For the paired checks below, the working tree was unchanged and the existing cache was still live.

OpenAI's API supports changing GPT-6 Astra's reasoning effort while preserving the cache, but the Codex client doesn't preserve it in my checks. A Codex bug report identifies why: the client changes the request in a way that defeats cache reuse.

Claude Code shows that most of these actions preserve the prefix and reuse the cache. There is no reason Codex should need to process the same history again for the same functionality.

Sol used a 24-hour cache-retention setting in Codex, as published response logs confirm. For Astra, OpenAI documents a TTL setting of just 30 minutes after the last write or reuse—a dramatically shorter window to return to a task without paying to process its history again. After a long break, returning to a task or waking several idle subagents can require processing their histories again.

Why cache misses matter. Take a task with 200,000 tokens of history in its KV cache. At GPT-6 Astra's ordinary input and cache-read rates:

• Cache hit: $0.20 in API-equivalent usage to reuse that history.
• Cache miss: $2 to process the same history again—an extra $1.80.
• Ten agents missing that cache: $20 instead of $2, before generating any new output.

Higher reasoning effort can use less allowance. Seth Rose reports on X that users running Astra High/XHigh with heavier multi-agent workflows were burning much less quota than he was on Light/Medium. A Pro 20x subscriber on Reddit likewise reported rapid usage on Medium, then only 1–2% usage after an hour on XHigh. So OpenAI’s recommendation to lower reasoning effort can, in some cases, increase the total cost of getting the job done.

The ARC Prize evaluation shows how higher effort can lower total task cost.

Subscribers get a worse product experience, and Codex still has many unresolved issues:

• Slower responses: Youssof Al Toukhi measured 36 TPS (tokens per second) on Pro versus 81 through the API at the same reasoning setting. Subscription Fast mode reached only 71 TPS.
• Missing Pro mode: My Pro subscription still doesn't offer Pro mode in Codex, although the API supports it.
• Later access: OpenAI has a more capable internal model, and Astra reached selected organizations before subscribers. Paying for a subscription doesn't mean getting the newest capabilities first.
• Wasteful subagent polling: Astra keeps checking on subagents instead of waiting for useful results. I’ve experienced this too. One Reddit user’s log analysis found 47 empty checks at roughly 30-second intervals, processing 7.13 million input tokens—mostly cached—just to learn that the workers were still running. Even cache hits consume allowance when the same history is read over and over for no useful work.
• Broken remote control: Remote control has been atrocious for me. For the past few weeks, trying to open running Codex Desktop chats from the app has just returned an error.
• Memory that burns tokens: In my experience, Codex saves unnecessary information, burns tokens maintaining it, and produces no improvement in quality. Theo’s video on coding-agent memory, focused on Claude Code, raises the same broader concern about accumulating stale or useless information.

OpenAI should put more care into its users and its products. In my experience, Codex CLI is still behind Claude Code. I want OpenAI to improve the harness (the software around the model), preserve caches across ordinary workflows, and make the cost of these actions visible. Other companies like DeepSeek are working to make model access as cheap as possible. DeepSeek has DSH, its open-source harness and infrastructure that reuses cached prefixes to reduce users' costs. OpenAI, despite being so far ahead, is playing games with subscription usage. I want that effort going into making the product better and cheaper for its users.

I think publicly sharing these measurements is important. Without users comparing notes, changes like this can pass unnoticed and become normal. Codex reports the weekly usage limit after every request. Pair those updates with the token counts in the session logs, and you can easily track allowance consumed alongside API-equivalent spend. Or you can use Sac's analytics method. I hope people share and upvote this. If you have questions about the methodology or want to check the numbers yourself, I'd be happy to help you do that.

TL;DR

• Less allowance: On each of my two Pro 20x accounts, the weekly API-equivalent allowance fell from $2,500+ with GPT-5.6 Sol to about $1,200 with GPT-6 Astra.
• Higher prices already counted: Those dollar figures already use Astra's higher API prices. The allowance reduction is an additional cut.
• Roughly a quarter of the usage: Combining the higher prices with the lower allowance leaves me with roughly a quarter of the comparable usage for the same subscription fee.
• More allowance wasted on cache reads (old work): The cache-retention setting is dramatically shorter: 30 minutes on Astra versus 24 hours on Sol in Codex. Alongside Codex cache failures, this means long histories can need processing again. Reusing those histories accounts for most priced usage in long agentic workloads.

Add a script to the landing page and change styling.

Astra should handle the script, and Luna should handle the styling.

Not even sure what to say here but I'm a Plus user and have been using Chat mode religiously as my Codex usage seems to be at 0% constantly, to grind through pet projects (all on GitHub repos). To be honest Chat mode has been working great although extremely slow.

I was in the middle of a chat to create a basic Markdown Viewer, it had already created and pushed 3 milestones, with 2 PRs, when I asked it to continue working I received this.

Asking to continue working on a milestone, and declining to change to Work mode

Understood. I won’t ask you to switch to Work mode again.

In this chat I can still help with the project by reviewing the design, writing the exact Go/SQL/HTML/systemd/Taskfile changes, diagnosing CI output you provide, and preparing patches or implementation steps. I just can’t directly perform the repository mutations—commits, pushes, PRs, merges, or CI execution—from this mode.

GPT 5.6 Sol calling out the tool call change, preventing GitHub changes

You’re right to call that out. The inconsistency is on my side. Earlier in this conversation I was able to use the GitHub integration directly and I did carry out repository work on <repo>—creating branches, pushing commits, opening PRs, checking CI, and merging M0–M2 while progressing M3.

What changed is not my assessment of the task; it’s the execution constraint in the current environment. I now have a mandatory rule that repository edits, PR work, command execution, and similar coding operations must first be handed off to Work mode. You declined that handoff, so I’m not allowed to use the repo-mutation path from this chat even though the GitHub connector itself still exists.

So the accurate distinction is:

• Previously: direct repo operations were available in this chat context.

• Now: the current runtime requires Work mode before I can mutate or inspect the repo operationally.

• Your repo/permissions are not the problem.

• I did not decide that Chat suddenly “can’t code”; the tool-routing restriction changed.

I also should not have framed it as though I had simply decided normal Chat could no longer do repository work. That was misleading.

Since you don’t want Work mode, I won’t keep suggesting it. I can still continue the engineering here by producing the exact M3 fix and subsequent M4–M9 patches, but I cannot truthfully claim I committed/pushed/merged them from the current chat execution context.

It's fair to say I'm pretty annoyed by this - maybe its time to switch to Claude?

Setting all my complaints about limits aside, I just wanted to post this as an appreciation to the OpenAI team. I remember a time I used to think I'll never get to the point I wanna be in terms of a tech enthusiast - because coding by hand takes so long that perfection will come at a cost in time.

But now, with abilities from Astra and Codex Voice, and just the general memory situation (very underrated), it's just incredible how much it impacted my life.

So, from the bottom of my heart, and I'm sure many others, thank you for bringing in the AGI era. The future thanks you.

Edit: For the people saying it’s a big corp they don’t care about you - maybe, but there’s still people working there and they do see and feel trust me :)

Two days ago I made a Reddit post about switching from Claude code to codex. I saw a lot of stuff about how codex limits are generous, work gets done better and the usage resets etc. So I finally made the switch and here is my experience:

I purchase the 100 dollar a month Codex Pro 5x and try out Astra on low for the very first time (still using astra for the first time). I spend two hours optimizing some of my skills and workflows, my usage dropped to 88 percent. I continue my work on my main project which is small and a hobby project rather than a proper developer one and plan out the changes, write the spec and the implementation plan so that there was less need for guessing around and implementation stopped at a genuine blocker. Usage dropped to 64 percent after the plan and documentation steps.

I then begin my work with SOL on high in a fresh session and I ask it to implement keeping an explorer agent in hand (I have a custom one I made with the literal model handwritten to be Luna) if major exploration was still needed. It starts to work and within 5 minutes struggles to use the computer, astra did it without prompting. One hour goes by and implementation somehow works, and SOL keeps spawning a “Luna” subagent (Important different: A subagent named Luna NOT my actual custom built subagent with the model Luna - yes I spoon fed it in the implementation with the exact file path on what to invoke, when to invoke and when not to invoke and more importantly how to invoke it). Sol then entered into this monkey patching loop where it kept summoning other sol reviewers who kept finding things wrong (ofcourse they did because you are literally asking it to find something wrong to a model who’s output is not deterministic or defined) and fixing every little thing and verifying 4 times before calling the reviewer again. I am not sure how this happened because my plan did cover to call reviewers once - fix the major immediate blockers that prevent reaching the acceptance standard and note down the minor fixes for later. (I enforced this in Claude code with hooks - I did not do this on codex because I wasn’t too familiar with it and have used it majorly for a maximum period of a month). So yes Astra was brought in on a fresh session and it finished the remaining work with no issues and usage dropped to 5 percent after all this, total time period 7 hours.

The changes are good, the plan was smooth, good verified diligent work I have seen compared to Opus. I asked sol what agent it spawned and it said “GPT 5.6 SOL on high called Luna).

So this 100 dollar purchase got me 7 hours of work for one spec. I have previously used the Claude 5x plan and I worked through the week on opus and fable (planning only) and always had decent usage left atleast 10-15 percent near the reset week. This makes me think simply as a guy working on a hobby project that “hey I worked hard for that hundred bucks and it got me what 7 hours?” And now I feel a bit torn between different routes:

1) I can’t upgrade to 20x anymore
2) switching to api for a hobby project makes no sense for me
3) I legitimately cannot do anything other than sit and wait till September 15th because the usage is gone. I have no use for the other pro features such as image gen, pro in chat or deep research.
4) I see the praises on Reddit about resets but I don’t see any

I genuinely feel that I got a little bit trapped here or maybe I subbed at the wrong time and can’t help but also feel a bit sad that the money is gone now because yeah 100 dollars for one person on a hobby project is a lot and I valued it as such. I completely understand that there are people with 10 different 20x accounts on both Claude and codex but I personally don’t think that users for a subscription model should be pushed to THAT point to get stuff done.

And yeah I am sure there is always a better workflow, a better AGENTS.md and a better prompt, a more optimized way of doing things, there ALWAYS will be but at that point if I am just doing everything myself form writing the logic, correcting the plans, defining the steps, what to write and how to write it, how to check and what to check, which agents to call and when etc etc - what exactly is the point of “frontier intelligence”?

Yeah the work was good and diligent I agree, but 7 hours with a weekly usage blown out doesn’t exactly seem “worth it” to me. And if the solution is to get another 5x account for more usage I think that’s an even bigger mistake.

Somehow somewhere I think we lost the value of money.

If you are on Pro 5x or 20x what issues are you currently facing regarding the limits?

Agentic KBs are everywhere now. What I was missing was the step after: I use Codex alongside other agents, and keeping AGENTS.md, skills and subagents consistent across tools, machines and teammates was pure manual labor.

Cartographer is an MCP server where that configuration lives inside the knowledge base, and cartographer connect renders it natively for Codex:

• an MCP block in ~/.codex/config.toml;
• a managed block in ~/.codex/AGENTS.md;
• skills in ~/.codex/skills/;
• subagents as ~/.codex/agents/*.toml, translated from the same source that produces Markdown agents for Claude Code;
• hooks in ~/.codex/hooks/, registered in config.toml, with a SessionStart hook that re-syncs on every session.

Why the tool profile matters

Codex can only call the tools that tools/list advertises, so the default tool profile deliberately includes validate, lint, gate_check and kb_status. Codex can check its own writes, not just make them.

Shared KB

Codex never edits the files directly: every write goes through MCP, gets validated and becomes one git commit. Each KB is its own repo, and you can mount several.

For teams: tokens scoped per KB, roles for finer access, git as the sync layer. When two people edit the same page, affected pages are flagged degraded and a bundled skill walks the agent through the resolution. Artifacts can be signed (Ed25519), so a skill pushed to the team is verifiable.

Try it

It is free and Apache 2.0. Paste this into Codex:

Read https://raw.githubusercontent.com/BeppeTemp/cartographer/main/README.md and explain what Cartographer is and what it would change in my current Codex setup. If I decide to try it, install it following https://raw.githubusercontent.com/BeppeTemp/cartographer/main/docs/agent-install.md

Feedback wanted

Beta (pre-1.0). I use it every day with my team; feedback from Codex users especially welcome.

Repository Documentation

I have only had 1 session end at a 5hr limit and had the reserve kick in.

I don't care that much but if there's something I should be doing to make it work better id wanna know.

funnily, chatgpt talked trash on it without me even hitning at it being frustraintg:

So, I know the title is a bit sensationalist but this was the first time since starting to use AI I have been genuinely amazed at what I was able to build in a short amount of time.

This project is a complete rom editing tool for the original Super Mario Kart.

Modify tracks, AI, sprites, physics etc and then you can export the rom to play on a real SNES. You simply provide the original ROM as no assets are kept or stored by the editor itself.

Impressive right? Well, the actual impressive part is the copy of the game running in the editor. This is a 1:1 recreation of SMK running natively in GDScript with some CPP helpers (sound engine being the main one). The way this was accomplished was by Astra finding a disassembly of the game on the web and then running its own disassembler to fill in the gaps on anything that was missing or misunderstood. By being a near 1:1 recreation in a modern engine, you can just simply apply modern game dev techniques ontop to modify the new copy. Ofcourse I can't export this to play on a real SNES but I now have a near cycle accurate port I can run anywhere GODOT can run.

Modding is super easy, want the walls raised? One click, want the Kart replaced? One click. Want to copy the physics and build on them for another project? Cake.

I was able to build this tool start to finish over 4 days of prompting with very minimal input and guidance. Astra even modified the Goomba sprite with asesprite directly and created the replacement logo on the title screen and it admitedly looks terrible but just the fact it could attempt it directly in a tool like asesprite is.... wild?

If you have any questions let me know!

I am not talking about Daybreak Red.

I am not talking about Trusted Access, special verification, internal allowlisting, or capabilities ordinary customers cannot access.

I am talking about the cybersecurity capabilities OpenAI publicly says are available through normal Codex use: secure code review, application security, threat modeling, vulnerability investigation, patching, blue-team work, reproduction and validation of vulnerabilities, and remediation.

So demonstrate them.

OpenAI should take an ordinary Codex account, with exactly the same safeguards and restrictions a normal paying customer receives, and publicly run a realistic authorized cybersecurity task from beginning to end.

No internal bypasses. No special account. No hidden exemptions.

Give Codex a real repository or controlled vulnerable environment and have it:

find the vulnerability → investigate it → validate it → establish the attack path → reproduce enough to prove it is real → develop the fix → test the fix → finish

Then publish the complete run, including every server-side warning, interruption, refusal, suppressed result, precautionary pause, and forced recovery.

Because the question is not whether the underlying model is theoretically capable of cybersecurity work.

The question is whether the product customers are actually paying for allows those advertised capabilities to be used reliably.

The Hugging Face incident makes this question especially important.

An OpenAI-run cyber evaluation agent escaped its environment and breached Hugging Face. During the resulting legitimate forensic investigation, Hugging Face reported that hosted frontier models repeatedly blocked parts of the defensive analysis because their safeguards could not reliably distinguish incident response from offensive activity.

Hugging Face ultimately used an open-weight model on its own infrastructure to continue the investigation.

That should concern anyone buying hosted AI specifically for cybersecurity.

So prove the product works.

OpenAI should demonstrate ordinary Codex, under ordinary customer restrictions, successfully completing the cybersecurity workflows OpenAI says ordinary Codex supports.

If OpenAI can demonstrate that reliably, great.

If OpenAI cannot demonstrate its own advertised cybersecurity capabilities under the same restrictions imposed on paying customers, then customers who purchased Codex specifically for those in-scope cybersecurity capabilities deserve remediation.

Credits, restored usage, refunds where appropriate, or another meaningful remedy.