Entries for August 10, 2026

I've felt the lack of a certain feature of codex desktop app since I went back to the CLI: scheduled tasks Codex desktop app can keep track of a task until it is properly finished. It's basically cron. And for some reason, codex CLI still doesn't have it. Codex app acts as a shared runtime, and for some reason, certain features don't work without it, even though they could... there is no reason for openai to not use a background process So I got bored of waiting, and decided to build my own in @pidotdev But I realized, I could do much more than a simple cron job, with my recently upgraded osolmaz/pi-workflows extension A cron job is a loop after all. Being a loop, I can represent it as a workflow graph So I created a built in `monitor` workflow to mimic cron behavior. The agent is forced into a loop where it re-checks a very long-running job every 1 hour, and it is instructed to autonomously correct it and fix any bugs if any are encountered The same functionality can be achieved by iamwrm/pi-unified-exec as well, which implements codex-like auto-forking exec behavior. But there is a chance the model messes up exec, or does not re-arm the next sleep() properly once one of them exits My monitor workflow on the other hand is deterministic. I can make the agent loop infinitely, and there is nothing the agent can do to evade the task. I just ask the agent to monitor something, and it starts it automatically This lets me just fire off week-long jobs, and forget about it! It even survives codex usage depletion, by auto-recovering once my quota resets Oh also, @ratatui_rs is a delight! I created piw, a viewer for my ongoing pi workflows. I just type piw, and can see the current state, or play back the finished ones

Apparently this went to HN front page briefly last night, so sharing it here as well YOLO safely with your agents 🤖 Give your GitHub/Hugging Face accounts + ability to run sudo safely to your agent. No need to create an agent account, or clickops policies on GitHub etc. Give it merge access to repo X for 5 minutes, 30 minutes, 1 time, 100 times, anything... Then give it unlimited access to repo Y forever. Other repos stay untouched. Complete flexibility that GitHub policies actually cannot give you due to the way that they are designed You can get notifications through telegram, and can approve its requests No need to pay $4 to GitHub if you simply want protection against force push. unYOLO blocks force pushes by default, unless you explicitly allow to Your exfiltratable, internet-accessing agent/claw gets its own Linux/Mac account, and has to access these services through unYOLO The video shows how it works! Visit:

This. LPDDR chips are cheaper to produce and run GDDR/HBM will likely keep being more expensive Most consumer GPUs will converge on a GB10 like form factor As much as us hobbyists love to project this ideal of running a GPU cluster at home, most working people will prefer smaller form factors, and will not want to pay hundreds of $$$ in electricity bills every month DGX Spark/GB10 runs at around 90-150 Watts RTX Pro 6000 runs at 600 Watts FOR THE GPU ALONE, and can cost 3-5x more than GB10. Despite having 25% less memory capacity than GB10... Looking at this, LPDDR will be orders of magnitude more commonplace at home Architectures will develop accordingly. Future local AI will be dominated by MoE and similar architectures which leverage mid-sized models with smaller number of active parameters That is why Qwen3.x-35B-A3B is a more useful model on the Spark than Qwen3.x-27B, despite the latter being a better model. Same for Gemma I can run A3B at 60 decode tok/s single session or 6x20 decode tok/s in parallel, whereas 27b only reaches 1/3rd of that Future of local AI is DDR/LPDDR and MoE/adjacent architectures, for the average person