Hacker News Reader

Comment by killerstorm | Hacker News Reader

I like the idea but it did not quite work out of box.

There was some issue with sign-in, it seems pin requested via web does not work in console (so the web suggesting using --pin option is misleading).

I tried BYO plan as I already have openrouter API key. But it seems like default model pack splits its API use between openrouter and openai, and I ended up stuck with "o3-mini does not exist".

And my whole motivation was basically trying Gemini 2.5 Pro it seems like that requires some trial-and-error configuration. (gemini-exp pack doesn't quite work now.)

The difference between FOSS and BYO plan is not clear: seems like installation process is different, but is the benefit of paid plan that it would store my stuff on server? I'd really rather not TBH, so it has negative value.

View on HN

Thanks for trying it!

Could you explain in a bit more detail what went wrong for you with sign-in and the pin? Did you get an error message?

On OpenRouter vs. OpenAI, see my other comment in this thread (https://news.ycombinator.com/item?id=43719681). I'll try to make this smoother.

On Gemini 2.5 Pro: the new paid 2.5 pro preview will be added soon, which will address this. The free OpenRouter 2.5 pro experimental model is hit or miss because it uses OpenRouter's quota with Google. So if it's getting used heavily by other OpenRouter users, it can end up being exhausted for all users.

On the cloud BYO plan, I'd say the main benefits are:

- Truly zero dependency (no need for docker, docker-compose, and git).

- Easy to access your plans on multiple devices.

- File edits are significantly faster and cheaper, and a bit more reliable, thanks to a custom fast apply model.

- There are some foundations in place for organizations/teams, in case you might want to collaborate on a plan or share plans with others, but that's more of a 'coming soon' for now.

If you use the 'Integrated Models' option (rather than BYO), there are also some useful billing and spend management features.

But if you don't find any of those things valuable, then the FOSS could be the best choice for you.

When I used `--pin` argument I got an error message along the lines of "not found in the table".

I got it working by switching to oss model pack and specifying G2.5P on top. Also works with anthropic pack.

But I'm quite disappointed with UX - there's a lot of configuration options but robustness is severely lacking.

Oddly, in the default mode out of box it does not want to discuss the plan with me but just jumps to implementation.

And when it's done writing code it aggressively wants me to decide whether to apply -- there's no option to discuss changes, rewind back to planning, etc. Just "APPLY OR REJECT!!!". Even Ctrl-C does not work! Not what I expected from software focused on planning...

Thanks, I appreciate the feedback.

> Oddly, in the default mode out of box it does not want to discuss the plan with me but just jumps to implementation.

It should be starting you out in "chat mode". Do you mean that you're prompted to begin implementation at the end of the chat response? You can just choose the 'no' option if that's the case and keep chatting.

Once you're in 'tell mode', you can always switch back to chat mode with the '\chat' command if you don't want anything to be implemented.

> And when it's done writing code it aggressively wants me to decide whether to apply -- there's no option to discuss changes, rewind back to planning, etc. Just "APPLY OR REJECT!!!". Even Ctrl-C does not work! Not what I expected from software focused on planning...

This is just a menu to make the commands you're most likely to need after a set of changes is finished. If you press 'enter', you'll return back to the repl prompt where you can discuss the changes (switch back to chat mode with \chat if you only want to discuss, rather than iterate), or use commands (like \rewind) as needed.

Here's what happened:

  1.  It started formulating the plan
 2.  Got error from provider (it seems model set sometime randomly resets to default?!?)
 3.  After I switched to different provider, I want it to continue planning, so I use \continue command
 4.  But when it gets \continue command it starts writing code without asking anything!
 5.  In the end it was still in chat mode. I never switched to tell mode, I just wanted it to keep planning.

Here's an excerpt: https://gist.github.com/killerstorm/ad8afa19b2f55588eb317138...

It went from entry 3 "Made Plan" to entry 4 and so on without any input from my end.

I could not reproduce the second issue this time: I didn't get the same menu and it was more chill.

I see, it sounds like \continue is the issue—this command is designed to continue with implementation rather than with a chat, so it switches you into 'tell mode'. I'll try to make that clearer, or to make it better handle chat mode. I can definitely see how it would be confusing.

The model pack shouldn't be resetting, but a potential gotcha is that model settings are version controlled, so if you rewind to a point in the plan before the model settings were changed, you can undo those changes. Any chance that's what happened? It's a bit of a tradeoff since having those settings version controlled can also be useful in various ways.

This feedback is very valuable, so thanks again!

The installation process for the FOSS version includes both the CLI (which is also used for the cloud version) and a docker-compose file for the server components. Last time I tried it (v1) it was quite clunky but yesterday with v2 it was quite a bit easier, with an explicit localhost option when using plandex login.

I'm glad to hear it went smoothly for you. It was definitely clunky in v1.

I would get rid of the email validation code for localhost, though. That remains the biggest annoyance when running it locally as a single user. I would also add a $@ to the docker-compose call in the bash start script so users can start it in detached mode.

It should already be skipping the email validation step in local mode. Is it showing up for you?

I’ll look into the detached mode, thanks!

Yes, it showed up for me, luckily I had the logs open and remembered that was the solution in v1 (it wasn’t documented back then iirc). I git pulled in the same directory I ran v1 in so maybe there’s some sort of left over config or something?

Email pins are disabled based on a LOCAL_MODE environment variable, which is set in the docker-compose config. I'll take a look.

Yeah, I noticed that (needing a dedicated OpenAI key) as well for the BYO key plan. It's a little bit odd considering that open router has access to the open AI models.

https://openrouter.ai/openai

OpenRouter charges a bit extra on credits, and adds some latency with the extra hop, so I decided to keep the OpenAI calls direct by default.

I hear you though that it's a bit of extra hassle to need two accounts, and you're right that it could just use OpenRouter only. The OpenRouter OpenAI endpoints are included as built-in models in Plandex (and can be used via \set-model or a custom model pack - https://docs.plandex.ai/models/model-settings).

I'm also working on allowing direct model provider access in general so that OpenRouter can be optional.

Maybe a quick onboard flow to choose preferred models/providers would be helpful when starting out (OpenRouter only, OpenRouter + OpenAI, direct providers only, etc.).

FWIW I got it working by selecting oss or anthropic model packs. But I had some OpenAI key... maybe it would work with a dummy.

Reply on news.ycombinator.com