Why is it so expensive?

[achimstruve]

I am vibe coding a lot with Cursor and can do like 500 prompts per month for $20 using Claude 4 sonnet. This implies many days of constant coding. However for some reason using Plandex with the default settings (daily-driver model pack with OpenRouter API key) which uses sometimes Claude 4 sonnet and often mixes in weaker chatGPT models I burnt through like $8 dollars on an afternoon. Sure OpenRouter is a little more expensive, but this does not explain this huge cost divergence. All while I was constantly coding with Cursor in my IDE on another project. This gives me the exact comparison. Furthermore I must say that unfortunately the quality of outcomes is a bit worse than the experience I have with Cursor. Sure this is open-source, but it is also more expensive at the same time. E.g. often it does way more than it was prompted to do. In one case I just wanted it to create a task list for a new project, but instead it immediately started with some arbitrary implementations..

Probably I am doing something wrong here and therefore would appreciate any tips or inputs on how to get higher quality with lower costs, comparable to Cursor.

Also I am super happy to have found Plandex so that I can vibe code via console and the option of using my OpenRouter API key.

[danenania]

Thanks for your feedback on this @achimstruve. I moved it over to a discussion.

The short answer is that Plandex prioritizes capability and getting good results over saving tokens. While it does use caching and selective context loading to reduce costs, it also doesn’t arbitrarily cut the model off from loading context that it determines may be relevant, which can make it more expensive for some use cases than other tools—though it really depends.

On getting output that you didn’t ask for: this can definitely be an issue and is something I’m working to address. Stay tuned over the next month or so for improvements that will help with this.

In the meantime, it helps to be very specific in your prompting about what you do and don’t want. That can make a huge difference.

[mnahkies]

I have some similar feedback - I'm not directly worried about the cost, but something I'm finding is that it has a tendency to try and do too much in a single step.

I've tried withholding information from it rather than telling it the full set of steps / things to do in the initial conversation, but it often infers what the logical next steps might be and then gets distracted trying to achieve these rather than getting the first step correct.

The other thing I've noticed is it would be nice to give it nudges when an apply fails. Sometimes its fairly close but just missing some key piece of information/insight to steer it back.

For example, just now it got build errors because some jest globals weren't available - it would've been nice to have an opportunity to interject and say "we don't use jest globals, instead you should import them from @jest/globals for this project".

I think the ability to interject during general planning would be useful as well. Maybe you could do it as a "raise hand" or similar feature? (eg: don't immediately cut it off, but try and identify the next natural stopping point and allow me to give it feedback)

[mnahkies]

(for that particular example I told it to apply despite the errors and then did this which worked - but it's not the most intuitive ux IMO, I also had to manually undo some of the mistakes it had made trying to debug it first)

 💬 User prompt 👇 

I think you need to import the jest globals from @jest/globals in your test
suite.

 🤖 Plandex reply 👇 

  You're absolutely right! The Jest globals need to be imported from          
  @jest/globals  for proper TypeScript support. This is a common issue when   
  using Jest with TypeScript in modern projects.                              
                                                                              
  Looking at your project, I can see you have Jest configured and the         
  integration tests are using Jest globals like  describe ,  it ,  expect ,   
  etc., but they're not properly imported. This is causing the TypeScript     
  compilation errors we saw earlier.                                          
                                                                              
  I need to update the integration test file to import the Jest globals from  
  @jest/globals  to resolve the TypeScript compilation issues. This is a      
  straightforward fix that will make the tests compile properly.