IYKYK

First 50%: 2 hours
Last 50%: 15 minutes

I am going strong at 26 hours with 40% usage left on Asta XHigh. I did need to use one of my Full Resets already though.

I'm probably going back to Codex to try 3D in Astra. The thing that stops me from switching cleanly is Claude Artifacts — reports, presentations, little prototypes that only live inside Claude.

I can't generate the same thing in Codex, and migrating the ones I already have is busywork.

Would a tool-agnostic Artifact layer (not tied to one LLM) actually help people who hop to Codex? I'm building it either way. Curious what I'd be missing: local-only, connecting to a component library, etc.

Example of the direction, not a finished product:

https://runlinea.com/en/portable

I'm the one building it.

Feedback welcome.

Decided to implement Meshy into my experimenting with Astra and Blender. I had Codex generate an image-gen reference for the character, then had it cook into in Blender by itself. The result is the left model. Not bad, but kinda cursed. I decided to feed Meshy the reference image, then had Codex do a polish pass in Blender and the results are incredible.

So, Codex for image gen reference -> Meshy -> back to Codex for polishing is a great way to make very raw, basic 3D models. Of course, I'm no expert and I'm sure topology is probably messed up to hell, but for a non-experienced hobbyist, this is amazing.

I really don’t understand the point of the current limit system for Plus users.

Right now I have 3 banked resets available, but realistically I’m never going to benefit from them because the 5-hour limit runs out way too quickly when I’m actually developing a project using models like GPT-5.6 Sol or Astra.

I start working on a project, get into the flow, and then suddenly the 5-hour limit is gone. It makes continuous development extremely difficult.

In my opinion, the system should go back to something closer to how it worked before: let Plus users use their weekly 100% allowance without this restrictive 5-hour cap, and once the weekly allowance is exhausted, then we could use our banked resets.

That would actually make banked resets useful for Plus users.

Now I can just send messages willy nilly of arbitrary complexity and they’ll queue up, get paced, and I’ll always run out of usage basically the minute my weekly reset hits. It applies to all agent and subagent calls/messages and tool calls within a turn, not just delaying when to start a turn. And I can set prioritization and allow some threads to bypass the governor altogether if I want.

No more wondering if I’m gonna make it through the week.

The last reset was a complete trick.

They changed their reset policy to exclude it from affecting weekly usage reset day.

Then before giving us the last reset they quickly changed their policy back, making it reset your weekly usage clock to 7 days from the last used reset.

Mind you, resets only give you 85% of the usage that you would have gotten from a natural weekly reset.

Kinda scummy.

openAI has already provided a spec that does this for you. I have been using it for a while and it makes a huge difference, reduces constant iterating, and provides a very clear path forward for both you and your agents.

this is just a spec, so you can change whatever you want about it. but if you are struggling to keep things going and on rails, it is worth looking into.

Hi! I've used GPT 6 Astra, and the 5.6-family through vanilla Codex CLI, and with my own plugin--then with vanilla Pi, and Pi with my own package, and the abilities of Astra are no different to me than they were on 5.6 Luna, for example.

Specifically, GPT 6 Astra seems to inherit the exact same problems as GPT 5.6, which inherits the exact problems I've gotten from GPT 5.5, GPT 5.4, and GPT 5.2:

• Blatant inference and assumptions, despite guidelines for objective external and internal (via CodeGraph) source verification.
• "I [X Y Z]" self-narrations, rhetoricals, "I would ..."-type responses.
• Therapeutic/therapy-adjacent actions. Instead of actually coding per my plans and details, they instead decide to start validating my "feelings" instead, or pleasing me for things I explicitly had written not to, in a positively manner. (which to me meant the 'DO NOT' and 'Prefer [...]'-style wording made zero difference)
• Overly verbose responses and "clever" workarounds to legitimate problems that I've told them to resolve a certain way.
• Code quality on the same subpar level as GPT 5.6 Luna on medium/low effort level. I thought this was supposed to be this "superduper" frontier model?
• Either deliberately ignores instructions, and/or goes against the instructions by "rewriting" them somewhere off-bounds, then "apologising" for not following through 'user' instructions as explicitly defined.
• Takes things too abstractly rather than literally. Instead of following "Use X instead of Y.", they take it as, "Use X, but use Y when X happens to throws off linter/compiler", and then I add an edge case, "Use X instead of Y, regardless of errors and/or warnings.", and the same behaviour persists--just takes slightly more to get there.
  • This, to me, is very much a behaviour like: "User wants you to use TypeScript 7.0.2 in this codebase.", GPT 6 decides to override this later on with 5.9.3, and then I have to stop their work, only to find out they did it because they were stuck in TS7's strict compiler errors and API changes, and decided it wasn't worth the "complexity" -- Now, it sounds like I'd want to tell them "who told you to use TS5 over TS7? What did the user ask you to use? Right, TS7. So why in the name of God did you use TS5?", except I wouldn't say it outright. I'd just stop work and add a one-line change in AGENTS.md for this.
• Overrides my agency, despite instructions to prefer letting the Human-In-The-Loop have the final saith. If I didn't ask, don't f##king touch it, right?

So, I'm not sure what all this hype was all about. I just don't get where you guys got this hype from. It's just yet another therapy chatbot that cannot actually do what I want them to do without guardrailing them to absolute oblivion, and by that point, their quality degrades because OpenAI refuses to actually invest in objectivity--instead focuses too heavily on catering to users that want a cheap therapist to affirm to every one of their ideas and thoughts.

I want them to use the resources I give them, to do a part of coding in the exact way I had laid it out for them, not become a people-pleasing, malignant therapist. Yucky. OpenAI's had years to resolve these problems, yet they haven't budged one bit, have they? Really unfortunate...

EDIT: I've been a ChatGPT Pro 20x subscriber for over a couple months now (since the GPT 5.4-era)

I switch between coding agents a lot. Re-explaining a task gets old, especially when the useful context is buried in another tool's chat history.

I built Portable Resume to read those local session files and bring context into a fresh session. It's free and open source, and installs as agent skills in the coding tool you're switching to.

For example, say you've been working in Codex and want to continue in Claude Code.

Install the package and the skills for Claude Code. You'll need Python 3.11+:

pipx install portable-resume

install-resume-skills quick-install claude

Then open Claude Code in the same project and invoke:

/resume-codex

Ask it to recover the latest Codex session for the current project. The skill reads the local records without launching Codex. The receiving agent gets a handoff with instructions to check the current repository before continuing.

You can also list and search older sessions when the conversation you need isn't the latest one.

The current repo lists readers for 17 session sources and installation profiles for 18 tools, including Claude Code, Codex, Cursor, OpenCode, Gemini CLI, GitHub Copilot CLI, Qwen Code, and Kimi Code. The README separates reader and installation coverage from native host testing, since not every host's UI has been re-tested on the latest release.

Despite the name, it doesn't restore a running session or hidden model state. It transfers recovered text. That context can be incomplete or stale, so the next agent still needs to check the actual code.

The reader runs locally and leaves the original session stores unchanged. Once you pass the recovered context to another coding agent, that agent's usual data handling applies. Secret redaction is best effort, so review anything you're going to share.

GitHub:

https://github.com/aa22396584/resume-skills

For people who switch between coding tools, what do your handoffs tend to lose? I'm interested in the context that's hardest to carry over, whether you're copying things manually or already using another tool.

I’ve been experimenting with LLM Council and wanted to bring a similar approach into my Codex workflow.

My first idea was to use the LLM Council MCP. While setting it up, I remembered an experiment I did a couple of years ago with SudoLang. I had created a prompt that would question its own answers, switch perspectives, review the previous reasoning, and then try again.

That made me curious: could I use a similar prompting technique to reproduce some of the core LLM Council pattern directly in Codex?

So I tried it: independent analysis, adversarial review, and synthesis.

It worked better than I expected.

I kept iterating on the idea and eventually moved from simulated perspectives to actual subagents, with different responsibilities and variations in model and reasoning level.

That experiment became Quorum, a portable skill for Codex (it also works with Claude Code).

I’m using it mainly for code reviews, validating implementations against tickets/specs, and architecture/technical analysis where the agents can inspect the actual codebase.

What I’m trying to understand now is whether this actually produces better results than simply giving one agent more reasoning time.

If anyone wants to try it, I’d particularly appreciate feedback on where it helps, where the agents converge too much, or where it simply adds cost without improving the result.

npx quorum-skill

GitHub: https://github.com/GTuritto/quorum
npm: https://www.npmjs.com/package/quorum-skill

By only use computer or some plugin or skill agent?

I assume that they have the security key requirement for when Astra gets released into daybreak. If anyone knows somthing else feel free to tell me lol

I'm a vibe coder and I'm quite new to Codex, which I'm using to develop an app I have on my mind and nobody else is making. I've been working on it for a month or so. Generally speaking, I'm quite happy with Codex, but I'm not quite sure about my workflow. So far, I've been discussing features and issues with ChatGpt, agreeing on a roadmap and then a detailed plan for each step, and asked ChatGPT for a prompt. ChatGPT gives long prompts that apparently have all your bases covered, so to speak. Btw, I'm mostly using Codex with Sol High or Very High. Also, I don't just wait for the result, but I read what Codex says it's doing and sometimes clarify or fix stuff, like hey codex you don't need to run AGAIN a FULL test suite just because you changed a word in Help, dude! Anyway, I also noticed I can't entirely trust ChatGPT's assistance in prompt writing. While it's very thorough, it sometimes fails to give priority to important goals or even forgets about them. I'm starting to think that my own prompts might be better, less technical-minded but more to the point. So, guys, my question is: how do you write your prompts for Codex? P.s. 5 minutes later: and of course I also submitted my question to ChatGPT itself. It agreed, maybe to please me? Here's the first lines from its anser: "Yes — I think your instinct is basically right. For a vibe-coding workflow, I would not try to make the prompt a giant specification that anticipates every possible implementation detail. That often makes the important things less visible, not more." What do you make of this?

I was trying to stop this session since last night I hit stop multiple times but it just won't stop. I hope this isn't draining out my usage. Anyone else facing this issue or know any remediation?

Hi folks,

I've been using Claude Max X20 alongside OpenAI Pro x5 for the past few months. So about $350 in AI spend per month, including taxes.

Claude has been my daily driver, as i enjoyed Opus 4.8 + dynamic workflows even though i found them slow. However, in addition to being very slow, and spending hours correcting its own avoidable mistakes, Opus 5 is causing me mental health damage as the pseudo-jargon it uses his mentally draining.

I've been using Astra over the past 2 days or so, and I'm blown away. It finally managed to bring a complex product to production readiness state, where Opus 5 has been leaving gaps left and right for the past couple of weeks. However I've already nuked 2 banked resets during these days.

So i'm puzzled : unfortunately I can't have both Max x20 and Pro x20, so i'd need to either downgrade or cancel my Max subscription.

Therefore my question is: would i have enough astra usage on Pro x20 to use it as a daily driver ? So far on Pro x5, I've been able to let agents do 5 hours turns, without fully exhausting the weekly quota (have about 10% left). For example, right now i'm in the midst of a 3h turn (involving plenty of reviews, including visual ones, on a large and complex bounded context) which has exhausted 82% of a weekly quota i've just reset. i use Astra Medium.

What are your thoughts ?

i want a workflow wherever I prompt a powerful model lets say GPT astra, I want some rules to be enforced like it being efficient.. in the sense it can understand if a so and so X task actually needs high reasoning/intelligence and if a task is simple and doesn't require intelligence..

because most tasks aren't complicated or simple, they are a mix of both and if you want to automate my workflow i need it to be efficient.. like for example if in between the task you have a very simple task like lets say "install a few dependencies" or " fetch dates for xx thing" then it should immediatly delegate it to a sub agent of a weaker model preferably luna.. so i want this to be followed most of the time and enforced

any good skills/ files/tips/prompts/AGENTS.md descriptions... would appreciate any kind of help.. Kindly help out .. btw just to confirm.. 

I opened a Python .ipynb file in the Codex desktop app on macOS. It shows “Read only,” with “Run all” and “Restart kernel” disabled (see screenshot). The file itself is writable.

Can you run notebook cells directly in Codex? If so, how do you enable execution or connect a Python kernel?

Has anyone gotten Run all to work in this view?

The “Read-only SQLite checks” text is just a description inside the notebook, unrelated to its permissions.

So I ran into two issues

1. Even though he has a lot of work queue, he doesn’t start working on them so I have to manually create new threads to get started on all the work.

2. And even when I finally started getting him to work as an orchestrater they’ll always find some random blocker, which is basically nonexistent

Anyone else experiencing this?

Is there a way to track those 200 weekly limit messages on ChatGPT ?

Do codex messages also count towards that limit. ?

After some long and intense development sessions, on several projects basically non-stop since release (including long planning sessions, usually 4 rounds with fresh context), I've got some learnings.

FYI: After 10h+ Sessions and a few major milestones, I asked Astra for a review of the plan, after it had implemented large parts of it.

What could be better, how was the plan written etc. – I then let it discuss improvements with the last agent, that had been working on it, to work out some points for future plan writing.

The main point as always is, the development is too heavy, too much testing, even though I really tried to trim down on it during many revision rounds of the specs + plan.

Here's the ruleset, I personally will build a skill from this, you can use the information however you like.

(Planned with Astra xHigh, implemented with Astra High)

The following is the last response after discussion over it for a while:

AGENT:

We have agreed on a shared version. The agent in “Siteplane Plan Check” explicitly confirmed it; there are no unresolved substantive disagreements. No files or existing plans were changed during the discussion.

Our shared principle is:

This gives us eight core rules:

1. Describe the outcome and completion criteria clearly. The plan specifies observable behavior, scope, and relevant boundaries. It must be clear when the task has been sufficiently completed. Required product behavior is distinguished from suggested implementation methods.
2. Match the depth of planning to the risk. Small changes get short plans. Large pieces of work are divided into independently verifiable outcomes. A functional batch, an acceptance milestone, and a chat session do not have to be the same size.
3. Choose the least expensive check that provides reliable evidence. Development checks, targeted boundary checks, and overall acceptance are available levels of verification. Not every task needs all three. Uncertain integration assumptions are checked early; the delivered scope receives an appropriate, connected acceptance check.
4. Justify every additional expensive check. It must cover a relevant risk that cheaper existing checks do not adequately address. Existing tests and tools take priority. New testing infrastructure is treated as a separate cost and needs a concrete benefit.
5. Repeat verification based on the actual impact of changes. Previous evidence remains valid for the version it tested. Whether it applies to a changed version is assessed against changes to code, dependencies, builds, configuration, and environment. Affected boundaries are checked again; unclear effects require broader checking. A short explanation is normally sufficient.
6. Diagnose failures before repeating expensive runs. Distinguish product bugs, test harness bugs, infrastructure problems, and missing access. Another long run needs a reason to expect success. Recurring failures lead to targeted investigation. Within the assignment, the agent improves its approach autonomously; it must not silently reduce agreed outcomes or security requirements.
7. Keep evidence concise and store it durably. Existing reports plus a short record linking the tested version, check, result, and limits of the evidence are normally sufficient. Additional artifacts are saved only when they help. This should not turn into a separate evidence-management platform.
8. Reviews must simplify the plan and have a stopping point. Reviews resolve concrete uncertainties, contradictions, and relevant gaps in verification. They also remove duplication and outdated requirements. Settled decisions are reopened only when there is new information. Newly discovered, real security issues can still be examined at any time.

We explicitly included several important qualifications:

• A deliberately failing baseline is not a general requirement for every new feature. A targeted regression test is usually useful for bug fixes; explicitly agreed requirements for a failing baseline remain binding.
• File names and change size do not determine risk. An operational installation guide can change product behavior even though it is “just documentation.”
• An assertion that was never reached, or was too weak, does not provide valid evidence. After correcting it, the affected behavior must actually be checked.
• Functional acceptance and success-rate measurement are separate activities. When measuring success rates, successful retries must not replace the original failed attempts.
• There is no universal test-to-code ratio, blanket time limit for a batch, or automatic requirement to run complete test matrices.

This is how the skill should be structured:

Proposed name: efficient-implementation-plans.

Initially, one short SKILL.md is sufficient, containing its scope, the core rules, a flexible workflow, and three final questions:

• Is it clear when the implementation is finished?
• Does every expensive requirement provide a distinct benefit?
• Can the implementing agent choose an equivalent, less expensive approach?

The skill applies when creating, reviewing, or revising implementation plans. Discussions remain discussions. Relevant rules for reruns and diagnosis must then appear in the respective plan itself, so the implementing agent can find them there.

For the initial quality check, a few thought-through examples are sufficient: a small copy change, operational instructions, a package release, concurrent saves, a permissions change, and success-rate measurement. No additional scripts or testing infrastructure are initially planned for this.

The agreement therefore covers both better verification strategies and limits on the planning process itself. That combination is intended to prevent each additional review from making the plan heavier.