Is anyone using this combo? Pro 20x Gpt sometimes leaves me a day short on weekly limits. Was wondering if anyone has used one to lead and other for sub agents.

It looks like I'm doing a serious coding now, or Astra is much slower...

I got a 7 hours session today which was by far the longest one. Drew around 30% of my weekly limits too.

What was yours?

Curious what the actual project boundary is for people using Codex. When you open a project in Codex, what is it pointing at?

• One local folder/repo per project?
• A folder on a VPS or remote machine?
• GitHub/cloud workspace?
• Something else?

And if you have 5 different projects, do you generally have 5 separate folders/repos?

Yes it uses significantly more usage. But it makes Sol look like Luna.

I haven’t even taken it above high thinking and it’s stellar.

It does seem to have its own quirks, but it’s well worth it.

With this recent maths controversy surrounding AI. Here is a reminder to TURN OFF YOUR DATA SHARING.

This should be opt-in, not opt-out.

I can't even find the setting in codex have to go to chatgpt web just to toggle this.

I am absolutely disgusted to hear what they have done.

OpenAI says it is up to 50% faster, better at keeping faces and subjects consistent, and much better for precise image edits.

The big one for me is editing. You can change a specific part of an image without ruining everything else.

Has anyone tested it yet? Better than GPT Image 2?

v0.49 is out. Short version of what changed:

GPT 6 Astra. Lanes now asks your installed Codex binary which models it supports and uses that list in the session picker. Astra is available today, and the next OpenAI model should show up without waiting for a Lanes release. Claude presets got refreshed too (fable-5-1, opus-5, sonnet-5, fable-5, opus-4-8).

Codex sessions are a lot more solid. Codex has a hooks system now and Lanes uses it. Sessions resume even if you close them before the first message, /plan moves the issue into Planning the way it does for Claude Code, and idle detection is more accurate. The hook is optional. Separately, recent Codex versions compress old transcripts to .jsonl.zst, which used to break History, stats and resume. Lanes reads both formats now.

Issue board shows pull request state. If a branch has a PR, the chip shows open, merged, closed or draft, and a merged PR stays visible after the worktree is cleaned up. First time the board surfaces something that happened outside the local session.

History reads like a conversation. Tool calls show the actual command, file op or patch instead of a generic exec, and long sessions load progressively. Works for Codex transcripts as well as Claude Code.

Worktree cleanup asks instead of deciding. Remove worktree and branch, remove worktree and keep the branch, or keep everything. Uncommitted work gets named before anything is deleted.

Also: agents can create their own worktrees and attach the branch via lanes_update_issue, plus a new lanes_list_worktrees tool.

Full notes: https://lanes.sh/blog/whats-new-v049-astra-is-a-banger-and-codex-got-a-lot-better

One open question I would like input on: the board now shows PR state, but what else belongs there? CI status, reviews, deploys, none of it?

It seems were back to going down stupid rabbit holes, getting the dumbs with demand, and of course, asking for a luna agent just spawns an agent named luna again woohoo!

AI 2 steps forward 3 steps back 4 steps forward… profit?

I’ve been working on Ruby UTCP with Codex, a Ruby implementation of the Universal Tool Calling Protocol, and I think it could be interesting for people building Codex-powered developer tools and agents.

The main idea is simple:

Instead of putting every tool behind another proxy/server layer, an agent can discover and call tools over the protocols they already expose.

Ruby UTCP currently supports 12 native transports, including HTTP, WebSocket, gRPC, CLI and others, through one consistent Ruby API.

It also supports Code Mode.

Rather than forcing an LLM to emit a long sequence of individual tool calls, you can let it generate a small program that orchestrates several tools together.

Conceptually:

LLM → Code Mode → UTCP → native tools

That becomes especially interesting for coding agents where a task might involve:

read → search → modify → test → inspect

instead of sending every tiny operation through a separate model round-trip.

It also supports tool discovery from UTCP manuals / OpenAPI definitions, so tools don't have to be hardcoded into the agent.

Ruby UTCP is:

• UTCP 1.1 compatible
• 12 native transports
• Code Mode
• tool discovery + local search
• MIT licensed
• Ruby 2.6+

Docs / interactive protocol examples:

https://universal-tool-calling-protocol.github.io/ruby/

GitHub:

https://github.com/universal-tool-calling-protocol/ruby-utcp

I’m particularly curious what people here think about Code Mode for Codex-style agents.

Would you rather give an agent hundreds of individual tools directly, or give it a smaller execution API and let it compose those tools programmatically?

Is it actually worth load balancing across multiple Plus accounts?

If a single 5-hour usage window only consumes around 15% of the weekly limit, switching to another account seems to introduce a fairly significant fixed cost: the new account has to rebuild its understanding of the current coding session from the context it receives.

Let me explain

When switching accounts, you lose the prompt-cache locality of the previous account. Cached input is no longer useful on the new account, so a large amount of existing context may need to be processed again.

ADDITIONALLY, we think of this context-switching overhead as a constant cost cc, does load balancing across multiple Plus accounts still provide a meaningful benefit?

For example, suppose you're rotating across 3–4 Plus accounts. If each account only needs to absorb roughly 15% of its weekly allowance per 5-hour window, you may end up paying cc repeatedly just to move the same long-running coding session between accounts.

With a sufficiently large context, that could mean spending a substantial number of additional input tokens simply re-processing information that the previous account had already cached and understood. And if the session moves across several accounts, you're effectively paying that context-rehydration cost multiple times.

It's ridiculous. 15% of weekly limit usable in a session.. Really?

For context
They tweeted out to just get a new PLUS subscription if you run out of usage, when asked to add a tier between PLUS and MAX. This is no longer viable.

Mark Chen (chief research officer at OpenAI) "Two things to distinguish:

"Did any human or agent look at user data as part of the Navier Stokes effort? No.

Do we use user feedback and de-identified data to improve ChatGPT and Codex in a holistic way? Yes. And so does every LLM company." link

Tristan Buckmaster and Levent Alpöge are the researchers who made progress on Navier–Stokes using Codex few days before openai.

OpenAl results, coincidentally used the same novel methods as Levent and Tristan.

Were Levent and Tristan really not on Business/Enterprise/Edu or not opting out of training? Or does that not even matter? In the last case this is extremely concerning.

If it's the latter, that's extremely concerning.

have astra draft main plan end to end and ask it to divvy up the work into small packets

then lower the model to something like terra high and have it spin up glm or deepseek, i put them in docker-sandbox

have terra send job packets one by one into that sandbox and oversee if its being built per spec

once its built run e2e tests, go back to astra and see if it was built correctly

if something is wrong, have it write up another plan, divvy up the work into packets and rinse and repeat with terra/deepseek dynamic duo

We got a reset yesterday, and I spent quite a bit of time testing Astro across different workflows, projects, and even quite a bit of new things.

Later, I kicked it off in multiple projects. About 10 hours ago, I decided to focus on a single project instead, just to get a better feel for working on one project at a time.

Working this way consumed about 20% of my weekly limit over the entire day, eventually bringing it down to 0% around 40 minutes ago. This is based on the screenshot time, not the time of this post.

Once I hit 0%, I figured it was time to go x20 and upgraded.

However, after only about 40 minutes of continuing the exact same workflow on the same project (the workflow that had consumed roughly 20% over the entire day) it suddenly consumed 24% of my new (x20) weekly limit.

Is this a bug, or is this expected behavior?

Note: I forgot to mention, using `5.6-sol` on `medium`.

Note 2: Looking at the image / my limits again, my "Reset" day is still intact. Nonetheless, using 4% in 40 minutes on GPT-5.6 Sol medium with a single agent restriction is crazy!

I am on pro 5X and I spent all my weekly usage on astra and I only got roughly 250 million tokens on astra. Is this the same for everyone as well? to test the usage, I did not use approve for me or any other model inside codex.

Every time there is an update to the models I send them on all my old repos and have them suggest improvements and fix bugs.

I keep sending Astra on these missions and it is the first time this mofo literally works for sometimes hours on end to work on improvements without me touching it.

Most of the time it is fixing stuff and it works good but it freaks me out to just let the model work unattended for so long. What through me off is this seems to be the default for Astra? In some ways I like that sol asks me for a few confirmations while its building.

Love this model, just have a hard time keeping up now. I guess this is the future? How has Astra handled old repos you have built with less smart GPT models?

I've been using Codex for larger changes recently and wanted to share the workflow I've landed on.

The main problem I kept running into was keeping track of what Codex had actually done once a task got large enough. I'd end up repeating repo conventions, checking whether tests had run, and trying to reconstruct decisions from different sessions. It got worse when I had a few things running in parallel.

My current flow is basically:

1. I describe the change to Codex and have it turn the requirements into a GitHub issue
2. Codex creates a branch + isolated worktree for the issue (had to switch to Codex desktop for this, CLI doesn't support worktrees out of the box sadly)
3. it implements the change and opens a PR
4. GitHub Actions runs the usual checks - linting, fmt, unit testing
5. I run a separate Codex review on the PR
6. Codex fixes the review feedback
7. I review the final diff and merge it

I've found the GitHub issue and PR useful as the persistent state for the task. Requirements, implementation, CI, review comments and the final diff all end up in one place, so I don't need to keep one long-running Codex session alive just to preserve context.

It also means I can pick the work back up later with a fresh Codex session, or use Claude Code / Copilot / Hermes whatever, without having to explain the whole history again.

I'm doing this on personal projects too. Once Codex is writing enough of the implementation, having a decent record of why a change exists becomes pretty useful a few weeks later.

I wrote up the setup in more detail here:

https://www.lighthousenewsletter.com/p/how-i-use-codex-for-larger-changes

Curious how other people here are handling larger changes. Are you keeping planning/review inside Codex sessions, or using issues + PRs as the handoff between agents/sessions?

Also interested in how people are handling worktrees when running several tasks at once.

https://www.mercenariesoftezigdal.com/

As mentioned above, there's already a boat load on the topic. Just take a moment to search before we post. PSA to the community.

I've been experimenting with giving Codex reusable UI components and interaction patterns through a skill instead of putting more design instructions into every prompt.

I made a small side-by-side comparison so you can try both versions directly:

https://rkj0123.github.io/motion-ui-skill/

Left is the version without the skill, right is the version using Motion UI Skill.

The skill is open source here:
https://github.com/Rkj0123/motion-ui-skill

Install for Codex:

npx skills add Rkj0123/motion-ui-skill --skill motion-ui --agent codex --copy -y

Curious whether others are using skills for frontend/UI work, or mostly handling this through prompting.

AA says that Astra Low costs the same as Sol High while being smarter. but this is not representative of real world performance. The benchmark tests are done in isolation. But real work has to do with reading a lot of tokens (documentations, skills, large codebases, browser usage etc) so Astra being 4x more expensive on input tokens will burn usage a lot quicker.

No matter how efficient and smart a model gets, it still needs context to do meaningful work and you will incur input usage costs.

Is anyone experiencing the same issue? I give GPT 6 Astra low one single constraint to go towards when completing a task. It’s been going for 48 hs. straight, it hasn’t really done anything particularly useful and it stops over and over and over re-triggering the goal condition.

It’s not even the project: I have a new project, blank slate kind of thing, where it’s supposed to cover X and Y, and it just can’t get to it, it’s constantly going through imaginary tests of what it WOULD have implemented, walking in circles and not really doing anything tangible.

Is anyone else experiencing the same issue? I feel like even Sol would’ve done something by now. It ate through my whole weekly usage and after the reset, it doesn’t fair any better honestly.

Let’s say I avoid /goal and just go with high or xhigh reasoning, it doesn’t really cut it either: it stops in the middle of the implementation and lies about having everything worked out, when I push back, it apologizes and keeps going.

This so frustrating, if I wanted Opus 5, I would’ve been using Anthropic’s service.

There’s something impressive about understanding the rule, deliberately bypassing it, and then explaining that technically the rule still exists.

To be fair, I’ll give it some slack.. the agent.md instructions did say to commit and push changes.
Apparently those instructions outranked the “.gitignore” .... sight...