I wonder if they are gonna stop us from using gpt subscriptions in alternative harnesses. If not - that doesn't matter much, codex cli is a remarkably unremarkable harness.
Heh, in another long-standing Codex issue I've been arguing against codex users who apparently don't know about git. Don't tell me you're yet another developer who refuses to pick up any sort of SCM?
It's to prevent collection of queries from users that are coming from resellers/proxies, for reasons of economy or bypassing region blocks etc. The users are using the stock client and may believe they are using direct OpenAI servers.
Could someone explain to me where exactly the encryption is happening?
I assumed that the main agent makes calls to sub-agents locally. Does Codex work in such a way where the main agent makes calls to sub-agents in the backend (openai server) before reaching local?
Sure. "Traditionally", your agent would send a text prompt to the sub-agent, then it goes off doing it's work. In the logs/session data, the clear-text prompt would be there, so if I want to see what's happening, I just browse the data. It's all just clear-text prompts being sent everywhere, even when you were using the experimental "sub-agents" stuff in Codex, before Sol et al was available.
Now, when using Sol or Terra (Luna seems unaffected), instead of the agent sending clear-text prompt to the sub-agent, it sends a ciphertext generated on OpenAIs backend, which ends up being the prompt, then agent sends this ciphertext to the sub-agent, which then continues to use that for further inference to OpenAIs backend. Only delegated inter-agent messages are encrypted, not all session data. Now if you browse the data, it's all encrypted content, that can only be decrypted by OpenAI and their backend.
HN Title is very misleading, it makes it sound like inference is being done directly on ciphertext, which would require homomorphic encryption well advanced of what is known.
It is not misleading, quite literally what's happening is that content the agent sends sub-agents is encrypted in such a way that only OpenAIs backend can decrypt it and actually see the clear-text. Just shared this is another comment that hopefully explains things better:
> Sure. "Traditionally", your agent would send a text prompt to the sub-agent, then it goes off doing it's work. In the logs/session data, the clear-text prompt would be there, so if I want to see what's happening, I just browse the data. It's all just clear-text prompts being sent everywhere, even when you were using the experimental "sub-agents" stuff in Codex, before Sol et al was available.
> Now, when using Sol or Terra (Luna seems unaffected), instead of the agent sending clear-text prompt to the sub-agent, it sends a ciphertext generated on OpenAIs backend, which ends up being the prompt, then agent sends this ciphertext to the sub-agent, which then continues to use that for further inference to OpenAIs backend. Only delegated inter-agent messages are encrypted, not all session data. Now if you browse the data, it's all encrypted content, that can only be decrypted by OpenAI and their backend.
Edit: Re-reading, I think I understand what you mean to be misleading. You're taking "uses ciphertext for inference" quite literally, while I couldn't fit a more nuanced version within the HN title constraints. Yes, the inference at OpenAI obviously doesn't happen over the ciphertext, but from the perspective of the local user, you don't see the clear-text prompt at all, only the ciphertext.
But, please suggest alternative titles that sufficiently explain what the issue is and is more accurate, I'm sure the mods can change it once people come up with better alternatives :)
Agreed, I immediately thought that homomorphic encryption was at play here or some other kind of computation on ciphertext, given the mention of "inferencing" in the title.
The title is a bit confusing, they're not using ciphertext for inference – they're passing ciphertext around in cases where an agent calls into another agent without exposing the plaintext to the end-user
Inference is still done in plaintext after this multi-agent message gets decrypted in the server side
This title seems extremely easy to misinterpret. If I understand correctly: Codex is now encrypting inter-agent communications and hiding those communications from the user.
I imagine this will be because a decent chunk of the IP in Codex is probably within its prompts, how they're built, and how they're sequenced and orchestrated, rather than in the codebase per se.
We had this discussion a few months ago where we talked about allowing people to choose an AI provider and provide their API key, thinking about enterprises with "preferred" (read: mandated) AI suppliers. We also wanted to offer the kind of very simple pricing that this is one way of enabling. But we realised pretty quickly that this would/could lead to leaking our back end prompts to customers and, although those prompts are only a part of the value add, if you could build a detailed trace of them then you'd be able to quickly reverse engineer a lot of what we're doing.
I'm unable to understand how much value can be in low-definability non deterministic prompts. It feels like the kept the right divinity spell into a chest.
I don’t disagree with your divinity spell comparison but unfortunately there is a lot of value in the prompts because these spells are the “programming languages” of LLMs.
yeah i get it too, i'm just flabbergasted that this is today's market
it reminds me of the pre-vulkan game programming days.. drivers were black boxes, game developpers had to resort to magic tricks to do stuff, until everybody got fed up and wanted some logical ground to operate
One does find oneself slightly askance at one's own thinking sometimes, that's for sure.
But I suppose, is it really so different? I mean, back in the day moreso than now, a lot of the valuable IP in any system was in the design and specification of that system - the problems usually solved within the design and specificaion (use X algorithm, etc.) - and the code was "just" the implementation of those solutions.
So perhaps it's more of a regression in some ways: the value is in the specification (the prompt) once again.
Your point about stochastic behaviour is well made though, and there is no way to 100% guarantee or formally verify the behaviour of a system that relies on an underlying technology whose behaviour is fundamentally stochastic.
Further proof that this tech stack is immature and would have needed to bake for a more years.
In an ideal world this would have been public tech like ARPANET or WWW and there would have been 2-3 major iterations (until the equivalent of Claude 7-8) and only then would everyone have tried to build huge businesses on top of it.
I mean, sure, it's sort of usable, but the churn is insane. And we're burning the planet (and probably the economy, too) for it.
It's also not the first time Codex started encrypting stuff. Their excellent compaction endpoint has served up a giant encrypted blob since at least five months ago.
> I don't think the difference between both really justifies the wide gap in pricing
I'd be ecstatic if this was true, but nothing so far comes close to the SOTA models from OpenAI + highest reasoning, but I'd be more than happy to be proven wrong by testing it out myself.
So far, I've tried MiniMax M3, GLM 5.2, Hy3, MiMo-V2.5 (+ Pro), DeepSeek V4 Pro (+ Flash), Gemini 3, Kimi K2.6, GLM 5, all the various Qwen variants and probably a bunch more I forget about, in a wide array of harnesses (Codex, pi, opencode, my own and more), and still nothing seemingly comes close to GPT 5.5 (now 5.6) xhigh for tasks beyond 5-10 minutes of work, they all more or less collapse after a while in my experiments. Although most of those do work well for really tightly scoped tasks.
What specific model are you thinking about here, in case I've missed testing it?
It seems likely to me this was driven by the `ultra` mode in 5.6, which fans subagents to do work. This mode was previously only available in the web UI (what was previously known as pro?)
It seems possible they trained this by doing full RL rollouts of agents interacting with each other. They likely view these prompts somewhat the same as raw reasoning traces, they don't want people to train directly on them.
I am unsure if this has been confirmed, but there are some signs that the opaque "compaction blob" they return from their dedicated compaction endpoint might not be text at all, rather a latent space representation of the conversation. The fact that OpenAIs compaction seems to be much higher fidelity than a lot of other providers makes me inclined to believe this.
If this is true, it doesn't seem far fetched to infer that they might be applying similar techniques to prompting subagents.
I would be curious to see if this way of spawning subagents (encrypted blob) is used when subagents of a different model type is spawned.
I think you hit the nail on the head here. Having subagent dispatch in the loop for RLVR is something we've already seen in open models, like Kimi K2.5 and later, so it's no great stretch to assume OpenAI are doing it too.
If you keep RL'ing the dispatch then the prompts are likely to keep diverging from the type of prompt a person would write (like CoT becoming increasingly incomprehensible), and that divergence is part of their competitive advantage.
"Latent space representation" I have been waiting for this moment in the evolution of AI. Well, waiting with some trepidation. It seems inevitable that frontier AI's will, at some point, leave behind human-comprehensible representations of language. Purely for functional reasons, it's going to start making sense for AI agents to communicate amongst themselves in much more efficient ways than borrowing the languages of flesh-bag humans as an interface medium.
I Imagine next that programming languages, interfaces and API design starts going this direction next. Being written, expressed and optimized as blobs of high dimensional vector space. As humans we might still be able to understand some abstractions of what our AI's are talking about to each other, but maybe not more so then we understand how different regions of our own brain communicate with each other.
I strongly believe that the future is the other way. New programming languages and environments designed for strong auditability and preventing bugs will dominate. Only bad actors will use latent space representation, and it might even be outlawed. But the bad actors will proliferate underground…
Even for like token efficiency it could make sense - like imagine if the representation were more compact
Agents acn already translate languages quite well. It doesn't seem crazy that they could work and think in a model specific language, and then translate back to English or something for the user
It seems like the most efficient method would be for LLMs to communicated by exchanged latent space representations directly. Serial language is a incredibly inefficient way to encode these, a lot like flattening a complex graph into text.
They are not really token-in token-out per se, they are embedding-in embedding-out.
When operating on text, you embed each token into the LLMs embedding space. You go from a discrete token to a point in embedding space.
Likewise, when processing images, you have a image embedding model which produces a set of embedding vectors representing the contents of the image in the LLMs embedding (latent) space.
This same concept can be extended to compaction. Instead if limiting yourself to discrete tokens, you could generate a set of embedding vectors which represent the contents of the compacted conversation in latent space.
These have the possibility of containing a lot more semantic information per vector, which is why this can be appealing.
A big downside is decreased interpretability. AI safety people are generally fairly opposed to latent space reasoning for example, it can be harder to tell what the model is actually doing and if it is trying to deceive you.
If there is no visible prompt at all, then that is very understandable. The PR issue exposes a real gap though: subagent spawns need a human-readable audit trial, of its goals/intent, its boundaries and scope and limitations, etc; for basic responsible agentic harness functionality.
Add? Just make the sub-agents input prompt not encrypted, literally change "encrypted: true" to "encrypted: false" everywhere and everything continues to work as it used to.
They need to fix the regression, not add something new here.
> It seems possible they trained this by doing full RL rollouts of agents interacting with each other. They likely view these prompts somewhat the same as raw reasoning traces, they don't want people to train directly on them.
this tracks. anthropic protects these as well iirc.
> I am unsure if this has been confirmed, but there are some signs that the opaque "compaction blob" they return from their dedicated compaction endpoint might not be text at all, rather a latent space representation of the conversation.
probably not a latent (to my knowledge latents aren't really part of the outer loop in ar-transformer inference processes), but maybe non-human-readable reasoning traces as occurs in fable.
That’s actually what got me to switch and use Codex sometime beginning this year, the compaction via these encrypted blobs was just waaaay better than Claude. I had short convos with Claude where it would forget something very obvious and important few million tokens into a task, whereas I reached ~1B tokens in some local codex sessions and it was recalling and paying attention to things I mentioned way back at the beginning of the session (and not persisted anywhere else in the repo/md files etc)
It's sort of insane though, you not only have dozens/hundreds of stochastic agents running on your machine, but you cannot even inspect the instructions those agents are working off of?
I've gone in to look at Claude subagent/workflows and sometimes been like "no this was a mistake to spin up" ... Codex users just get to token yolo the encrypted telephone operator instructions+shell from orchestrator to subagents?
You already have an agent freely doing stuff on your machine. Subagents prompts are a weird place to draw a line. It's not like you're reading everything the agent is doing in any case, let's not kid ourselves.
When things go wrong I very much read the session traces to figure out what in my prompt wasn't good/explicit enough, then retry to evaluate if it would have helped.
I was about to do the same with Sol + Ultra, but then discovered this encryption issue that prevents me from doing the same for sub-agents.
>but you cannot even inspect the instructions those agents are working off of?
It makes more sense when you realize they don't want developers to be doing any coding at all. That's what they seem to be moving towards. From product manager to product via AI.
Last stage is moving everyone to their cloud platforms, they deploy everything for you, you don't even get to see the code, just the deployed end product.
Because letting you look at the code would be too dangerous, you could reverse engineer an exploit to another product! Or distill their internet-distilled model!
But don't worry, at least it will be very convenient.
Using ciphertext for inference would mean it's not a very secure ciphertext.
These two ideas don't compute for me.
Same thing with homomorphic encryption. I don't get it. If you can gain any knowledge from a ciphertext, you just found a way to exploit the ciphertext to me.
They’re not using ciphertext in inference. They are encrypting agent responses on their servers if it’s going to a subagent on the client. The subagent will send it back to their servers for inference.
Only their servers have the keys, so they can decrypt when running inference.
> Using ciphertext for inference would mean it's not a very secure ciphertext.
Inference is done in plain text. It's just that some parts of the response can be encrypted. While I haven't looked into this specific implementation, here's a short "how I'd do it" if I wanted to implement this:
Before:
[] - encrypted
{} - plain text
1. user -> please do this -> server
2. user <- a) [thinking1] encrypted; b) {answer1} plain text <- server
3. user -> please do this -> [thinking1] (sent encrypted as received) -> {answer1} -> good but do this instead -> server
4. user <- [...] <- [thinking2] ; {answer2}
(here the server decrypts the thinking parts, adds them to the conversation, does the inference, and sends back the new thinking trace (encrypted as well) and the new answer
After:
1. user -> please do this long task -> server
2. user <- [thinking1] ; {tool_agent_spawn([params1])} ; {answer1} (e.g. would you like me to explore or do a quick hack?) <- server
3. user -> please do this long task -> (decides if explore or message) spawn([params1]) / message -> server
3. a) if no explore -> send message as usual
3. b) if explore execute spawn that in turns begins 2 channels
4. user <- [channel_1_thinking] ; {channel_1_answer} ; [channel_2_thinking] ; {channel_2_answer} ... <- server
So the server always does inference on plain text. But it sends the "important" bits encrypted, and you only send those back if you as the user want to (or need to, or choose to, etc). The idea is that the client still gets to decide on "local" things, but the server keeps the important bits from reaching the client. In this particular case, the [params] are encrypted bits that can include prompts, etc.
No normative opinion on whether this is justified or not, but noting that this is only for parent -> subagent spawns/messages, and only for the `multi_agent_v2` feature (currently experimental / off by default).
> and only for the `multi_agent_v2` feature (currently experimental / off by default).
Wrong, this is enabled by default for Sol and Terra (not Luna), no way of avoiding this short of patching the client yourself, and that still doesn't make the backend endpoints work, they want the ciphertext that OpenAI creates on their side.
> but noting that this is only for parent -> subagent spawns/messages
This is almost fully correct though, the encryption only seems to be for the initial prompt the main model sends the sub-agent, not all communication and not regarding the state of the sub-agent at all.
So you can inspect what the sub-agent is doing currently, and the output, but you cannot see what the initial prompt the sub-agent got started with.
Couldn't you just instruct the model to always use your tool call to spawn subagents? Subagents are not some magical thing; it's just another prompt with a couple tool calls for plumbing. One of my colleagues made his own subagent harness earlier this year before codex had them at all.
This is very obviously a countermeasure against distillers, illicit resellers, and the like. The scale and competence of the Chinese black (grey?) market has become a serious threat that can’t be ignored.
> Is it mainly about how the main/orchestrator agent communicates with its subagents ?
Yes
> If desired the user can always see what the sub agent is doing in detail ?
Well, no, that's the problem, you're currently not allowed nor is it even possible, to see the exact prompt the main agent sent the sub agent. This is the problem.
> Isn't it the same in case of claude as well ?
No idea, but if Claude Code makes it so it's impossible to inspect what the sub-agents actually received before they started their work, then I'll say it's similarly impossible to rely on Claude Code if so.
> Multi-agent v2 currently routes agent instructions through normal tool arguments and inter-agent context. That means the parent model can emit plaintext task text, Codex can persist it in history/rollouts, and the recipient can receive it as ordinary assistant-message JSON.
This is the "Why" section, but it's notably devoid of any explanation for why any of these things, which seem like normal useful observability features, are a bad thing that needed to be fixed.
The issue description is overly charitable:
> The encrypted delivery path is understandable as privacy hardening
Whose privacy? The message the parent sent to the sub-agent is now encrypted by OpenAI on their servers. OpenAI has the key. There's no user privacy gained here, only privacy for the details of what instructions were sent to the model, and they carefully avoided explaining why this needed to be encrypted at all.
I guess this implies that non-Codex harnesses get a little bit worse? In wondering what's so special about their subagents system that they feel the need to hide these messages...
Seems fairly obvious what the point from OpenAI's side is (protect what they see as the moat, that a model is "good at spawning sub-agents"), but what's really strange to me is that the team somehow didn't manage to push back on this, it's so clearly disadvantageous to developers who are trying to rely on Codex for real work. For this we need introspection into what exactly is going on, hiding the prompts is just so backwards from what I expect from OpenAI.
> protect what they see as the moat, that a model is "good at spawning sub-agents"
Yes, that is the obvious answer, of course. I was looking for an explanation as to why that would be so special now. They used to not do it until Codex is open source after all. Agent prompts more generally are also not encrypted. This particular change just looks unintuitive to me.
They must think they have some secret sauce they don't want others to learn. How to optimally instruct sub agents for example. If they hide the sub agent prompts, other models cannot be trained to emulate.
Oh and you can't even use local models or other providers for the sub-agents. You're locked-in.
If we're viewing this as a _bad_ thing, I don't really see that it is any different than how Claude encrypts it's thinking. Take a peek at your ~/.claude jsonl files. You're sending thinking ciphertext back and forth to Anthropic. Presumably the thinking is either considered proprietary, or, more likely, leaks embarrassing or confidential information.
> I don't really see that it is any different than how Claude encrypts it's thinking. Take a peek at your ~/.claude jsonl files. You're sending thinking ciphertext back and forth to Anthropic.
I was already only using Claude Code to double-check if it's getting better than Codex, but with things like this, it really isn't even an alternative. What's the point of using a reasoning model if you as an end-user can't seen the reasoning? I don't think I'd be able to work like that at all, I need to have introspection into what the model is doing, and can't believe I have to say this, but also need to be able to see the plaintext of the input prompt...
They always talk about transparency and all but it never was as opaque as it is going on now.
There is no possible audit trail. No possible way to review what happened to validate the result. But even worse, no you will be billed somehow randomly. 20 sub agents started to do something we don't know. No way to now if it was legitimate, if it is just burning tokens or agents doing the same work on loop...
135 comments
[ 3.8 ms ] story [ 59.8 ms ] threadhttps://github.com/openai/codex/blob/main/codex-rs/responses...
Encryption is useful to at least stop the latter.
Ultimately same purpose as a\ ‘s trick exposed earlier, but a much nicer implementation.
I assumed that the main agent makes calls to sub-agents locally. Does Codex work in such a way where the main agent makes calls to sub-agents in the backend (openai server) before reaching local?
Now, when using Sol or Terra (Luna seems unaffected), instead of the agent sending clear-text prompt to the sub-agent, it sends a ciphertext generated on OpenAIs backend, which ends up being the prompt, then agent sends this ciphertext to the sub-agent, which then continues to use that for further inference to OpenAIs backend. Only delegated inter-agent messages are encrypted, not all session data. Now if you browse the data, it's all encrypted content, that can only be decrypted by OpenAI and their backend.
> Sure. "Traditionally", your agent would send a text prompt to the sub-agent, then it goes off doing it's work. In the logs/session data, the clear-text prompt would be there, so if I want to see what's happening, I just browse the data. It's all just clear-text prompts being sent everywhere, even when you were using the experimental "sub-agents" stuff in Codex, before Sol et al was available.
> Now, when using Sol or Terra (Luna seems unaffected), instead of the agent sending clear-text prompt to the sub-agent, it sends a ciphertext generated on OpenAIs backend, which ends up being the prompt, then agent sends this ciphertext to the sub-agent, which then continues to use that for further inference to OpenAIs backend. Only delegated inter-agent messages are encrypted, not all session data. Now if you browse the data, it's all encrypted content, that can only be decrypted by OpenAI and their backend.
Edit: Re-reading, I think I understand what you mean to be misleading. You're taking "uses ciphertext for inference" quite literally, while I couldn't fit a more nuanced version within the HN title constraints. Yes, the inference at OpenAI obviously doesn't happen over the ciphertext, but from the perspective of the local user, you don't see the clear-text prompt at all, only the ciphertext.
But, please suggest alternative titles that sufficiently explain what the issue is and is more accurate, I'm sure the mods can change it once people come up with better alternatives :)
Inference is still done in plaintext after this multi-agent message gets decrypted in the server side
We had this discussion a few months ago where we talked about allowing people to choose an AI provider and provide their API key, thinking about enterprises with "preferred" (read: mandated) AI suppliers. We also wanted to offer the kind of very simple pricing that this is one way of enabling. But we realised pretty quickly that this would/could lead to leaking our back end prompts to customers and, although those prompts are only a part of the value add, if you could build a detailed trace of them then you'd be able to quickly reverse engineer a lot of what we're doing.
So we quickly dropped that idea.
it reminds me of the pre-vulkan game programming days.. drivers were black boxes, game developpers had to resort to magic tricks to do stuff, until everybody got fed up and wanted some logical ground to operate
One does find oneself slightly askance at one's own thinking sometimes, that's for sure.
But I suppose, is it really so different? I mean, back in the day moreso than now, a lot of the valuable IP in any system was in the design and specification of that system - the problems usually solved within the design and specificaion (use X algorithm, etc.) - and the code was "just" the implementation of those solutions.
So perhaps it's more of a regression in some ways: the value is in the specification (the prompt) once again.
Your point about stochastic behaviour is well made though, and there is no way to 100% guarantee or formally verify the behaviour of a system that relies on an underlying technology whose behaviour is fundamentally stochastic.
In an ideal world this would have been public tech like ARPANET or WWW and there would have been 2-3 major iterations (until the equivalent of Claude 7-8) and only then would everyone have tried to build huge businesses on top of it.
I mean, sure, it's sort of usable, but the churn is insane. And we're burning the planet (and probably the economy, too) for it.
When was the last time you used an LLM to evaluate how true those last part(s) still are?
I also love how you went from "I'm unable to understand" to "This is surely right", it's a good representation of the software ecosystem at large :)
I already switched to a Chinese provider personally, I don't think the difference between both really justifies the wide gap in pricing
I'd be ecstatic if this was true, but nothing so far comes close to the SOTA models from OpenAI + highest reasoning, but I'd be more than happy to be proven wrong by testing it out myself.
So far, I've tried MiniMax M3, GLM 5.2, Hy3, MiMo-V2.5 (+ Pro), DeepSeek V4 Pro (+ Flash), Gemini 3, Kimi K2.6, GLM 5, all the various Qwen variants and probably a bunch more I forget about, in a wide array of harnesses (Codex, pi, opencode, my own and more), and still nothing seemingly comes close to GPT 5.5 (now 5.6) xhigh for tasks beyond 5-10 minutes of work, they all more or less collapse after a while in my experiments. Although most of those do work well for really tightly scoped tasks.
What specific model are you thinking about here, in case I've missed testing it?
* https://en.wikipedia.org/wiki/Homomorphic_encryption
It seems possible they trained this by doing full RL rollouts of agents interacting with each other. They likely view these prompts somewhat the same as raw reasoning traces, they don't want people to train directly on them.
I am unsure if this has been confirmed, but there are some signs that the opaque "compaction blob" they return from their dedicated compaction endpoint might not be text at all, rather a latent space representation of the conversation. The fact that OpenAIs compaction seems to be much higher fidelity than a lot of other providers makes me inclined to believe this.
If this is true, it doesn't seem far fetched to infer that they might be applying similar techniques to prompting subagents.
I would be curious to see if this way of spawning subagents (encrypted blob) is used when subagents of a different model type is spawned.
If you keep RL'ing the dispatch then the prompts are likely to keep diverging from the type of prompt a person would write (like CoT becoming increasingly incomprehensible), and that divergence is part of their competitive advantage.
I Imagine next that programming languages, interfaces and API design starts going this direction next. Being written, expressed and optimized as blobs of high dimensional vector space. As humans we might still be able to understand some abstractions of what our AI's are talking about to each other, but maybe not more so then we understand how different regions of our own brain communicate with each other.
https://www.wired.com/story/google-ai-language-create/
Even for like token efficiency it could make sense - like imagine if the representation were more compact
Agents acn already translate languages quite well. It doesn't seem crazy that they could work and think in a model specific language, and then translate back to English or something for the user
and how would you load that back into the model? they are token-in, token-out, plus the KV-cache which is derived from token-in
When operating on text, you embed each token into the LLMs embedding space. You go from a discrete token to a point in embedding space.
Likewise, when processing images, you have a image embedding model which produces a set of embedding vectors representing the contents of the image in the LLMs embedding (latent) space.
This same concept can be extended to compaction. Instead if limiting yourself to discrete tokens, you could generate a set of embedding vectors which represent the contents of the compacted conversation in latent space.
These have the possibility of containing a lot more semantic information per vector, which is why this can be appealing.
A big downside is decreased interpretability. AI safety people are generally fairly opposed to latent space reasoning for example, it can be harder to tell what the model is actually doing and if it is trying to deceive you.
Hopefully they can add that.
Add? Just make the sub-agents input prompt not encrypted, literally change "encrypted: true" to "encrypted: false" everywhere and everything continues to work as it used to.
They need to fix the regression, not add something new here.
this tracks. anthropic protects these as well iirc.
> I am unsure if this has been confirmed, but there are some signs that the opaque "compaction blob" they return from their dedicated compaction endpoint might not be text at all, rather a latent space representation of the conversation.
probably not a latent (to my knowledge latents aren't really part of the outer loop in ar-transformer inference processes), but maybe non-human-readable reasoning traces as occurs in fable.
I've gone in to look at Claude subagent/workflows and sometimes been like "no this was a mistake to spin up" ... Codex users just get to token yolo the encrypted telephone operator instructions+shell from orchestrator to subagents?
I was about to do the same with Sol + Ultra, but then discovered this encryption issue that prevents me from doing the same for sub-agents.
Personally I do, these tools aren't mature enough to be used without supervision
It makes more sense when you realize they don't want developers to be doing any coding at all. That's what they seem to be moving towards. From product manager to product via AI.
Because letting you look at the code would be too dangerous, you could reverse engineer an exploit to another product! Or distill their internet-distilled model!
But don't worry, at least it will be very convenient.
These two ideas don't compute for me.
Same thing with homomorphic encryption. I don't get it. If you can gain any knowledge from a ciphertext, you just found a way to exploit the ciphertext to me.
Inference is done in plain text. It's just that some parts of the response can be encrypted. While I haven't looked into this specific implementation, here's a short "how I'd do it" if I wanted to implement this:
Before:
[] - encrypted {} - plain text
1. user -> please do this -> server
2. user <- a) [thinking1] encrypted; b) {answer1} plain text <- server
3. user -> please do this -> [thinking1] (sent encrypted as received) -> {answer1} -> good but do this instead -> server
4. user <- [...] <- [thinking2] ; {answer2}
(here the server decrypts the thinking parts, adds them to the conversation, does the inference, and sends back the new thinking trace (encrypted as well) and the new answer
After:
1. user -> please do this long task -> server
2. user <- [thinking1] ; {tool_agent_spawn([params1])} ; {answer1} (e.g. would you like me to explore or do a quick hack?) <- server
3. user -> please do this long task -> (decides if explore or message) spawn([params1]) / message -> server
3. a) if no explore -> send message as usual 3. b) if explore execute spawn that in turns begins 2 channels
4. user <- [channel_1_thinking] ; {channel_1_answer} ; [channel_2_thinking] ; {channel_2_answer} ... <- server
So the server always does inference on plain text. But it sends the "important" bits encrypted, and you only send those back if you as the user want to (or need to, or choose to, etc). The idea is that the client still gets to decide on "local" things, but the server keeps the important bits from reaching the client. In this particular case, the [params] are encrypted bits that can include prompts, etc.
Notably, subagent output is still in plaintext.
Wrong, this is enabled by default for Sol and Terra (not Luna), no way of avoiding this short of patching the client yourself, and that still doesn't make the backend endpoints work, they want the ciphertext that OpenAI creates on their side.
> but noting that this is only for parent -> subagent spawns/messages
This is almost fully correct though, the encryption only seems to be for the initial prompt the main model sends the sub-agent, not all communication and not regarding the state of the sub-agent at all.
So you can inspect what the sub-agent is doing currently, and the output, but you cannot see what the initial prompt the sub-agent got started with.
If desired the user can always see what the sub agent is doing in detail ?
Isn't it the same in case of claude as well ?
Yes
> If desired the user can always see what the sub agent is doing in detail ?
Well, no, that's the problem, you're currently not allowed nor is it even possible, to see the exact prompt the main agent sent the sub agent. This is the problem.
> Isn't it the same in case of claude as well ?
No idea, but if Claude Code makes it so it's impossible to inspect what the sub-agents actually received before they started their work, then I'll say it's similarly impossible to rely on Claude Code if so.
> Multi-agent v2 currently routes agent instructions through normal tool arguments and inter-agent context. That means the parent model can emit plaintext task text, Codex can persist it in history/rollouts, and the recipient can receive it as ordinary assistant-message JSON.
This is the "Why" section, but it's notably devoid of any explanation for why any of these things, which seem like normal useful observability features, are a bad thing that needed to be fixed.
The issue description is overly charitable:
> The encrypted delivery path is understandable as privacy hardening
Whose privacy? The message the parent sent to the sub-agent is now encrypted by OpenAI on their servers. OpenAI has the key. There's no user privacy gained here, only privacy for the details of what instructions were sent to the model, and they carefully avoided explaining why this needed to be encrypted at all.
Yes, that is the obvious answer, of course. I was looking for an explanation as to why that would be so special now. They used to not do it until Codex is open source after all. Agent prompts more generally are also not encrypted. This particular change just looks unintuitive to me.
Oh and you can't even use local models or other providers for the sub-agents. You're locked-in.
I was already only using Claude Code to double-check if it's getting better than Codex, but with things like this, it really isn't even an alternative. What's the point of using a reasoning model if you as an end-user can't seen the reasoning? I don't think I'd be able to work like that at all, I need to have introspection into what the model is doing, and can't believe I have to say this, but also need to be able to see the plaintext of the input prompt...
There is no possible audit trail. No possible way to review what happened to validate the result. But even worse, no you will be billed somehow randomly. 20 sub agents started to do something we don't know. No way to now if it was legitimate, if it is just burning tokens or agents doing the same work on loop...