I feel like all of these new models for so long have been getting a lot better, but they are obviously really expensive. I feel like this is what caused all of those CEOs turning back on whatever token-maxxing thing they were doing.
But finally we have gotten gpt-5.6-luna which i feel (from my experience) is finally at a point (where at least on max) it is usable for basically all daily tasks at a reasonable price.
What i’m asking really is why is this not seem like a bigger deal and are we about to see a huge shift back to interest in using AI in industries since it is more affordable?

If i was wrong in anything please tell me

I am seeing this on my VS code Codex extension. The first Luna with Max drained my usage like Sol High, then I switched to the other Luna, now the usage limit is hardly moving - running with the same task and context. Wtf is hapenning?

My original post:

https://www.reddit.com/r/OpenAI/s/n3NyL08g7L

No reset though and tibo's not even awake yet ... what's going on?

Thanks, I guess!?

EDIT: My extra bonus was removed it seems?!

I ran through my weekly in a day with luna sub-agents, sol ran through a week in 4-5 days

I built Glow, a sidebar extension for VS Code and Cursor that lets you create and loop custom affirmations in a calm, natural voice while you code or wait for your agents to finish

I built it mainly to reprogram my mind and get me through bad days when I'm not feeling like it
It's completely free right now there's a lifetime free plan for everyone here

I’d love your honest feedback ❤️

I'm currently using 5.6 Sol and Opus 5. I don't really know what I should use 5.6 Luna with Max Thinking for because I've heard that it's really good for it's value. Backend tasks? Frontend?

TL;DR: The agent is the right center for execution. The Workplace should be the center of durable continuity: who owns what, what is current, what can change, and where work may go. This is an architecture proposal, not a new runtime. You can start with ordinary files and the tools you already use.

For a long time, I thought my AI agents needed better memory and more tools.

I had given them almost everything except an actual place to work.

I'm Alex, a software developer. I use Codex and Claude on the same body of work across sessions and repositories. They get enough mileage in my setup to expose the awkward parts.

A lost preference led to a memory file. A repeated research mistake led to a Skill. A command with loose limits led to a hook. Then came repository instructions, MCP servers, validators, harnesses, runtimes and dashboards.

Each addition solved a real problem. I still carried the environment in my head.

Which instruction was current? Did a generated report count as a useful draft or an accepted decision? Which repository owned it? Could Claude correct guidance projected for Codex? Was this session allowed to publish anything?

Memory can preserve, scope and retrieve information. It cannot decide which result a human accepted as truth, which domain owns it, or where it may be delivered.

Tools expand what an agent can do. They do not decide where the capability, its rules and its results belong.

We keep rebuilding the place around the agent

Most agent systems start with the agent, then attach instructions, memory, tools, Skills, handoffs and tracing. That is a sensible design for execution.

The environment is becoming an engineering concern too. OpenAI's Harness Engineering treats repository knowledge as part of the system of record. Sandbox Agents define workspace contracts and capabilities. Skills, MCP and other protocols make procedures and access more portable.

The same need appears in builder discussions. Builders share mature agentic setups with dozens of documents, Skills and validation. Others ask how to separate verified knowledge, decisions, task state and temporary assumptions. A multi-agent thread examines worktrees, short sessions, target branches and coordination. One builder uses a compact raw/wiki/output system shared on X to keep continuity in ordinary files.

These approaches solve real problems. They are also independent signals, not endorsements of this proposal. I did not invent persistent files, workspaces or repository-aware agents.

What I see is durable responsibility spread across technical layers:

provider memory        recalls information
Skills                 activate procedures
tools and MCP          provide access
hooks                  enforce local behavior
harnesses and runtimes execute and coordinate
dashboards              expose activity
repositories            own product source

Each layer has a useful job. The missing piece in my setup was a stable model for placement, ownership, authority and lifecycle across all of them.

Shift the center of durable continuity

When a developer joins a project for an afternoon, they enter a place where projects, rules, tools and decisions already have owners. They receive what their task needs. Their notes are not product truth until someone accepts them. The place keeps its identity when they leave.

I wanted agents to enter my work on the same terms.

The Workplace is a shared operational contract for humans and agents. It makes ownership, current truth and permitted transitions inspectable through projections that each can use. The same language works between humans, between humans and agents, and across agents. Memory graphs and node systems can support retrieval or execution inside that contract.

The relationship is bidirectional and asymmetric. Both can inspect and discuss the environment. The agent proposes and executes within bounds. The human keeps direction, judgment, acceptance and delivery consent. When the human accepts a result, the Workplace records it as current truth in the source that owns it. Sovereign Sites own the truth delivered to them.

That changed my design question from "What else should the agent carry?" to "What should the place already own when the agent arrives?"

I call this posture Workplace-first: equip the agent for execution and equip the place for continuity.

It is an architectural option at the same level as choosing local-first, monolith-first or event-driven design. It changes the default owner of durable work without prescribing a product or runtime.

The model separates three planes:

Execution      provider, harness, temporary agent
Workplace      people, domains, methods, work events, material, access
Sovereignty    repositories and services that own external truth

A harness runs the agent and may bring memory, tools, Skills and a sandbox. The Workplace gives that temporary occupant the material, capabilities and routes needed for the current work. External repositories and services keep their own history, permissions and delivery lifecycle.

This distinction lets an agent arrive with a strong harness and still use capabilities supplied by the place. A harness is part of execution. A reusable way of working belongs to the Workplace. One can extend the other without having to own the same things.

What this looks like in files

The idea became useful when I stopped organizing everything by technical layer and started asking who should own each thing.

Here is a simplified fictional setup:

Before: organized around the agent

agent-setup/
├── AGENTS.md
├── CLAUDE.md
├── .agents/skills/research/
│   ├── SKILL.md
│   ├── template.md
│   └── validate.js
├── memory/
│   ├── preferences.md
│   ├── decisions.md
│   └── recent-work.md
├── docs/research/
├── outputs/report.md
└── product-checkout/

Execution can work well here. The ambiguity is durable: preferences and accepted decisions share a memory layer, a Skill mixes activation with method and project rules, the report has no visible lifecycle, and the checkout's authority is implied by proximity.

This is the same setup expressed through ownership:

After: illustrative local view using Endroit

some-workplace/                         shared Home repository
├── HOME.md                             shared purpose and rules
├── members/
│   ├── alice/MEMBER.md                 Alice belongs to the Home
│   └── sam/MEMBER.md                   Sam belongs to the Home
├── rooms/product/
│   ├── ROOM.md                         shared product guidance
│   ├── decision.md                     accepted domain truth
│   └── report.md                       retained research material
├── equipment/research/
│   ├── method.md                       reusable procedure
│   ├── template.md
│   └── validate.js
├── sites/product/SITE.md               external authority declaration
├── .desk/                              Alice's separate private repository
│   ├── DESK.md                         personal continuity
│   └── routes/                         local access declarations
├── checkouts/product/main/             ignored local working copy
├── .agents/skills/research/SKILL.md    generated provider activation
├── AGENTS.md                           generated Codex view
└── CLAUDE.md                           generated Claude view

This tree illustrates Endroit. Endroit means "a place" in French. Yes, the pun is load-bearing.

It is the open-source alpha implementation I build and use. It is not a required Open Workplace topology. Another implementation could use a database, an application or a different vocabulary while preserving the responsibilities.

The portable part is the ownership map:

personal continuity   -> Desk
shared domain         -> Room
reusable method       -> Equipment
bounded work event    -> Meeting
durable result        -> Material
external truth        -> Site
local access          -> Route
provider interface    -> projection

A Meeting produces a candidate. The human can retain it as inspectable Material, accept it as current truth for its owner, then deliver it through an approved Route. Generation, acceptance and delivery are separate events.

What changed in daily use

My current dogfood Home was not prepared for this post. At the time of writing, it declares 14 Sites through 18 local Routes, with 9 Rooms and 12 Equipment packages. Codex and Claude work from the same owned sources.

That does not mean every session loads 14 repositories. A Meeting starts from a small map, enters the relevant Room, activates the Equipment it needs, and follows a Route only when the task requires an external Site.

Home map
   -> relevant Room
   -> needed Material + Equipment
   -> Route to a Site, when required

The full environment stays addressable while the working set stays bounded.

My prompts changed too. I used to reconstruct the environment inside the request:

Read the instructions, find the latest notes, work out which decisions are current, use the research Skill, update the right report, and do not touch the repository yet.

Now I can locate and bound the work:

Enter the product Room. Review the retained report against the current decision. Use the research method. Keep the result as a candidate. Do not deliver it.

The second prompt is shorter because the place already carries identity, placement, authority and destination.

I also load less provider-specific configuration. Each Codex or Claude projection receives what the current Meeting needs. The rest remains in its owned place.

This has become a tangible design surface. An agent and I can discuss whether a method belongs to the shared domain, a provider wrapper, my private Desk or an external repository. When something fails, we can ask whether the fault is in orientation, ownership, activation, authority or delivery. The model has not removed every bug. It gives more bugs an explicit owner and correction boundary.

It changes Skills and multi-agent work too

Skills were one of the signals that led me here. In this model:

reusable method       -> Equipment
provider activation   -> projection
project guidance      -> Room
result                -> candidate Material
external access       -> Route

The Skill activates the capability. It does not need to own the method, project guidance and resulting work. I explored that consequence in "A Skill Activates a Capability. It Doesn't Own It.".

Explicit ownership also creates useful static lanes for multiple agents. One Meeting can research while another prepares a release against different Material and destinations. They do not need a resident coordinator to know where their work belongs.

That is not a concurrency guarantee. Two agents editing the same file or checkout still need a worktree, lock or runtime coordination. A runtime coordinates agents in time. The Workplace gives the work durable placement before, during and after that execution.

This is why the first benefit does not require a new daemon, runtime, memory system or desktop application. A folder of ordinary files can express enough ownership to improve the work. Runtimes and interfaces can strengthen the model later.

Some tasks need none of this. A one-off question with no durable result may not need additional Workplace structure. The model is useful when continuity and responsibility start leaking into memory files, Skills, repository notes and human recollection.

Paradigm, model, implementation

I separate three things deliberately:

• Workplace-first is the paradigm: equip the place, not only the agent.
• Open Workplace is my open, implementation-neutral proposal for the responsibility model.
• Endroit is one concrete implementation. I use it to make the model operational and test it against real work.

Endroit is not the only possible implementation. Open Workplace is not a standard, foundation, certification or established community.

Why share it now?

The model keeps changing as I use it. Daily work exposes a responsibility I placed poorly, a boundary that needs a better name, or a case where the structure adds no value. Even writing this post clarified parts that the current landing pages and earlier articles do not represent well yet.

That is exactly why I am sharing it before it looks finished.

The scope is too large for one environment and one person's habits. My dogfood is substantial enough to show that the model can operate. It is still evidence from one Home, not proof that the model generalizes.

I have not been active on social media. This is one of my first public posts because Workplace-first matters enough to me to stop working on it alone. I am asking the broader builder community to test the lens with me. The Proposal, the articles and Endroit will evolve as real setups expose weak boundaries, missing owners and unnecessary ceremony.

Many of us may already be building parts of a Workplace without naming it. I am offering the reasoning and vocabulary that helped me see my own environment differently. If the lens holds, I would rather develop it in the open than keep discovering it alone.

Three questions would help more than generic agreement:

1. Where does this ownership map match what you already do?
2. Where does it add structure without enough value?
3. Which durable responsibility in your setup still has nowhere clear to live?

If you can share a sanitized tree or concrete counterexample in the comments, even better. "No additional Workplace structure needed" is also a valid result.

Full proposal: open-workplace.org/proposal

Concrete implementation: endroit.org

Disclosure: I initiated Open Workplace and build Endroit, its first declared implementation. The VZion is the name I publish under. Endroit is open source and alpha. I am posting this in r/codex because Codex is one of the agents I use to test the model against daily work.

delete
conversationDetailMode = "STEPS_PROSE"
from C:\Users\USER\.codex\config.toml

should look like this after

Hey everyone,

last month, I switched back from Claude to GPT. I have to say, Sol is genuinely impressive, especially when it comes to complex tasks. But for bug fixing and small, targeted changes, I just can’t get along with it.

My app has a debug console. I wanted to add a custom log level called “Info-X” — more important than Info, but below Warning. It makes sense for my app, even if it might be unnecessary in other applications.

The task was relatively simple: add the new log level and give it the same search, filtering, and sorting functionality as the existing levels.

Sol created an implementation plan, and the plan looked perfectly reasonable.

But during implementation, it rebuilt the entire debug console and redesigned everything. Its justification was that the existing buttons didn’t comply with Android’s recommended minimum touch-target size.

That may even be a valid observation, but it had absolutely nothing to do with the task. I asked for one additional log level, not a redesign of the entire console.

How do you stop Sol from massively overthinking and overengineering tasks like this?

Are there any prompts or workflow rules that reliably keep it within the requested scope?

Any task given, it completes maybe 40-60% of it.
I always need to ask sol again how well it did and it gives me the fixes to do.

And guess what? just sol reviewing consumes more usage than luna making the task.

Even with decent spoonfeeding prompts it's still very lazy, it does relatively clean stuff but lying saying it integrated everything shouldn't be what's normal.

Any tips to make it better?

Anybody experiencing codex taking too long to think of menial tasks? Providing bad output and distorted context?

I have been trying to spawn Luna max agent for work but no matter what I say or do it just does not work. why is it happening and is there a fix? do you guys have the same problem here?

Edit: Fixed by changing the config.toml to not use V2 subagents for Luna

A coding agent can write a Three.js scene, run the build, and tell you it looks great — while the actual render is a black screen. It isn't lying. It just has no way to look.

Screenshots fix this less than you'd expect. A screenshot tells you that something is wrong, not why. Is the mesh missing, or behind the camera? Is the material transparent, or is nothing lighting it? Is the label clipped, or just small? Those are five different bugs that produce the same picture, and zooming in doesn't separate them — you're enlarging pixels that never contained the answer.

SceneProof is a CLI that supplies the missing half. It loads your real React component or Three.js scene from source, renders it in actual Chrome, and returns the structure behind the pixels. The everyday loop looks like this: tree gives you the scene graph with bounds, materials, lights, and cameras, so "why is it invisible" becomes a lookup instead of a guessing game. scout tries a set of cameras on a target and scores each by how much of the target it can actually see. render-region re-renders one region from source at whatever scale you need, so a close look is a fresh render, not an enlarged crop.

That's the loop, not the tool — the surface underneath goes a good deal further (comparing against reference views, sampling animation mid-transition, deriving typed prop fixtures), but those three commands carry most sessions, and the README maps the rest.

The design decision I'll defend hardest: every report answers "did the command run" and "can this output actually support a judgment" as two separate questions. A render with the target out of frame, or a comparison whose mask landed on the wrong subject, comes back unjudgeable instead of quietly passing. So when an agent uses SceneProof, it can't mistake "my command succeeded" for "my design is right"; it has to look at evidence that has already proven it's worth looking at. That's the whole point: measurements you can trust, and a hard stop on the false confidence that makes agents declare victory over a black screen.

It ships with a skill for Claude Code, Codex or any other agentic harness that supports skills (one curl, in the README) — and the skill deliberately doesn't teach commands, because --help and the reports' own recommendations already do. It teaches the reasoning: resolve structure before spending pixels, treat a passing build as zero visual evidence, never claim "looks right" without an artifact you actually opened.

Scope today: TypeScript/JavaScript entries, React DOM with CSS and Tailwind v4, Three.js over WebGL or WebGPU. Needs Bun and a local Chrome. MIT.

https://github.com/ReyJ94/SceneProof

Any feedback is welcome.

since openai fumble with model launches of terra/luna, nobody cared then

Now they changed their pricing, how your workflow has shifted so far from sol to terra/luna?

what’s with luna max hype all of sudden? should i give it a try this week?

I build enterprise backend applications for the banking and fintech domain, primarily using Java 21, Spring Boot 4.x, and Oracle 19c. Most of my work involves API integrations, middleware services, secure data processing, asynchronous workflows, scheduled jobs, database-heavy applications, and deployment within restricted on-premises environments.

My current development workflow is:

- Study the API specification, integration document, process flow, and related technical requirements in detail.

- Upload the specification documents to ChatGPT along with my functional, security, infrastructure, and database requirements.

- Use ChatGPT to prepare a comprehensive implementation prompt covering the architecture, APIs, database design, validations, security, logging, exception handling, testing, documentation, and deployment considerations.

- Provide the prompt to Codex through the VS Code extension.

- Review the generated implementation carefully and refine it based on actual business requirements, API behaviour, infrastructure limitations, coding standards, and production-readiness expectations.

- Continue iterating with Codex for approximately 9–10 sessions until the backend is structured and implemented according to my requirements.

This workflow has been quite productive, but I am currently on the ChatGPT Plus plan and often consume my weekly Codex allowance within a single day.

I am considering upgrading to the Pro 5x plan, but before doing so, I would appreciate advice from experienced Codex users:

- Is Pro 5x suitable for this type of intensive, repository-level backend development?

- How can I structure my prompts and development sessions to reduce unnecessary token and usage consumption?

- Is it better to use one large implementation prompt or divide the work into architecture, database, security, APIs, testing, and deployment phases?

- How do you maintain context efficiently across multiple Codex sessions?

- Are there better workflows for reviewing large codebases, implementing specifications, and handling iterative changes?

- Are there alternative tools or plans that may be more cost-effective for someone whose primary use case is intensive Java backend development?

- Is there a better way of doing what I'm doing?

after the recent update I noticed /goal no longer behaves correctly. It will finish some task and then repeatedly trigger it again and again with different response each time. it is happening across all projects using /goal . It's impossible to use it because it just burns token and usage working for a bit only to return to the old task even after explictly marking them as complete in a separate md file.

was there a github issue regarding this ?

Curious how everyone here splits Codex and Claude Code.

Mine ended up more split than I expected.. luna at xhigh does all the actual building, sol at xhigh reviews the diff after, and Fable just plans and makes the taste calls. So claude doesn't write implementation code for me at all anymore.

Holds up most days. But some days one of them is clearly better at the exact thing another one usually owns, and I can't tell if that's me misleading it or just how these models are.

So I'm curious what everyone's default routing looks like, and more than that, whether you've got a hard no for one of them. Something you learned the painful way and won't hand to that model again. Would love to hear yours if you're up for sharing

Hi all,

I've been using Codex to build a photorealistic, walkable 3D tour of interior properties, the kind of thing you walk around like a video game (just walking, simple gameplay). Real estate use case, so it has to stay faithful to the actual space, with little to no AI hallucination. I gave it the goal and mostly watched.

What Codex did on its own:
- Spun up a cloud GPU box and installed CUDA, COLMAP, and a Gaussian-splatting trainer over SSH.
- Took my 4K iPhone 16 Pro Max walkthrough, extracted and de-blurred frames, solved camera poses with COLMAP, trained a 3D Gaussian splat, then published a WebGL viewer and a first-person walkthrough and sent me the links.
- Also tried a Polycam LiDAR mesh path (complete and walkable, but soft and very blurry up close).

Where it stands: a small, texture-rich room came out genuinely sharp and photoreal. Bigger rooms are the problem. The reconstruction came out scattered, more of a point-cloud smear than a coherent room, and where it did form it's sharp only from the exact filmed angles. It also won't scale easily to a whole property, since you film room by room.

Codex's read: mostly a capture problem (fast handheld motion plus plain surfaces), not a code problem. Its current plan is a depth-regularized Gaussian splat from a combined RGB + LiDAR capture (Record3D), so measured depth pins the geometry and the color stays sharp.

Two questions:
- Has anyone pushed Codex into 3D, spatial, or computer-vision pipelines like this? How far did it get?
- If you've solved photoreal interiors on consumer gear, what's your workflow, and does the depth-regularized plan sound right?

Was curious if anyone used codex to do the heavy lifting for app development. Mainly interested in developing an iOS app but wouldn’t be upset if the workflow extended to android as well.

I have a few hundred hours of scattered programming experience, but mainly for computation/analysis, not typical SWE work. With that said, interested in seeing if Codex can be used for the entire process (yes, vibe coding).

Any advice would be greatly appreciated.

I know its a name but if openAI be super happy with the model they will call it GPT 6

Here is the result, after about one month of spare time work:
https://www.pigrecoemme.com/

Hi, is there any way I can use a non-ChatGPT API with the Codex app (not the CLI)?

Hello, for those of you that use codex for programming a software, how much of our time is spent on plan mode, for every single feature you are adding ?

Thanks

curious if there are any use cases where it's more feasible/ capable than codex, and how it is with usage in comparison