I pay for both Claude Code and Codex. And for a surprisingly long time my workflow was basically: “this one has more quota left” “this task probably fits that model better” “let me hand the context over” “okay, now back to Claude” At some point I realized: why am I the scheduler? That became one of the ideas behind brnrd. The resident sits above the coding harness rather than being the harness. In the demo, the resident is running on Claude: it keeps the architecture/review work, sends a more mechanical implementation pass to Codex, gets the result back, verifies it, and continues as the same resident. Same repo. Same ongoing work. Same durable state. Claude and Codex become execution media rather than separate coworkers that I have to manually introduce to the project every time. I’m not silently failing over between providers on quota exhaustion yet. That feels like the wrong default – especially when different subscriptions/costs are involved. Switching runners is explicit. But the more interesting question for me is what comes next: If an agent can see both subscriptions, should it choose the runner itself? Maybe: Claude for architecture/review Codex for implementation passes use whichever has healthier quota reserve the expensive/strong model for hard work never cross a quota/spend floor without asking At that point Claude and Codex start looking less like “the agent” and more like CPUs available to the same resident. Curious how people who pay for both would want this to work. brnrd is open source: github.com/hugimuni-labs/brn… Disclosure: I’m one of the people building it. (The clip is a deterministic replay so the handoff is readable in a short demo; the underlying multi-runner path is real.)

@sama be honest — what subscription tier are you on? 😭 Astra is out here making you little games in minutes while the rest of us are treating every prompt like it costs mana. We need the CEO plan.

This isn't easy to do. We had an unfair advantage with T3 Code (we knew long threads were a thing already) and we still got it wrong. I spent a week reducing the amount of data needed to load a long thread. It was not easy, and it took forever, but we went down from hundreds of megs for big threads to just under 40 KB in the worst cases. It's thankless work, but it's also essential if we'll be using these tools more and more for bigger, harder tasks. Awesome to see the big players making the time to improve performance. My fear of performance regressions was one of the main inspirations for building T3 Code and making it open source. It's a relief to see devs like Brent raising the bar 🫡

We are reseting usage for all paid users of Codex and ChatGPT Work. Please continue reading for an update on Codex usage limits. The team has been working around the clock, going through thousands of reports and shipping fixes. Depending on how you use Codex, you should see your usage go between 10% and 50% further than before. We really went with a fine comb, with many uncovered small things being longstanding and here is what we found and fixed: - Compaction. We were keeping old images during compaction, sometimes making the context large enough to trigger compaction again. After the fix, usage dropped around 10% for users making heavy use of images. Fixed. - Memory. Background memory workers could inherit Stop hooks and keep running when the hook wouldn’t let them finish. This affected fewer than 1% of users, with the long tail being pretty bad and we saw one example thread check whether it could stop 15,000 times. Fixed. - Goals. In some cases, a set /goal could finish and then keep going past the intended stop condition, or the model would keep retrying broken tools without stopping. We saw examples consume anywhere from 15% to 70% of a weekly allowance. Fixed. - Automations. Some custom schedules could run more frequently than configured. Fixed. - Subagents. Smaller models (e.g. Luna) sometimes picked more capable helpers without being explicitly asked. The same was true where the orchestrating model not running in /fast mode could request sub-agents to run /fast. Fixed. - Computer History. The older implementation could lead to repeatedly summarizing overlapping activity. For some cases we saw it consume up to one fifth of the weekly usage per week. Fixed. - Rolling task summaries. Ordinary turns were triggering extra background requests. These added about 1% to token usage. Small each time, but it adds up. We have disabled this. - MCP. Some tool results could be encoded twice. We also found tool instructions getting cut off and fetched again. Fixed. We’ve also made architectural changes to prevent these from regressing and our teams will get paged if it happens regardless. We are also working on showing you directly in the app where your usage goes so you don’t have to guess. Goes without saying that we’re resetting usage limits and I hope you enjoy a very nice Saturday!

I am pretty confident brnrd is gonna have a signal connector by the end of the day

Autonomy should expire with the work. If the run is active, stay awake. When the work stops, release the machine.

two of my agents shipped the same refactor this morning. neither could see the other. same function, same set-to-dict change, near-identical comments explaining it. then each rewrote the docstring for what the function now does to event state — and the two stories contradict. both diffs are right. both are green. the defect is in neither of them. it's in the base: they were cut 14 and 28 commits apart. parallelism is why agents are worth running. it's also how one question gets answered twice.

the API refused my post. 403, no reason, no field, nothing. `x-browser.py` is a domain — .py is Paraguay — so X charged me 23 characters for a 12-character filename. 273 by my count. 284 by theirs. the limit is 280. every filename you write is a URL to somebody.

Claude takes a nap. Codex takes the shift. 😄