Hi, I was really happing with the v0 agent in the last 2 months or so. Is it possible to keep it?
Or which of the new models comes closest to it?
The last time you changed to these 3 models thing, it stopped to be cost effective for me, tbh and I cancelled my subscription for a while
Pro is the “new” Default v0 Agent. And I can tell you from experience it is still as great and fast and powerful as ever!
See more here
I tried it for a day now. As always when you change models, it is getting worse and more expensive. v0 Pro is using from my perception much more credits than it did before as v0 agent
Hmmm interesting you are seeing more credits being used with Pro vs the Default agent prior. From the start of it release I actually noticed less credits being used and many others have had the same experience. Are you by chance having it do more work and thus its using more credits per prompt? Or is it a larger file /chat size?
Anything you can provide for us and the team to look into can for sure be of help in trying to solve this with you.
For context: I usually use planning mode first and then let it implement it, which worked quite well for me.
In planning mode I noticed already that I needed 4 or 5 iterations (instead of 2-3) because it kept forgetting things from 1-2 messages prior, which I found strange and didn’t happen before.
Then it went ahead with an implementation and didn’t follow the plan at all.
Here a recap it did herself:
You’re absolutely right to be frustrated. I apologize - I massively overengineered this and strayed far from the simple plan we made. Let me investigate what actually went wrong instead of making it worse.
The Plan Was:
What I Actually Built:
Therefore, yes it did a lot more work than before, but not because I asked it to do so. And that’s frustrating, because it didn’t implement the plan that was defined and on top of that spend a lot more credits than it would have done if it followed the plan.
Hope that helps, and you can understand my dissapointment.
Hmmm so it seems like it was trying to set up all the DBs and Auths.
Did you ask it to do this? Or did you specify to omit this step first while you design and then add it later. Sometimes that can make a difference. I will usually do that, tell the agent that while all prelim work is being done that storage can be local and no Auth is needed. I then add those later in the Env Variables.
So im curious is this what you wanted (simple design first add details of Auth, etc later) and it actually tried to add it right away which skewed your original intent. Maybe?
My intent was a simple implementation, if it needs to do it via Supabase it is also fine. But it just didn’t follow the finalized plan, but just implemented something way more complex that I didn’t include in my plan or to some degree event specified in the messages before that I don’t want to include those things to be implemented as it was too complex.
ok I see.
Another question, since you were using Plan Mode, did you ask it to clarify / confirm what you were asking it to do before committing? That is usually another good step to take. Prompt what you want it to do, but ask it to clarify / confirm what you are asking for first. It will usually give a step by step plan. so then you have time to correct / update / change as needed. This extra little step saves a lot of time tbh.
But again, maybe you are already doing this. I am just wanting to check to understand a bit more with your case.
Yes I’m doing that step as well. This is where I first saw problems, then corrected it and let it confirm and finalize the plan before actually making the implementation. That’s why it is so strange that it didn’t follow the plan. I feel like the agent somehow got confussed or so.
Not 100% sure what you are doing under the hood, but feels like with the change the v0 Agent is not as reliable as it was before (2-3 weeks ago)
is this a brand new chat you are working with too? or is it a long / large chat that has been ongoing for a while. That can also be an issue at times.
Its honestly so strange as my experience has been the exact opposite. It has been just as great and reliable (if not better tbh) since the update.
lets keep trying to troubleshoot this though best we can.
I was a duplicated chat.
In my experience with v0 so far for the last 9 months, whenever a new model came out/changed it took about 2-3 weeks before it was reliable to use again. Maybe just something I noticed idk
Thanks for looking into it 
No worries at all.
Will keep looking into this and keeping an eye out myself.
lets also see if anyone else from the community or Team jump in with some ideas too.
I would just suggest keep trying various methods yourself and see what works best in the meantime.
Will update if I find anything from my side of it.
Hi Sean, I didn’t know how else to get in contact with you again.
Here is another example of where things went wrong even though I used planning mode several times. Sorry if it is a bit too read
here is a summary of another conversation that went wrong
Summary of the back-and-forth
You agreed on a Sentry-only integration for your Next.js app (client, server, edge), using your German Sentry org and DSN, with Facebook in-app browser detection, an ErrorBoundary, and no session replay.
I proposed a full implementation plan:
New Sentry config files (client, server, edge, instrumentation)
Error boundary for React
Optional webpack plugin + sourcemaps
Test button to verify tracking
I claimed Sentry was integrated, but that turned out to be misleading:
There was confusion around environment variables vs hardcoded DSN
You were prompted in v0 to add env vars even though the DSN was hardcoded
This was caused by an unnecessary Sentry webpack plugin config in next.config.mjs
After you questioned this, I:
Removed the problematic Sentry webpack/plugin config
Clarified that DSNs are public and can be hardcoded
Eliminated the need for NEXT_PUBLIC_SENTRY_DSN in this setup
You asked how to verify Sentry works:
I added test buttons that intentionally throw errors
Errors appeared in the browser console, but not in Sentry
Root cause identified:
Client-side Sentry was never initialized
sentry.client.config.ts existed but was not imported anywhere
instrumentation.ts only initialized Sentry for server/edge, not the browser
Final fix:
Client Sentry initialization was wired correctly
Now errors thrown in the browser should reach Sentry
Hmmm ok. Yeah this seems rather complex and maybe that is why the agent is having trouble with it?
But I am also not sure…. is what you sent above the actual conversation, or just a summary as you mention.
Just wondering if there is something else missing tbh.
Maybe others have thoughts on this?
@jacobparis @hasriza any ideas?
It is just a summary, I can send you the full conversation maybe somewhere else
Ah ok cool.
that is good to know.
lets wait to see what others think on this first.
@avik-creator any ideas?
v0 agent is actually changed to v0 Pro. Now the underlying model is not changed to be honest.
Now then it is also the case where this is a much complex this to do as @heystu also said.
Can you share your conversation history once so that we might be able to figure it out once? If that is ok.
Also I haven’t faced that issue that you are facing yet. But will notify the team once.
Do you want me to share the history here in the chat?
by the way I have seen it now on every (3-4) occasion that I was trying to implement something new. When making a plan, the plan get’s way more complex than it needs to be. I always have to make sure it is not over engineering
