Hi, I wanted to know if “GPT-4” option in Cursor is using GPT-4 or GPT-4 Turbo. If it’s using GPT-4, how could I change it to Turbo?
Thanks.
1 Like
No. Please revert Cursor settings to those used last month.
It’s gpt-4.
if you use your own open-api key, you can choose gpt-4-turbo or gpt-4
I asked Cursor a question about something in early 2023 and it’s telling me it was only trained up to 2021. Is this change rolled out for everyone?
does not use turbo
Our fast mode uses turbo for everyone now. If you’re in the slow pool, we’re currently still using gpt-4-0613, but are hoping to switch that one to turbo as well as soon as possible.
1 Like
Sounds good. Thank you for the update
- Is there an ETA for when the slow requests become turbo?
- For fast requests that use turbo, is the context size still 8k?
1 Like
Probably Monday — OpenAI usually does not work weekends, and we need them to manually change a config. The fast requests still use an 8k context window by default, yes, though we’re exploring how to dynamically adapt the context window and auto-expand it when it would be useful (and ideally give the user some control over that as well).
3 Likes
Did I understand correctly that since the context size remained the same (8k), the only obvious change from the transition to turbo is a more updated knowledge date for GPT? The abilities of turbo to code reviews are contradictory, so it’s hard to consider this an improvement. But in general, people were waiting for turbo because of the updated knowledge date and larger context, without this I don’t see much sense. I will be glad to any news - is an increase in context planned? To what size - will it be 128k, if not, how much and when? This would seem like an obvious advantage over simply using github copilot. Thank you.
1 Like
Update here: we saw a few worrying regressions when using turbo for one of our cmd-k prompts. GPT-4 fast mode is now back to the 0613 version. We’re hoping to update our prompts and switch over to turbo again tomorrow.
Curious to hear what your ideal version would look like here!
One problem with using long context is latency, so increasing the context to 32k across the board is actually a regression in most cases. In our testing, 8k is a sweet spot for having enough context to provide good answers in most cases, and having acceptable time-to-first-token latency in all cases.
That said, definitely want to allow users to control the context window here, and maybe even dynamically adapt on our end.
Without knowing how much context we use, it’s very hard to give an answer.
Something many people have requested is to see how much context used or see tokens, and to be able to toggle on/off what is included in that context.
As an example, when you start a chat and include docs, you don’t see what is going to be used when you press chat, until the response is being generated.
Then when pressing “rerun without context”, sometimes docs are left in (according to the icons showing) that response’s context. So, we can’t really control our context or know what is being used.
I imagine longer context - to a point - is better. When I used turbo through the api I was getting better responses as I didn’t have to repeat information I thought would already be in context from very recent messages and suggestions.
So, basically please let us see tokens and have better control over what is in context.
I would agree that 8k context is usually enough in most cases since if you need to generate code that requires a bit of context you can always just copy and paste bits and parts of the relevant code in your codebase.
Would a 32k+ context be more useful if say I was using references from docs that cursor crawled? That would be the most likely use case for when I would want a larger context. Perhaps when the rules for AI start getting longer as well, is when a larger context might be useful.
Being able to choose the context length is also a good idea to give more control of what information gets used as context. This is why sometimes I just start new chats to get a fresh start.
any updates regarding this?
A bit trickier than we anticipated to switch over our prompts without quality degradation. We’re working on it.
3 Likes
What would be the expected benefit for the user?
Since the turbo models are probably much smaller, it is expected that there is a tradeoff in quality when everything else stays the same.
My hope would be to have better quality due more context information because of the larger context window.
Another thing that came to my mind would be increasing the limit of ~400 lines for the /edit feature (that would be really great! :).
Also since the turbo model is smaller and much cheaper, one would also hope that requests could be served faster and/or the limit of fast-request could potentially be increased.
Are there plans to implement anything like this?
Is there any status update available at this time?
3 Likes
Lol, it’s been a few months since Turbo was released. At this point, I think we can conclude that the Cursor team doesn’t believe this transition is worthwhile. The only sad thing about this is that GPT-4’s knowledge is so strongly outdated. Also, initially, when they talked about Turbo, a much larger context was implied - and I was very interested in this. But as I understood, this is not even discussed, i.e., the context would have been 8k anyway. Then, I repeat, the only thing that is annoying is obsolescence. Are we waiting for the next version of GPT?