36 points AIorNot 4 hours ago 22 comments
AIorNot 4 hours ago | parent
See this: https://github.com/openai/codex/issues/25921#issuecomment-62...
cyanydeez 2 hours ago | parent
aleph_minus_one 24 minutes ago | parent
Because the former can be marketed very prestigiously, the latter hardly can.
According to https://www.briefia.fr/en/article/openai-revendique-la-resol... it is estimated that solving Navier-Stokes did cost OpenAI 40 million USD. I would bet that if OpenAI spent the same amount of money using its super-intelligence to fix this bug, this would work.
But seems not to be very economical. :-)
starfallg 1 hour ago | parent
On a work project, we're moving financial processes from Excel to code, and Codex ended up creating and storing thousands of validation tests unnecessarily. That ended up eating 90GB after we let it loose on a Windows VM that we connected with a custom agent between codex and the VM.
This is definitely a Codex thing and I've never seen this happen in Claude Code or Antigravity.
majormajor 1 hour ago | parent
Had to tell it to update it's agents.md to not do that...
giancarlostoro 1 hour ago | parent
When I was younger I thought we would be having exabyte hard drives by now.
plantain 1 hour ago | parent
mattgreenrocks 47 minutes ago | parent
tonyarkles 25 minutes ago | parent
Works especially well for transient/hard to repro bugs. It’ll either set breakpoints or write a monitoring script, go to sleep, get woken up by the harness when the bug trips, inspect state, put together a new build based on a hypothesis built from the debugging, flash it, and loop. I’ve had sessions run completely autonomously for over a day and come with a beautiful one-line solution to a gnarly race condition.
In that regard it’s like a human: you can read code all day if you want and you might get somewhere, but being able to inspect what happened, build a new theory, test it, and iterate is way more powerful 99% of the time.
glenngillen 1 hour ago | parent
- my approach to using git worktrees for all work. Not entirely surprising, the duplicated build artifacts in each worktree being the main culprit here. There were some limited gains to be had by just being more efficient with how builds were managed but ultimately I just had to limit the number of concurrent features I was working on in a couple of particularly large repos.
- more insidious was the fact I was actually hitting memory limits more than I realised and causing my mac to have to swap heavily. The system was surprisingly still quite performant while this was happening... until it wasn't. Unfortunately as best I can tell the only "fix" when this happens is to restart the machine. There's no way to have the system reclaim any of the swap space once it's written to disk. Which if you have it thrash a couple of times a day (especially easy if you leave something running overnight) adds up very quickly.
singularity2001 48 minutes ago | parent
aaronbrethorst 57 minutes ago | parent
madaxe_again 49 minutes ago | parent
And yes, codex is eating my disk, too. Ironically my solution is mostly codex - I have a task which goes around stomping on detritus.
rudedogg 35 minutes ago | parent
They still update it, it works perfectly, no version 2.0 forced obsolescence. Just a nice, reliable tool.
piskov 31 minutes ago | parent
TUI version is free, though there is a paid app if that’s your thing
columk 8 minutes ago | parent
clumsysmurf 31 minutes ago | parent
matt3210 49 minutes ago | parent
adamddev1 47 minutes ago | parent
piskov 30 minutes ago | parent
kudokatz 27 minutes ago | parent
jbellis 21 minutes ago | parent
two things help:
1. fs-level compression, I use ZFS bc Btrfs has massive contention problems with concurrent Rust builds
2. Archive your old sessions using something like sessionwiki (https://github.com/youdie006/sessionwiki), I've integrated this into my control plane (https://github.com/BrokkAi/mjolnir/)