same author who's idea of constraint decoding for structured outputs was to run an schema-begging-API call in a loop 10 times & then throw an exception on failure.
Give each Codex an AgentName and ask them to mark their PR/issue/comments with those. Have one or two "managers" that manage PRs and overall project direction. I write the project directions and make long lasting issues. Each Codex session has an almost unachievable `/goal` but they are asked to achieve the goal by landing changes in `main` via PRs
I am running about 14 Codex sessions on 4 machines right now for about two weeks since OpenAI 10x'ed my 20x account and I simply can not run out of tokens fast enough.
Side note: I have multiple Claude accounts too but the new Claude Code `/goal` command is seriously broken. It waits long pauses between iterations and sometimes prematurely stops.
Yes I'm aware of that. Perry is a different project. Folks at Oxi tools are also doing something similar (a ts checker) but that's also not 100% compatible with tsc. My goal with tsz is a superset of tsc that's stricter (for now it's called Sound Mode). But matching more than a decade of work that TypeScript has put in has been a long journey already. None of the existing TypeScript rewrites are matching the original tsc yet. tsgo is the closest but that also has bugs that needs to be addressed before TS 7 is released.
I think my architecture can be faster than tsgo albeit a much more painful codebase to work on. But I'm not claiming any sort of achievement yet.
Ultimately users have to decide and I have to show a very strong case that someone should use a nonofficial rewrite over Microsoft's own code.
Will tsz be a success? I am not sure. Am I learning and having fun? for sure!
Yeah I didn't mean subsuming one project into another, just that maybe both could be integrated so that a user can type check strongly and soundly with tsz and then compile with Perry. Turning TypeScript into a true sound statically typed language with AOT compilation would be amazing.
inb4 "I got prompt injected and they stole my stuff". Now real talk, there are some viable usages of codex here but nothing novel its the same "old": "MEMORY,VAULT,BG TASKS" that everyone is doing.
And about voice mode, I thought it was a good idea but I seriously don't know how you guys use it, my thoughts whenever I use voice are "aaaaaaaaahhhhhh, uhmmm" and then cancel it so that I can type and organize my thoughts. I don't really think those "brain dumps" are useful when you are thinking out loud like "We should really do X oh wait but actually Y is in the way and we have to take into consideration Z, but wait Y was actually done" and so on, and it turns out that your assumptions are wrong, it becomes a mess. I am in favor of the LLM to work with facts and always verify it. To me this post is basically selling Codex app and that's it, nothing new inside.
> Every 30 minutes, check Slack and Gmail for unanswered messages that need my attention...
> When I come back to Slack, replies are often already sitting in drafts. I still decide what gets sent, but the expensive part of gathering context is done.
This just feels so dystopian to me. I hope that I never work with you or someone else doing this.
I personally do use LLMs for work messaging but I'm extremely careful to state clearly like "here's a draft for that quotation request that Claude wrote:" or something like that. I would never present that as my own words.
If the other people in the org are using LLMs to a similar degree, any question to which an LLM can provide a good answer to will never get sent. How useful are the draft replies then?
Still not useful enough for me and I really want this feature!
The problem I encounter is the inability of the LLM to look stuff up and respond to me. "What's that name of that database table?" "What are all the services that call this endpoint?" "Are there any open PRs for this repo right now?"
Once information can flow in both directions not just one it will be a gamechanger for me.
These cloud LLMs are not the tool for you then I suppose. There are local models too, unless your point is why use LLMs, in which case, you don't need to.
The diff-as-review point is the one I keep coming back to.
The cost of memory-as-files isn't writing them. It's that the agent will cheerfully claim it updated something and not actually do it, or write a one-line stub that satisfies the spec but loses the original signal. Without a verification layer, the vault accumulates plausible-looking entries that quietly drift from reality.
What ended up working for me was treating the agent's self-reported summary as a wish, not a fact. A separate process diffs the actual file system against the claimed changes and flags mismatches.
After a few cycles, the agent gets calibrated and stops claiming things that don't survive a file check. That has the side benefit of making the diff review itself much higher signal: most of what shows up is real.
The split I'd make early is per-agent instructions vs. cross-thread shared notes.
They sound like the same artifact, but “what this agent should always do” and “what sibling work just learned” age very differently. Mixing them means the wisdom gets stale together.
The author of this post works at OpenAI on the Codex team.
same author who's idea of constraint decoding for structured outputs was to run an schema-begging-API call in a loop 10 times & then throw an exception on failure.
All the AI stuff lately is just like Unix Porn reddit but posted to places where the people don’t care about it.
I feel that we're about ready for someone to start something like Uber, but for file-like objects
Anything with “maxxing” in the name is most likely not good for you
I came to understand it as "optimizing well past the point of diminishing returns".
in tsz (https://tsz.dev) I am Codex-Maxxing with this:
Give each Codex an AgentName and ask them to mark their PR/issue/comments with those. Have one or two "managers" that manage PRs and overall project direction. I write the project directions and make long lasting issues. Each Codex session has an almost unachievable `/goal` but they are asked to achieve the goal by landing changes in `main` via PRs
I am running about 14 Codex sessions on 4 machines right now for about two weeks since OpenAI 10x'ed my 20x account and I simply can not run out of tokens fast enough.
Side note: I have multiple Claude accounts too but the new Claude Code `/goal` command is seriously broken. It waits long pauses between iterations and sometimes prematurely stops.
Do you know about Perry, a TypeScript to native binary compiler also in Rust? That might be interesting to collaborate on.
https://old.reddit.com/r/typescript/comments/1rjxo8z/what_if...
https://perryts.com/
Yes I'm aware of that. Perry is a different project. Folks at Oxi tools are also doing something similar (a ts checker) but that's also not 100% compatible with tsc. My goal with tsz is a superset of tsc that's stricter (for now it's called Sound Mode). But matching more than a decade of work that TypeScript has put in has been a long journey already. None of the existing TypeScript rewrites are matching the original tsc yet. tsgo is the closest but that also has bugs that needs to be addressed before TS 7 is released.
I think my architecture can be faster than tsgo albeit a much more painful codebase to work on. But I'm not claiming any sort of achievement yet.
Ultimately users have to decide and I have to show a very strong case that someone should use a nonofficial rewrite over Microsoft's own code.
Will tsz be a success? I am not sure. Am I learning and having fun? for sure!
Yeah I didn't mean subsuming one project into another, just that maybe both could be integrated so that a user can type check strongly and soundly with tsz and then compile with Perry. Turning TypeScript into a true sound statically typed language with AOT compilation would be amazing.
inb4 "I got prompt injected and they stole my stuff". Now real talk, there are some viable usages of codex here but nothing novel its the same "old": "MEMORY,VAULT,BG TASKS" that everyone is doing.
And about voice mode, I thought it was a good idea but I seriously don't know how you guys use it, my thoughts whenever I use voice are "aaaaaaaaahhhhhh, uhmmm" and then cancel it so that I can type and organize my thoughts. I don't really think those "brain dumps" are useful when you are thinking out loud like "We should really do X oh wait but actually Y is in the way and we have to take into consideration Z, but wait Y was actually done" and so on, and it turns out that your assumptions are wrong, it becomes a mess. I am in favor of the LLM to work with facts and always verify it. To me this post is basically selling Codex app and that's it, nothing new inside.
> Every 30 minutes, check Slack and Gmail for unanswered messages that need my attention...
> When I come back to Slack, replies are often already sitting in drafts. I still decide what gets sent, but the expensive part of gathering context is done.
This just feels so dystopian to me. I hope that I never work with you or someone else doing this.
I personally do use LLMs for work messaging but I'm extremely careful to state clearly like "here's a draft for that quotation request that Claude wrote:" or something like that. I would never present that as my own words.
If the other people in the org are using LLMs to a similar degree, any question to which an LLM can provide a good answer to will never get sent. How useful are the draft replies then?
Most people I know underutilize voice mode. Such a game changer for making brain dumps the LLM can just gobble up
Still not useful enough for me and I really want this feature!
The problem I encounter is the inability of the LLM to look stuff up and respond to me. "What's that name of that database table?" "What are all the services that call this endpoint?" "Are there any open PRs for this repo right now?"
Once information can flow in both directions not just one it will be a gamechanger for me.
Why would I want OpenAI to gobble up my brain dumps?
These cloud LLMs are not the tool for you then I suppose. There are local models too, unless your point is why use LLMs, in which case, you don't need to.
I don’t like that they don’t have realtime output. Would prefer Parakeet for that.
Slop
The diff-as-review point is the one I keep coming back to.
The cost of memory-as-files isn't writing them. It's that the agent will cheerfully claim it updated something and not actually do it, or write a one-line stub that satisfies the spec but loses the original signal. Without a verification layer, the vault accumulates plausible-looking entries that quietly drift from reality.
What ended up working for me was treating the agent's self-reported summary as a wish, not a fact. A separate process diffs the actual file system against the claimed changes and flags mismatches.
After a few cycles, the agent gets calibrated and stops claiming things that don't survive a file check. That has the side benefit of making the diff review itself much higher signal: most of what shows up is real.
The split I'd make early is per-agent instructions vs. cross-thread shared notes.
They sound like the same artifact, but “what this agent should always do” and “what sibling work just learned” age very differently. Mixing them means the wisdom gets stale together.