Hacker Newsnew | past | comments | ask | show | jobs | submit | tekacs's commentslogin

Unfortunately, we're all stuck moving at the speed of the model labs because of the subscription models that they've provided.

The rest of us were able to implement things like push a long time ago, but because Claude Code and Codex stubbed those things out, we couldn't really use them for 'most agent users'.

In fairness to OpenAI, they have been generous in allowing for example OpenCode to sign in with your ChatGPT subscription – so you _could_ build a more powerful agent (which OpenCode is... not) – but unfortunately GPTs' instruction following just isn't up to snuff yet. Hopefully they pre-train something amazing this year!


I mean you can just use /loop in both Claude Code and Codex for heartbeats.

https://github.com/quinn-rs/quinn/issues/224#issuecomment-38...

It's lovely to see the polite and respectful back and forth in this comment thread where the Iroh folks are talking about deciding to fork. :)


Great interaction. Very refreshing after some of the past problems I've encountered with maintainers treating forks as hostile or "stealing our work".

The message also exposes a reality of how hard it can be to upstream internal changes: They admit they don't have the time to go back and re-submit all of their work as tiny incremental patches that could be reviewed and approved upstream. They estimate it would be on the order of 100 PRs necessary to break it up and get it reviewed. That's a very large time investment for a company that needs to keep moving forward.

Hopefully they stay close in the rest of the implementation details of the project they forked from. After a fork becomes battle-tested enough it might be reasonable to start merging things in larger chunks rather than treating them as incremental development again.


I very much agree, a nice contrast to so much open source drama

disclosure: I work on the team behind noq. Can't emphasize enough that the quinn maintainers are really lovely people, and quinn is an excellent project.

Can confirm! We work closely with them at Datum

I think that the point about building with agents though. Your ideas meet reality sooner and you actually get feedback on whether they are worth anything or not. So you're not really being an ideas guy in the sense of just throwing ideas out there. You're being an ideas guy in the sense of testing your ideas, which is really the essence of what building startups is: figuring out what people want.

That's true. I was just responding to the post above, which seemed to be inferring a different meaning (i.e. that there are no bad or good ideas guys) than how I interpreted it.

libghostty already powers quite a few alternate terminals:

https://github.com/Uzaaft/awesome-libghostty

This project uses alacritty-terminal, so it's also very much 'not from scratch', just using a Rust library to that effect.


Worth bearing in mind that people in VFX are often relatively technical.

From their own 'LLM handover' doc: https://github.com/nikopueringer/CorridorKey/blob/main/docs/...

> Be Proactive: The user is highly technical (a VFX professional/coder). Skip basic tutorials and dive straight into advanced implementation, but be sure to document math thoroughly.


Back when I played with animation and post pipelines, I was writing a decent amount of python. It's part of how I got into programming. At the time I would have said I can't program, and I suspect this guy is similar.

This is fun! I switched to https://github.com/manaflow-ai/cmux for a while, but had to switch back to Ghostty due to its unreliability, high memory and CPU usage and a bunch of bugs.

This makes a lot of sense, but... it'd be great to allow pulling out of a canvas into a second canvas for those of us with multiple screens (you at least end up needing one window per screen).

In general it feels like... more structure rather than less feels like it'd be the smoothest experience. I'll play with your Ctrl+K shortcut and see if it ends up feeling like I can get everywhere that I need quickly.

But... nice work!

Note for jj users like me: you need to `git lfs pull` if you want to `cargo run --release`!

Update: No luck creating any 'shell' workspaces (it looks like you use GNU-only flags to script) – I'll push a fix once I find it.

Also: the AGENTS.md is wrong JFYI - it points to portable-pty, when this is using alacritty_terminal's tty (on rustix-openpty)


Thanks for trying it! I totally forgot about multiple screens because I use multiple workspaces on an 8K screen.

Splitting across multiple screens shouldn’t be too difficult since Horizon already supports multiple sessions. I’ll try to get it working tomorrow :)


Splitting across multiple screens support just landed: https://github.com/peters/horizon/pull/32

I prefer Terminator, where splitting screens is much easier work flow.

This is the only reason I stick to Terminator, but none of the othet terminal emulators are coming close. I wouldn‘t even be searching for an alternative if Terminator wouldn‘t crash every other week.

I've not had any real crashes; but I have to swap between linux and windows, so anything that bridges that gap would get my vote.

It kinda... does? The problem is that folks have been flailing on the right UX for this.

This is what build vs. plan mode _does_ in OpenCode. OpenAI has taken a different approach in Codex, where Plan mode can perform any actions (it just has an extra plan tool), but in OC in plan mode, IIRC write operations are turned off.

The screenshot shows that the experience had just flipped from Plan to Build mode, which is why the system reminder nudged it into acting!

Now... I forget, but OC may well be flipping automatically when you accept a plan, or letting the model flip it or any other kind of absurdity, but... folks are definitely trying to do the approval split in-harness, they're just failing badly at the UX so far.

And I fully believe that Plan vs. Build is a roundly mediocre UX for this.


The switch from plan mode to build is not always clearly defined. On a number of occasions, I've been in plan mode and enter a secondary follow up prompt to modify the plan. However, instead of updating the plan, the follow up text is taken as approval to build and it automatically switches to building.

Ask mode, on the other hand, has always explicitly indicated that I need to switch out of ask mode to perform any actions.

This is my experience with Cursor CLI.


Does Codex actually have a Plan Mode, or is there a mode switch I'm missing? I find myself having to manually tell it to 'make a plan' every time.

and if it has directory permissions, sometimes it just skips the confirmation step and starts executing as soon as it thinks the plan is ready.


cmd-shift-p (at least in vscode)

shift-tab in cli

It actually work, got "Plan mode (shift+tab to cycle)" at corner.

reading the manual , there is Slash commands /plan /plan switch to Plan mode

It seems that, unlike OpenCode, Codex doesn't show a notice for mode by default.


This applies well if you’re writing code.

But often I am using Claude to investigate a problem like this “why won’t this mDNS sender work” and it needs a bunch of trial and error steps to find the problem and each subsequent step is a brand new unanticipated command.


The OpenCode plan experience has been pretty bad (the community has accepted this, at least on Discord). The community's adopted a handful of plugins to make the experience better, and also guardrail when the agent switches versus doesn't

I think this means cost above. As in the extra cost you pay.

As a heavy magit user prior to jj, I can attest that I've just felt much less need for it in the wake of jj. Things like JJ's split being interactive and a lot of the commands having really neat short forms has meant that for me, as attached as I was, I still found myself benefiting so much that I switched.

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: