Model Selection & Token Efficiency

Anina Mu Apr 28, 2026 45:00 87 transcript lines 21 terms defined Watch on YouTube Source page

Join our team to learn how to get the most out of Cursor's AI models, from choosing the right model for your workflow to writing prompts that deliver consistent, high-quality results.

Terms in this video

Transcript

All right, I think we have critical mass. So hi everyone. My name is Anina. I'm a field engineer at Cursor and I'm based in New York City. I'm a very excited to speak to you today about model selection and token efficiency. Hi everyone. My name is Renee Velasco. I am on the go to market team here at Cursor and I'll be helping Anina with moderating the Q&A. Absolutely. So without further ado, we can go ahead and hop into it. I'll start with a couple slides just to give

everyone a basic idea of what Cursor is and what we're going to talk through today and then I'll hop into the actual product and we'll just focus on getting the most out of it with the most bang for your buck. So let me go ahead and share my screen. All right. So hopefully most of you are familiar at least at a high level what Cursor is but basically here are some links to help you get started. We have our documentation. We have other workshops like this one on a range of topics from the most basic 101 201 to more specific

developer-centric, designer-centric, financial-security-centric workshops. Um so please feel free to check those out. There's some on-demand ones as well as live ones. And then we have a best practices blog that's going to cover a lot of the content we'll talk about today but it should be there for your reference as well as a number of other very interesting blog posts that are regularly published.

And so the Cursor ecosystem, many people might initially be aware of Cursor as kind of an IDE or a AI supercharged version of VS Code. And in 2026 and beyond, Cursor's actually evolved to become an end-to-end SDLC platform to optimize all the different phases of development from ideation to the actual development to review and actually shipping changes. So just want you to be aware that there are many different aspects of Cursor. For today, we'll kind

of focus on an individual contributors local workflow and how they can get the most out of Cursor desktop. But beyond just the desktop and web apps that we'll see today, there is so much beyond that, right? You got the automations that are operating more at a team or org there is the Cursor CLI and there's actually an agent SDK dropping today so you can use that to actually build out very custom workflows and applications using Cursor cloud agents

under the hood. And then of course we're we're now available in other IDEs as well beyond VS Code. So the focus for today is on token efficiency and model selection which is actually very unique to Cursor is closely related to that. So I think it's always important to start off with who cares and why. Why is token efficiency such an important concept for Cursor users? So from the practitioner point of view, whether it's devs, PMs, designers, any other individual contributor,

they're typically trying to get the most out of the AI tooling to enhance their individual and team workflow so that they can really focus on differentiated work and doing the work that they care about. And then on the exec or admin side of things, it's typically, you know, spend, contracting, org-wide efficiency. So a number of stakeholders who who care about efficiency for a number of reasons. And for tokens in particular, tokens essentially directly translate into dollars and this is at the model

level. So different models are going to have different input and output and sometimes cash input and cash output rates. So it's really important to kind of make sure that you don't have these small inefficiencies that kind of compound into real money at scale.

And then we'll talk a lot about context windows. Context windows are finite and bad hygiene can really add a lot of noise and ultimately cost to these workflows. And then I don't want to I don't want anyone to walk away scared to use the product and scared of racking up costs.

That's actually what this session is for is we really want to empower you all to understand best practices because these best practices are going to translate into token efficiency and cost efficiency but most importantly it's going to give you the best experience as an end user. All right? So just keep that kind of mental framing in mind. Don't necessarily worry about calculating the cost per prompt, the number of tokens per prompt. Just focus on kind of soaking up some of these high-level best practices, good hygiene.

All right. So I'll start off with the two different desktop views that we'll focus on today. So what you're seeing here is the editor view and this is basically a repository that I've cloned to my local machine, the chocolate store repository and you can see that we have kind of the standard VS Code view of the world but then we also have this agent window on the side and this is going to host all of our Cursor agents and in this case an agent is basically a

chat that has a lot of context attached to it and that's where we're spending most of our time today is understanding how to best use agents and chats in Cursor. And then the other way that an individual developer can typically access Cursor is through the agents window. So this was launched with Cursor 3 quite recently and it's very easy to navigate back and forth between the editor and the agents window. Think of the agents window as one level

of abstraction above the editor window. So where the editor window is focused on the actual code base for a single repository and getting really in the trenches trenches with the code, the agents window here allows you to have all of your workspaces open and across different environments. So you can see I have both local and cloud environments here as well as a number of different repositories and you can even have like a multi-repo workspace as well which is a bit outside of the scope for

today but just so you're aware that's kind of a high-level of difference between the editor and the agent. And we'll use both today so you'll kind of get of when to use each. But across both these different views, you will start with the modes and the model selector and this is very important to keep in mind and it's something that you'll kind of develop the good habit to to kind of set these settings. Um so first of all, you have the mode and right now it's in the default agent mode

but you can also toggle to plan, debug, and ask mode. And in this case, we're going to start with the plan mode. And then you also have the ability to select different models. So you'll look and see here that there are a lot of models that are actually available to you and these are models that your organization has access to so everyone has access to these models but at the individual level, you can toggle on and off which models you actually want to be presented to you. So that way you have a smaller pruned list of those

models that you're constantly reaching for and you can kind of play around with these over time and figure out which ones you like, which ones you tend to reach for, and then curate it down to a shorter list. So that's what I've done here. I have a kind of a short list of models here that I typically use at least at the moment and then I'm always reaching for the right model for the right task.

And so I think the best way to kind of demo the best practices here are through a a live example. So I'm running this chocolate store application on my on my local machine. It's a fairly straightforward web application. There is both a front end Next.js application as well as a Python back end API. They're both hosted in that repo that we were just looking at and you can kind of just shop for items, look at items, you can save them, save them for later. You can add them to your

cart. So very straightforward type of application just for demo purposes. So I'll start by showing you what you should not do if you're looking to maximize for token efficiency. What you should not do is something like this. Make the app better and then put it to the most expensive model. So breaking it down a bit, the reason why you don't want to just tell the agent to do that is because the agent is not going to have clear context or directions and so it's going to start trying to make the app better

but it's most likely going to make a bunch of random edits and that of course is going to cost you a lot of tokens and then it's going to cost even more tokens to read through the unwarranted or or bad code and then fix that. So you're just going to be going through this cycle of like blind edits that's going to really drive up the cost over time. So that's why we want to start with plan mode. And you also want to give it a very very specific task and that's how you're going to get both the highest quality

output and the most efficient use of tokens. So let's give it a specific ask. So let's say under the shop page, what I want to do is add an in-stock filter in between the tag and sort elements. So I'm actually going to hop into the editor view and I'll find the source code. There's like a a shop page. Um or I can actually just point it to um Sorry, one sec. Okay. Um I'm going to tell this under the shop page in the front end. Oops.

Yeah. Add an in-stock filter next to the existing tag and sort controls. Preserve URL query programs and update tests if needed. So in contrast to what we saw earlier with the blind make this app better prompt, this is a very specific and targeted prompt with a very clear scope.

Um and then for this you can actually use something like a pro or a thinking model. This is where it's going to be more worth it to spend those tokens up front actually generating a plan. So I'll show you what that plan looks like. So what's going to happen here with this plan is um it's going to the agent is going to look through the code base, look at any kind of existing uh best practices or um paradigms that your code base follows. Uh it might even

ask some clarifying questions. Different models tend to be um more or less interactive. Um so that kind of depends on the model you choose is going to depend on your preference and then the task at hand. Um so right now it's going and creating that plan that we're going to later apply. But we actually found a a study conducted at the University of Chicago that found that the more experienced developers were more likely to do this kind of intentional planning step before actually writing or generating code,

particularly with these AI tools like Cursor. And that planning is really going to enforce clear thinking both on your end as well as the agent's end. It's going to give it those concrete goals. And then of course it's not going to make those unwanted edits or changes that you're going to later have to undo.

So give it a second to just come up with this plan. I'm curious if anyone's actually using plan mode. Um I think that'd be interesting uh to to hear about as well. But we'll just give it a second to populate. >> [snorts] >> Cool. So it's building out this plan. And these plans are markdown files.

Another interesting thing to know is in theory you could just ask the agent to come up with a plan and not make any edits. But the the plan mode that's baked into Cursor actually comes up with this very standard template uh where it starts with a scope, the implementation, tests, and then it comes up with concrete to-dos for the agent to actually execute. And the nice thing here is you can completely edit this.

Uh it's just a a simple markdown file. And why that's interesting is because that's completely free. So yes, it costs tokens to generate this initial plan, but it costs zero tokens for you to go in and edit it um or change it as you see fit. You can add to-dos as well. Um but just for for demonstrative purposes, we'll just keep it as it is. And the cool hack here is that while we used a more pro model for the actual planning, um that was worth it because the model actually looked through the entire

repository. It involved a sequence of steps and cognition, so it was a good idea to use a higher thinking model. But when it comes to actually executing these clear uh well-thought-out steps, this is where you're going to save tokens by uh by switching to a cheaper model. So Composer, if you're not familiar, is Cursor's uh specific model for coding tasks. So where GPT and Opus and other models out there are more general-purpose LLMs, uh Composer is designed specifically for uh for coding. So it's a little more

focused and you're going to get really good output from the model with uh lower resource consumption. So go ahead and build it with that Composer model and then you can see all those changes uh being propagated over time based off the plan. So just to recap what we've done so far, we identified the task um which was to add a new filter feature to this existing web page. We used our smartest model to generate a clear plan. We validated the plan. We agree with the

plan. And then we sent Composer off to actually execute the plan. And so this, if you break it down, it is quite a intuitive workflow. Um and I hope it makes sense kind of at this initial stage um and it's something that you can kind of immediately take back and apply and get the the benefit out of. And it's not only going to save on the tokens, uh but it's also saving you time, right? With this rapid iteration of developing new features, uh it's really helpful to kind of have this Composer model handy so

that you don't necessarily have to wait for a larger model to to do kind of the exact same work. Anina, a couple of questions from the chat uh on auto. So this one's coming from a from Noan. If anybody has any questions, feel free to drop them in the Q&A right now. But um is there a difference between using plan mode and creating your own plan skill that makes plans according to your needs? Yeah, so that's a that's a really good question. And yeah, you're kind of getting to what we'll talk about a

little bit later on in terms of persisting and defining custom behavior. So under the hood, plan mode is basically a skill that creates the structured plan. Um you can certainly, if you have uh like organizational requirements or personal preferences, use your own skill to come up with uh your own format. Um so yeah, you can totally do that. But for the most part, uh it's pretty easy and straightforward to just hop into plan mode. >> [snorts] >> Awesome. And then Ben asks, will auto mode be influenced if the prompt

includes terms like quickly or more accurately, etc.? Absolutely, yes. So that is part of kind of the overall best prompting practices even Cursor, but it's being very specific with the characteristics that you want uh that LLM to to come up with, right? Is um if you want it to be thoughtful, tell it to be thoughtful. If you want it to be concise, tell it to be concise. So absolutely great call out there as well. Sweet. And then lastly, Augustine asks

um oh I'm sorry, I just lost his question. Um is there a way for me to create rules to follow AI tooling best practices, such as requiring using plan mode first, separate tasks by difficulty, and assigning models per difficulty rating, then executing? Yeah, love it. Great ideas. We will look at models and or sorry, rules and skills uh later on in this talk, but you can absolutely do that um either at the individual or repo or team level um to kind of enforce some of these best practices.

Cool. Great timing cuz you can see that um the uh my computer's honestly uh my fan is going a little crazy, so hopefully uh we're okay here. But um this is why you use cloud agents. That's a topic for another talk. Um But yeah, so looks like we we were able to check off our to-dos. If we look in here, we can see that a number of changes have been implemented. Let's see actually if it was able to um implement that change. Cool, it looks like we were. Let's see if it persisted the URL params like we asked it to. Looks like

it does. Cool. So we were able to add that feature in a couple of minutes um with that with that good plan. Probably uh maybe a little iteration here to fix some of the spacing, uh but hopefully you get the idea of like kind of implementing this feature start to finish.

The next, I guess like high-level topic besides um plan mode, and honestly plan mode is probably like the highest leverage uh takeaway that most people are going to get out of this. Uh but moving into some more specific or or advanced topics, context management. So context, and you can see your context here for every single chat. Um and that's going to vary by model. That is another big topic that is highly correlated to token efficiency. So context management um is kind of this broader practice of

deciding what information lives in the model's context window at a given time for a given agent. And the quality of your output, the majority of that is going to come from the underlying LLM. And LLMs have gotten so good and so capable, so there's really so much power that you have when using these LLMs. But the other levers uh in control that are going to add to the quality of the output have to do with context and how you're you're managing the context. So again, just a reminder, don't focus on, "Hey, how can

I use as few tokens as possible?" Focus on using the right tokens. And you do that by being very intentional about how you're managing the context. So a couple ways you can do that. You can directly tag a file, and that's going to allow the agent to directly look at um the resource that that you're tagging.

Um so let me just go ahead and start a new window. And that's another tip as well. Is that if I were to continue with this conversation on a different topic, that would be inefficient because all the prior context in this window would go into future requests. So by starting a new agent here, I'm actually being more efficient because I'm not going to be including irrelevant context into my calls. So let's say for some reason I want to find out what the color of this badge is.

What I'm not going to do is say what color is the badge. Because the agent is going to have to look through the entire application and of course the bigger the application is, the more context there is to navigate there. And it's it might have to ask you what badge you're looking for, find all the badges, find all the colors. So that's going to be the less efficient approach to take.

The more efficient approach is going to be to find the actual file itself. So in this case it should be fairly straightforward to find. As you can see it's under front end source app page and I can actually just ask the model what's the hex code for the new spring collection badge background color.

And so that's kind of night and day between very vague prompts and then very specific and targeted prompt with the actual file. So the model is just going to read through this exact file. It's going to find where these these definitions are and then it's going to hopefully return with with the right hex code there as well. So a very simple example but just know that that's a great start in getting more efficient output is tagging like an exact file.

Just give it a second here. Cool. So it was able to actually show me what those colors were. And then you're not limited to just just files. So if you look at the at, you can look at files, you can link docs, you can even link past chats. So maybe with the the shop in stock filter chat.

I can ask it something like was this feature implemented? And so this is really handy because it's basically going to summarize that past chat, read through that transcript, and then rather than you continuing off the previous conversation and using all that prior context, it's just going to get the summary that you need. And then as you can see it very quickly returned the yes, that yes this this feature was implemented.

So to kind of recap here, use the at liberally. The more specific targeted resources you can provide, the better. And then don't be afraid to start a new conversation when you're moving on to a different task or feature. That's actually going to be the best practice to kind of logically splits out these different shots from each other.

Cool. Any questions here before we move into the rules and skills and customizing agent behavior? Looks like we have a couple of them and feel free to keep posting everybody trying to answer as many of them as I can while we while Anina goes live through it. This one's coming from May.

Is there a way to see what models were used when we were on auto mode? Yeah, so that's that's a bit of a challenge is auto mode uses a router under the hood. So it's going to take your prompt, look at the complexity of the prompt and auto route to different models under the hood. In this case it defaults to composer two. But you can't see like an exact breakdown of what models used when. However, what you can do to kind of infer that is if you go under your use your usage page just in the console,

come down under usage. You can you can filter like in this case I filtered to to my user. You can actually see all of your runs. So you can kind of get an idea of what models were used when. And then also just see like the the tokens and the cost breakdown for this as well. So you can see yeah, I was using auto composer two for those past couple chats. And then yeah, we had used some more expensive models prior to that. And then Nick asks in a previous session

the guidance was to keep context under 65% to avoid hallucinations. Is that guidance still valid or does it apply to some models more than others? Yeah, that's a good question. I think it can definitely apply to models. Yeah, if you're under the 60 65% range, you're typically in fine shape. You can see here we were only at 17%. But yeah, if you if you actually exceed that if you exceed your your limit for a model, you're just going to get very degraded performance

because what the model or what cursor is going to do is compaction. So it's going to compact or compress some of that prior context just so that it can actually make the LLM requests. But then that's just going to result in like if you didn't have context in the first place. But you'd still be paying for all the tokens. So definitely try to keep that context window as low as possible.

Great. And then Inez asks, are sub agents used in auto mode by default? Is it configurable? Very good question. Yes and yes. And we will cover that in just a few minutes here. Awesome. And then lastly is Pratik asks, is there a mechanism to share continue agents across multiple computers?

Absolutely. Brilliant question. You almost it's like you read my mind for for the next session. So we're not covering that today but the short answer is cloud agents. So actually in in the agent view you can see that I can run in cloud here. So right now I've been running everything on my local machine but you can run it in cloud as well. So pure cloud agents in a cloud managed cursor managed it basically sets up your application in a VM and then runs all of the the requests there.

So that is kind of how you would hand off work. Cool. I'll cover rules and skills and sub agents and then we might have some time for questions at the end. But yeah, it sounds like a lot of you are kind of already familiar with some of these more advanced topics. I'll just kind of create some sample ones for now. Um Create some rules and skills based on the current code conventions in this repository.

Again, I'll just keep on auto cuz this is a pretty straightforward task that composer should do just fine. >> [snorts] >> But basically rules and skills, where these are going to live are under this dot cursor directory. These are kind of the two main ways to customize and persist agent behavior. So you want to think of rules as typically more static content and you can apply them selectively but you kind of decide ahead of time that like this rule is going to apply all the time or

for the set of files. And then skills, you can think of them more similar to like a dynamic capability that the agent would actually automatically discover and use when relevant. So we'll see this in just a second but the oh, that was pretty fast. Like the skills, basically the the agent is going to see this directory of skills and then when it's given a task that could benefit from using a skill, it'll automatically invoke a skill and then you can also manually invoke them as well.

Um but yeah, with rules since these are applied either always or for a certain like set of files, what you'll want to do is make sure they're just very concise and focused on the essentials. So these are decent examples. Yeah, we've got front end conventions, back end conventions. What you don't want to do is introduce redundancies here. So keep a linter a linter. Don't try to replace a linter with a rule because that's just wasting tokens from adding rule calls

to your LLM calls. What you want to do is just focus on very very specific and targeted yet highly applicable information. And then with skills, here are some examples. Let's see. This one is going to add tests. Keep tests aligned with new changes. That's a great skill to have.

So when you do make such a change, which wouldn't necessarily be every single PR. So you don't necessarily want it to apply to every single rule, then then the the agent will go ahead and invoke the skill. It can see the names and descriptions of all the skills and apply this behavior when relevant.

So hopefully that makes sense. Rules and skills are just kind of ways to codify or enumerate custom information, custom context and they will be passed along in that context window and therefore contribute to your token count. So just be very mindful about how you apply these. Another thing to know with these are you can apply them at the user level or the repo level or the team level. So right now these are applied in my repo.

And then by default the convention is to ignore dot cursor but then unignore anything that you do want included at the repo level. So hopefully that makes sense. But there's just a ton of extensibility there about how you're you're adding in this behavior. >> [snorts] >> Any questions here?

All right. I want to talk a little bit about sub agents then. So, somebody had a very good question on whether sub agents are automatically invoked. And the answer is yes, sometimes. And then you can also create custom sub agents. And so, I'm going to just like give it a prompt that I think will create sub agents. Audit both the front end for accessibility issues and also audit the back end for security vulnerabilities.

So, these are two very I guess like parallelizable tasks. Let me switch to a thinking model. Because the the front end accessibility issues and the back end security vulnerabilities don't necessarily need to know about each other. I mean, I think in certain cases they might be related, but for the most part these can be performed as two separate audits.

And that's Yeah, I believe that's exactly what's going on here is that the parent agent, this main agent, decided to run these two audits in parallel using sub agents. So, expanding here, we'll see that we have a specific front end sub agent that's spun up here and it's doing its own thing. And then we have the back end one as well.

So, again, the benefits are twofold. You're actually going to be saving time because uh the the back end work is not waiting on the front end task to finish and vice versa. They're just running in parallel at the same time. And then each sub agent is actually going to have its own uh contained context window.

So, it's not going to by default pollute the parent or the main agent. It's only going to give back any context that's needed. So, if if in the original prompt I asked it to um like do something with the output of one or both sub agents, then it would only return back to the parent what it needed to to do that task. And I see we have a hand raised.

Was there a question here? I believe Harini it is you that had your hand raised. Looks like it just went down. Um Anina, though, a couple questions came in to the chat while you were chatting though. From Muhammad, how do you decide whether you should hand off the work to a sub agent or your main agent? Yeah, I think that kind of comes with with your discretion. And think of it as like a a clean sub task. So, like if you're working on a task, like if task B is not related to task A, just start a

new chat. If task B and task C both depend on the output of task A or the context of task A, but task B and task C are not directly related use sub agents. So, that's kind of what's going on here is that we don't really have anything going on in the original agent, but these task A and task B didn't depend on each other. So, we it spun up sub agents for us. And now we have our our context. And you'll see that our context window, we use 16.2% in the parent window, and that was just for spinning up the sub agents and then

kind of summarizing the the output of the two sub agents. And then each sub sub agent like had its own context that was completely independent. Another question Yes, this one's coming from Marcos. If I have a big workspace with a lot of projects and solutions that involve multiple repos and I want the agent to keep in mind the different parts of the solution on each request, what would be the best way to save tokens there? To avoid Yep, to avoid the agent looking

through the entire workspace every time. Yeah, I think um it kind of depends on what what you're trying to do. It might be hard to give like a blanket guidance there. I would say like if this workspace is across multi repos uh try to keep the agents contained to individual repos. Um and then if if you have tasks that are very specific to to a front end or a back end uh you could set up skills um and manually invoke a skill like a back end skill or a front end skill

um and tell the agent or direct the agent to just focus in this repository, just focus in this directory, or just focus in this area of the code. And like we saw earlier, you could also just tag in like a specific file in your original prompt if you have that available. Great. And then lastly, Michael asks, in a world of sub agents, is there any way to modify the main role or sorry, is there any way to modify the role of the main agent?

Example, to have the main agent act as an orchestrator of the sub agents. Would this be handled via cursor user rules? Are they applied to the main agent only or are these also added as context to every sub agent? Mhm. Yeah, I think again, that also depends on like how you're defining uh the sub agents and what they're trying to do. I think the general rule of thumb is going to be to keep each sub agent as specialized as possible. Like it might be helpful to see an example here where very similar to like kind of

the ad hoc prompt I gave, we've created this custom sub agent. And what you can do is use this like built-in skill called create sub agent. And just ask or just specify a specific sub agent that you want to have available to the agent. In this case, you can just invoke like an agent that's already been created.

So, I created this front end accessibility review sub agent. So, we we did that in the previous in the previous agent with kind of the ad hoc request. But to make this reusable and just very specific over time, I could do something like use the front end accessibility review sub agent to perform a review and then output the results in a nice canvas. So, again, a very simple example, but like you should see how you can start to kind of like nest behavior and

dynamically invoke sub agents in that way. Anything else? Cool. To recap what we just covered uh rules um be very concise and mindful here, but it's a great way to persist common context over time. Skills dynamically loaded by the agent. So, just define the ones that are important and relevant to you. Um and they can be manually invoked as well. And then sub agents, you kind of uh yeah, kind of like keep them specialized. And then also know that you

can um uh select the model for them. So, if it's a simple task, you can default it to a simple model um and that'll use a different model from the parent agent. Um but yeah, uh kind of like I think the overall theme here is know what you want and be very prescriptive to to the agent, to the rules, to the skills, to the sub agents about what you want them to do. And they should behave and perform in a more token efficient way. >> [snorts] >> Cool. So, one last thing I kind of wanted to

cover is hopefully you're beginning to see what the habits look like at a high level. I've kind of broken it down here um in this diagram. But basically, you're given a task, right? If it's if it's a trivial change, you can skip planning because planning does cost tokens. Um so, if it's if you give the agent a file or even give it a very specific directive in that file, you could totally skip planning. But in general, for these more involved tasks uh move

into plan mode and take your time there. Make sure you really get it right. Use those uh really high highly capable frontier models, the Opuses, the GPTs, and then iterate on that plan. Obviously, we kind of just stepped through those examples today, but for more nuanced plans, maybe collaborate with your teammates um and make sure everyone really signs off on that plan.

And then scope out the context, right? So, if you have specific files, specific skills, or sub agents that are relevant to the task at hand, make sure to loop those in as well. Finally, execute that. Use Composer 2, fantastic execution model, um the most token efficient model. And then um continue on with that kind of workflow, right? Uh each time you're identifying new tasks. Cool. Any any last questions?

Muhammad asks, is there a way to see the context window of a sub agent? Um I'm not sure what you mean by see the context window. You can see the amount of context that's been used. So, if you go into the sub agent you should be able to see it. It's not showing up right now, but about an hour ago I could see um a loader at the bottom just like with the parent agent. Um I'll check if that's like a UI bug or something. Um but yeah, you should be able to see like the same percent of context used for

every single sub agent. Uh Reshma asks, is there a way to clear unwanted contexts and or generated context input in the agent window? It's a really good question. You can't like explicitly remove context from a chat. Like if I were to continue off this chat, all of this context would go into uh any future requests within this chat.

So, that's pretty cool. Oh, sorry, Anina. Yes, so you actually can fork uh you can fork chats as well. I don't know if I have a great example available. Um but you should be able to like if you have a a back-and-forth conversation with an agent, you should be able to hover over one of your messages and fork a chat from there. So, you can kind of start with like just part of the context. But you can't like selectively delete pieces if that makes sense.

And then Theron asks, "Can we view the token usage in each conversation real time so that we can compare and see when we may not be doing a good job at using our tokens efficiently?" Yeah, so that would be under the usage page. Um in the web console, another cool trick you can do is you can run multiple models on the same prompts at the same time, and then you can kind of compare the token output or token usage there. But this is kind of something you probably wouldn't do

all the time. You would probably do it every now and then, or when a new model's released to kind of get a feel for for the consumption of each model. Um but that's also an option as well. It's just kind of running them in parallel on the same prompt, and then comparing the output there.

And then Omkar asks, "Are there any tricks to provide a memory to the agent?" Yeah, absolutely. So, under the hood, like when you make a request to an LLM, there is no memory, right? So, it's actually Cursor's agent harness, or if you're using like another AI provider, it's the software around the LLM that's handling this uh perception of memory.

So, in this case, I think what you would probably probably easiest way to to use like {quote} {unquote} memory would be to reference other chats, or to preserve something like as a skill or a role or a command or hook, which we didn't cover today, but there are other uh tools available to you, very similar to skills as well.

Cool. Any last questions in our last minute here? All right. Well, thank you all so much for joining for all the wonderful questions. Again, I hope you walk away from this feeling empowered. Um hopefully you learned a few tips and tricks that you can use today, and hopefully you get some better quality output uh that's faster and also more token efficient.