Guys, I understand there’s issues with teh reasoning encrypted streams and the sol/terra pattern vs the Luna pattern, but it DID work with a pretool use hook override and it was exceptional.
Now, there’s basically no way to use Luna and its incredible commercial effectiveness with main agents running on Sol/Terra.
Can we get an indication as to when Luna will either be upgraded to be multi_agent_v2 compliant, or please consider removing the change you made to stop us from forcing it.
Did you find any workarounds? Right now I’m using the CLIProxyAPI and Claude Code but that seems like a very hacky alternative.
I believe this has now been fixed! As I understand it, Luna is back inside Multi-Agent V2 
Actually… spoke a little too soon. It looks like Luna can be invoked in a multi-agent-v2 tree… but it DOES NOT HAVE the collaboration. surface, so it is incapable of spawning further subagents! Thats… not going to fully solve things sorry guys ><
Yes, since last week Luna agents can be used in the v2 multi-agent setup in Codex.
I created a post about this here:
The question I have, @johnbernardcosgrove, is how you used Luna agents as little peer collaborators. I’m asking because the guidance has always been that these models simply aren’t capable enough to do exactly that.
So, the collaboration.* surface can be as simple as allowing a runtime to pass down another trivial item to the model below it. There are reasons why you may want this in swarm optimisation - even splitting a task and cascading is easy. This is a pattern that even things like GPT-4o could easily handle, so long as the scope was sufficiently tight.
What I’m suspecting is that the overall context load from the Codex harness is a pretty big stretch for Luna - askign it to also remember how to use the collaboration surface tools and what to do while in the wait_for_threads mode is the tricky bit. But, I feel pretty confident that if you could give her a very very clean context window (which would mean a custom harness rn), she could handle basic splitting, with very strict task parcelling.
Yes, that makes sense.
I think what you are looking for is to instruct the orchestrator to fork the conversation when spawning subagents. That way, the full reasoning chain is omitted. It also saves tokens because otherwise the orchestrator will simply create a copy of itself using a less capable model.
so, in my case, I have a full hook and agent toml rig configured to avoid this Strongly typed subagents and swarms FTW Personally I think Luna is a fantastic small model and incredibly good value for the cost - I think we just need to get the teething issues ironed out with the multi-agent-v2 and the new reasoning inheretance stuff so we have simple booleon switches for every sub-component of the system, and then it won’t matter what type of model you use where in the subagent tree.
Honestly, I think the real strength of MAv2 is the messaging protocols, including the abstraction of compute from message. Just impatient to get it bedded down so we can configure our own switches.
Luna is now documented as an option for scoped subagents: https://learn.chatgpt.com/docs/agent-configuration/subagents. Thanks for clarifying that your remaining issue is delegation from the child itself. We can share that distinction with the product team; we don’t have a timeline.