coding agents, co-agents, and coco-agents.
Readit Newsnathants commented on Ask HN: What Are You Working On? (December 2025) · Posted by u/david927
Just exchange json.
Backend in python/ruby/go/rust.
Frontend in javascript/typescript.
Scripts in bash/zsh/nushell.
One upon a time there was a low amount of friction and boilerplate with this approach, but with Claude and Codex it’s changed from low to none.
https://platform.openai.com/docs/models/gpt-5.2
400k, not 256k.
400 - 128 = 272. Codex cli source.
Weirdly, the blog announcement completely omits the actual new context window size which is 400,000: https://platform.openai.com/docs/models/gpt-5.2
Can I just say !!!!!!!! Hell yeah! Blog post indicates it's also much better at using the full context.
Congrats OpenAI team. Huge day for you folks!!
Started on Claude Code and like many of you, had that omg CC moment we all had. Then got greedy.
Switched over to Codex when 5.1 came out. WOW. Really nice acceleration in my Rust/CUDA project which is a gnarly one.
Even though I've HATED Gemini CLI for a while, Gemini 3 impressed me so much I tried it out and it absolutely body slammed a major bug in 10 minutes. Started using it to consult on commits. Was so impressed it became my daily driver. Huge mistake. I almost lost my mind after a week of this fighting it. Isane bias towards action. Ignoring user instructions. Garbage characters in output. Absolutely no observability in its thought process. And on and on.
Switched back to Codex just in time for 5.1 codex max xhigh which I've been using for a week, and it was like a breath of fresh air. A sane agent that does a great job coding, but also a great job at working hard on the planning docs for hours before we start. Listens to user feedback. Observability on chain of thought. Moves reasonably quickly. And also makes it easy to pay them more when I need more capacity.
And then today GPT-5.2 with an xhigh mode. I feel like xmass has come early. Right as I'm doing a huge Rust/CUDA/Math-heavy refactor. THANK YOU!!
Usable input limit has not changed, and remains 400 - 128 = 272. Confirmed by looking for any changes in codex cli source, nope.
Location: USA Remote
Remote: Yes
Relocate: For better remote timezone
Tech: All
Resume: https://nathants.com
Email: me@nathants.com
Just have SES put the email in s3, then do stuff.
nathants commented on BorgBackup 2 has no server-side append-only anymore github.com/borgbackup/bor... · Posted by u/jaegerma
Cool, but looks like it's going to miss capabilities, so not suitable for a full OS backup (see https://github.com/python/cpython/issues/113293)
Interesting. I'm not trying to restore bootable systems, just data. Still, probably worthwhile to rebuild in Go soon.
nathants commented on BorgBackup 2 has no server-side append-only anymore github.com/borgbackup/bor... · Posted by u/jaegerma
Index of files stored in git pointing to a remote storage. That sounds exactly like git LFS. Is there any significant difference? In particular in terms of backups.
Definitely similar.
Git LFS is 50k loc, this is 891 loc. There are other differences, but that is the main one.
I don't want a sophisticated backup system. I want one so simple that it disappears into the background.
I want to never fear data loss or my ability to restore with broken tools and a new computer while floating on a raft down a river during a thunder storm. This is what we train for.
nathants commented on BorgBackup 2 has no server-side append-only anymore github.com/borgbackup/bor... · Posted by u/jaegerma
I use rsyncs --link-dest
abridged example:
rsync --archive --link-dest 2025-06-06 backup_role@backup_host:backup_path/ 2025-06-07/
rsync_cmd = [
'/usr/bin/rsync',
'--archive',
'--numeric-ids',
'--owner',
'--delete',
'--delete-excluded',
'--no-specials',
'--no-devices',
'--filter=merge backup/{backup_host}/filter.composed'.format(**rsync_param),
'--link-dest={cwd}/backup/{backup_host}/current/{backup_path}'.format(**rsync_param),
'--rsh=ssh -i {ssh_ident}'.format(**rsync_param),
'--rsync-path={rsync_path}'.format(**rsync_params),
'--log-file={cwd}/log/{backup_id}'.format(**rsync_params),
'{remote_role}@{backup_host}:/{backup_path}'.format(**rsync_params),
'backup/{backup_host}/work/{backup_path}'.format(**rsync_params) ]This is cool. Do you always --link-dest to the last directory, and that traverses links all the way back as far as needed?