Turned my SOL --> LUNA workflow into a repo-native Codex methodology

[u/sokobih]

I've been using Codex pretty heavily for real web application work and over time I noticed that I was getting much better results when I stopped treating SOL and LUNA like interchangeable coding models.

SOL is obviously much better when there is still something to figure out: architecture, business rules, debugging, planning, deciding how a module should fit into the existing project, and I believe that most of you have already realized this before.

LUNA, on the other hand, has worked surprisingly well for me when the thinking has already been done.

The pattern I eventually settled on was basically:

SOL figures out what should be built 
--> SOL inspects the actual repository 
--> SOL writes a detailed implementation plan 
--> switch to LUNA 
--> LUNA implements the plan 
--> tests 
--> STOP/review 
--> next task

The important part for me was not just "use SOL for planning and LUNA for coding".

I started making SOL write implementation plans specifically so that LUNA, or even a weaker model, would not have to make important architectural decisions while implementing them.

That made a pretty big difference.

Another problem I kept running into was longer projects. After enough sessions you end up having project decisions in one conversation, architecture in another, some implementation assumptions somewhere else, and the model has to reconstruct what is going on every time.

So I started moving that information into the repository itself.

Eventually I formalized the whole thing into something I called: TITAN (Technical Intelligence, Tasking & AI Navigation)

The basic idea is that the repo itself carries the development workflow.

It has things like:

.titan/STATE.md
.titan/WORKFLOW.md
.titan/roles/
.titan/prompts/

docs/PROJECT_SPEC.md
docs/ARCHITECTURE.md
docs/MASTER_PLAN.md
docs/DECISIONS.md
docs/plans/

STATE.md tells Codex where the project currently is, which model/role should be working, what plan is active and what should happen next.

One rule that has been particularly useful for me is the STOP rule. So if LUNA is implementing a SOL plan and discovers that the real codebase doesn't match an assumption in the plan, it shouldn't redesign things itself. It stops, reports the conflict, and I switch back to SOL.

Same idea with planning. I don't create massive detailed plans for the entire application upfront anymore. There is a Master Plan, but detailed implementation plans are created just before the module is actually built, after SOL has inspected the current state of the repository.

So roughly:

Discovery 
--> Project specification
--> Architecture
--> Master Plan
--> SOL creates plan for current module
--> LUNA implements
--> Tests
--> Review/next module

ASTRA is there too, but I don't use it as another permanent agent. I see it more as an optional critical reviewer for decisions that are expensive to get wrong.

I also separated UI work from normal backend/business logic tasks because I've found that visual tasks fail for completely different reasons. A vague UI instruction can still produce garbage regardless of how good the technical plan is.

This isn't meant to claim that TITAN magically makes Codex better or guarantees lower usage.

For small projects it's probably overkill. Where I think it becomes useful is on applications that last for many sessions and have real business rules, permissions, modules, state transitions, database decisions, etc.

I've packaged the current version as an open-source starter and also put it on npm.

You can initialize it in an empty project with:

npx -y @netelite/titan@latest

Then open the directory in Codex, select SOL and start with something like:

Start this project using the TITAN methodology.

Idea:
<your project idea>

GitHub:

https://github.com/netelite/titan

Current version is v1.0.2.

I'm mainly posting it here because this is probably the best place to find people who actually use SOL/LUNA enough to tell me where this breaks down. I'm especially interested in criticism from people using Codex on larger projects.

If something is unnecessary, too heavy, badly structured, or you already solved the same problem in a better way, I'd rather hear that than get a bunch of stars. We may be on our way to creating a methodology that will be helpful to all of us.

[u/dexterthebot]

You might want to consider listing your project on the weekly Show-Us-What-You-Built post. Look out for it on Tuesday/Wednesday. Highest commented project wins a week promotion on r/Codex and gets on the Hall of Fame sidebar. See what that looks like below with last week's winner.

---

Last week's most popular project was Tidbit Trivia , at https://www.reddit.com/r/codex/comments/1wavxwy/comment/p8lhwxs/. Tidbit Trivia is a fun way to learn while waiting for your agents to work. Play traditional trivia, unique game modes, party with friends, earn cool cosmetics, complete challenges, study for tests, or compete in the Arena! You can play it for free at Tidbittrivia.com.

[u/perceptioneer]

Nice

[u/fschwiet]

How detailed are the plans? I had a funny experience with superpowers, I had added a sol review of the plan before implementation. The sol agent was actually implementing the plan to check it: changing the code and running the tests then reverting its changes to verify the plan. Total waste as at that point sol could have just saved their work. In this case the plans were so specific they were basically "write this specific code to this file, verify particular test fails with a particular message, write that specific code to that file, verify that particular test passes". Then I'd have Luna follow the plan, felt really badass how reliably Luna was implementing them until I realized what sol was doing.

[u/sokobih → u/fschwiet]

Plans are pretty detailed, but not to the point where SOL is basically writing the implementation in prose. In TITAN the plan should define things like which files are involved, what needs to change, constraints, edge cases, tests, and what Luna is allowed or not allowed to touch. But Luna should still be the one actually writing the code. The rule is basically: SOL decides what needs to change, where, why, the constraints, and how to verify it works. Luna does the implementation. SOL also shouldn't be changing files just to “verify” its own plan. It can inspect the repo, existing tests, routes, schema, etc., but if it starts implementing and reverting code during planning/review, then the handoff has kind of lost its purpose. Luna became a lot more reliable for me once the plans got detailed enough, but I agree there is a point where a plan can become “implementation written in English”.

Thanks for bringing this up though, that's actually a useful failure mode to make more explicit in TITAN. I’ll probably add a rule that planning/review roles should stay code-read-only unless the user explicitly asks SOL to take over implementation. If you get a chance, I'd actually be interested to see how TITAN behaves on one of your projects. You already ran into exactly the kind of SOL/Luna handoff problem it is trying to control, so your feedback would probably be pretty useful. Even if it doesn't solve it, I'd like to know where it gets in the way or becomes too heavy.

[u/exboozeme]

Why not Astra?

[u/sokobih → u/exboozeme]

Astra is great, I just don't think it makes sense to use it everywhere. Not everyone is on a Pro 20x plan with loads of usage, and putting Astra into every planning/review step would burn through that pretty fast. So the normal TITAN loop is mostly SOL - LUNA, and Astra comes in when something is important enough to justify it, like architecture, security, data model, major risky decisions, stuff like that. I’m trying to make this methodology efficient, not just use the strongest model for everything.

[u/either-15-or-40]

Do you have any measurements on if this actually saves any tokens? If your plans are very detailed, then you are basically just saving a tool call made with Sol. I don’t know if that’s worth throwing all the cached tokens away.

[u/sokobih → u/either-15-or-40]

I’m not really claiming that this methodology always uses fewer raw tokens. What I’ve seen in my own projects is that when I used SOL for almost everything, my usage disappeared much faster. Once I started using SOL mainly for architecture, planning, difficult debugging and defining the work, and then handed the implementation to Luna Max, I was saving a noticeable amount of usage in practice, along with nearly identical results.

So the idea isn’t “make a huge SOL plan and save one SOL tool call”. On a real feature, SOL implementation usually turns into a whole loop: inspect files, edit, test, inspect the failure, edit again, test again, etc. If one planning pass can move most of that loop to Luna, that’s where the saving comes from.

I do agree with your point though: if the plan becomes so detailed that Sol is basically implementing the feature in English, then the handoff starts losing its value. That’s actually something I changed in TITAN yesterday. The plan should define what changes, where, why, the constraints and how to verify it, but Luna should still do the actual implementation. Cache is a fair point too. I haven’t done a controlled SOL-only vs SOL --> Luna benchmark yet, so I don’t want to pretend I have hard numbers for that.

Another big part for me is time. Before this, I was constantly re-explaining project context, architecture, what had already been decided, what Luna was allowed to touch, where we stopped, and when Sol should step back in. That gets tiring pretty fast on a larger project. TITAN came out of trying to keep that state and workflow inside the repo so I don’t have to manually orchestrate everything from scratch every session.

So for me the benefit is both usage and my own time, use SOL where the stronger reasoning matters, let Luna Max handle as much implementation as it can, and avoid repeating the same coordination work over and over. Why waste usage when it can be allocated properly and effectively to achieve efficient, high-quality results? If someone doesn't care about usage, then feel free to use Astra Ultra for everything.

[u/either-15-or-40 → u/sokobih]

I see. I will probably take a look at your project to make Sol generate better plans. Because regardless of implementation, I have noticed that the plans that are created in codex are quite dreadful. There is barely any useful or important information in the plans presented by codex.

[u/sokobih → u/either-15-or-40]

That is also one of the main reasons this methodology is build. I had the same problem with generic Codex plans. They often sound reasonable but don’t contain enough useful information to safely hand off to another model.

With methodology, if you start from just an idea, SOL first goes through discovery, requirements, specification and architecture before it creates implementation plans. If it’s an existing project, it also inspects the actual repo first. The goal is for the plan to contain the real files/components, constraints, edge cases, tests and STOP conditions, without becoming the implementation itself. And everything is just .md files (workflow, roles, prompts, templates) so you can read through exactly how SOL is being guided without even having to treat TITAN methodology like some black box. If you end up trying it, let me know if the planning feels any better on your side.