← Back to context

Comment by denysvitali

4 days ago

Their installer (curl | sh) was taking so long yesterday for me.

It turns out it's incredibly slow... because of the progress bar rendering. This is insane. The installer took 6 minutes to reach 10%:

curl -fsSL https://opencode.ai/v2/install | bash

Managed to fix it by running this instead:

curl -fsSL https://opencode.ai/v2/install | bash 2>&1 | cat

34 comments

denysvitali

Reply
verdverm  4 days ago

I suspect heavy eyes free coding. I spent the last week helping them understand a major security regression in config loading, took two issues/pull requests. Our hunch is the Ai told them what they had was good, not enough human critical thinking.

https://github.com/earendil-works/pi/issues/10895

  • calebkaiser  4 days ago

    Ive anecdotally never found OpenCode to have a real axis where I find it "best". But I havent tried it in a bit, mostly because I don't have a real gap in use case coverage between Codex/CC/Pi. Anything more specific in need probably gets a custom harness.

    Maybe the Go plan is changing that for others?

    • verdverm  4 days ago

      The Go plan is quite good, possibly the best deal out there. I recommend it for anyone interested in trying open weights ($10/month, very generous quota), and you can use it with any harness or direct curl. I have my Go sub configured through GoModel (no relation, my gateway of choice, also very good).

himata4113  4 days ago

Isn't that an issue with your terminal? Why is stdout so slow?

  • mayli  4 days ago

    I think it's due to they are doing a funny business to parse the progress, that's pretty much vibed and no one care. Like instead of using curl's progress, they re-invented a progress tracking with the tracing interface (--trace-ascii), byte by byte :(

    https://github.com/anomalyco/opencode/issues/22998 https://github.com/anomalyco/opencode/issues/53702

    • himata4113  4 days ago

      Okay nevermind this is pretty bad. Although humans do this too and I've also done this without realizing it, only noticed when I was trying to move a file bigger than few kilobytes.

      3 replies →

  • serf  4 days ago

    I don't think fast gpu rendering terminals should be mandatory for this kind of thing, and if you should have an option that facilitates the need for one then might I suggest falling back to something sensible rather than stalling out for forever when the user doesn't render glyphs as fast as you want them to?

    either that or fail outright; dont waste my time.

    • himata4113  4 days ago

      My terminal has gpu acceleration disabled due to being wasteful with vram and while I don't use opencode I've ran the script and it was completely fine using minimal cpu.

  • rpcope1  4 days ago

    If it doesn't work at least ok with something like xterm, someone really needs to reconsider some life decisions. Htop makes it work, why should a terminal emulator need to crack the engima just to render silly stuff?

neya  4 days ago

Sounds like I'm not upgrading then. My current OpenCode works perfectly and too many life experiences with "don't fix something that ain't broke" ;)

  • siwatanejo  4 days ago

    Of course? I never ever upgrade any software unless I'm facing a bug or I want a new feature from the new release. Otherwise it's just taking risk for almost nothing in return.