Loading video player...
With the advancement of AI and the
increasing power of each new model being
released, the way we produce code has
been completely transformed. There are
now many tools specialized for coding
like claude code, cursor, anti-gravity,
and others, each with its own unique
capabilities. But good models alone
don't determine the quality of the code
you produce. How you use the tool and
manage context matters just as much. All
of these tools have some inherent
mechanism for context engineering, but
cursor just made a major push for a new
approach, building it natively into the
app itself. As I went through their
article, I realized these principles are
genuinely strong. We have a lot to talk
about today because these ideas can be
applied broadly to any platform you use
to build applications. Context
management has always been critical when
working with AI agents because good
context management determines the output
quality. We have previously talked in
our videos about how important context
management is and talked about workflows
for it. Cursor implemented context
management features directly into their
product and released an article about
it. These principles are based on their
observation that to get good results
from models, it's better to provide as
few details as possible in the context
window. The less information the model
receives at once, the less data it has
to process at once, meaning lesser
confusion and more focus on the task it
needs to do at the moment because only
relevant information is included. This
approach is what they call dynamic
context discovery. The idea is
structured note-taking. That is the
information not needed right now should
not be in the context window. Excluding
potentially confusing or contradictory
details improves the quality of the
agents responses significantly. Cursor's
current release adds five dynamic
context management methods rolling out
to users soon. Even though cursor is
implementing this as a product update,
these principles are widely transferable
to all AI agents. The first update
cursor mentioned is that long tool
responses should go into files. MCPS
often return large responses that stay
in the context window. Not all of the
information from the responses is always
needed. Cursor mentioned that the common
approach of the most coding tools is to
truncate long MCP responses which leads
to data loss or important information
that might be necessary for the context
being removed. Claude's Chrome extension
is a very tool-heavy extension and just
a few prompts can fill up the context
because of loading a huge chunk into the
context window. So, I added an
instruction in the claw.md file that any
MCP tool response greater than 50 lines
must be saved to an MCP folder within
the context folder by running an echo
command in the terminal. When I ran the
Chrome extension to analyze the UI of a
landing page, whenever Claude came
across a tool like read page that
significantly bloat the context window,
it saved the MCP response into a file
for further reading using which it
analyzed the whole page and gave me a
report. This workaround improved the
accuracy of the tool response analysis
by letting Claude analyze the responses
from files as many times as needed and
eliminated the need for repetitive tool
calls. When data from previous MCP calls
is needed, Claude can read it directly
from the context folder instead of
making tool calls, saving significant
time. Before we move on to the next
change, let's hear it from our sponsor,
Zenrose. If you're building AI products,
automations, or datadriven systems, you
already know one thing. Everything
starts with reliable web data, but
getting clean, structured data at scale
is harder than it sounds. That's where
Zenrose fits perfectly into the stack.
Zenrose handles data extraction from
complex websites while automatically
managing antibbot bypass so you can
focus on what actually matters using the
data. Instead of dealing with messy
outputs, Zenrose delivers structured
results like JSON or Markdown, ready to
plug directly into your pipelines. It's
integration ready and business focused,
which makes it ideal for AI startups,
data teams, and automation builders who
don't want to babysit infrastructure.
Whether you're enriching leads, powering
AI agents, or automating research,
Zenrose just works. If your work depends
on web data, Zenrose belongs in your
stack. Click the link in the pinned
comment and start building today. We
know that the summarization step when
the context window is filled is messy
and leads to losing a lot of
information. Most tools including cursor
and clawed code trigger a summarization
step and start the session with a fresh
context window with the summary as a
starting point. When you hit compact
again and again, the summary starts to
forget details that might be important
to you but that the model summary may
miss. There is only so much control you
have over autocompaction and repeated
compression leads to the loss of crucial
information if you have to do it
repeatedly. Cursor's solution is to save
all previous chat history as a file for
the agent to reference later. When we
provide a very specific prompt and the
model cannot find the information in the
summary, the previous transcript serves
as its knowledge base. The model uses
that transcript to generate the solution
allowing it to recover anything that was
lost from the summary until cursors
implementation rolls out and becomes
available for everyone. I tried
implementing this feature with clawed
code. I added the instruction inside the
claw.md file to update the chat history
after each turn, documenting all the key
decisions and steps taken. It used a
history folder inside the docontext
folder with each file's name reflecting
the session. So whenever I ask it to
perform any task at the end of its task
execution session, it documents the chat
history into the corresponding history
file, adding everything to that file.
This way the context folder contains
detailed records of all sessions and
everything that was done. Agents were
given skills to help manage the context
problem MCPs were causing. The whole
purpose of skills is to make agents
provide better ability to use its own
capabilities by guiding through scripts
and instruction files, reducing context
bloat by progressive disclosure.
Anthropic was the first to come up with
the idea which is basically giving the
agents a set of instructions, scripts,
and resources that the agent can
discover and use to perform better at
specific tasks. Anthropic basically
open- sourced these agent skills,
setting a standard that others could
implement. Following this, Codeex,
Gemini, and others started implementing
agent skills. After which, it was
finally cursor's turn to do the same.
Cursor skills are basically the same
executables and scripts bundled together
into a single skill that the agent can
use for its respective tasks. Only the
skills name and description are in the
static context. Once they are inside the
static context, the agents can pull
their skills on their own using Grep and
cursor semantic search. This is what
makes it different because cursor
semantic search uses its own embedding
model and indexing pipelines in the
background instead of plain pattern
matching like regx based searches in GP
commands. Claude skills only expose the
name and description in the context no
matter how many files the script uses,
preventing context bloat. In my project,
I had configured five skills, each
consuming very few tokens, only about
0.2% of the total, leaving more room for
working. What's different is that Claude
skills can also be accessed via
/comands, letting you manually trigger
them whenever needed, addressing
people's complaints about skills not
being loaded on demand properly. MCPS
contain a lot of tools, all exposed in
the context window, bloating the context
window unnecessarily. Cursor took it
upon themselves and emphasized that it
is the responsibility of the coding
agents, not the MCP servers, to fix the
context bloat. The solution for this was
dynamic context discovery by syncing
tool descriptions in a folder. Cursor's
idea is to have all of the MCPS with
their names in separate folders named
after each connected MCP. And within
each folder, all the tools must be
listed. With this, the agent only
receives the names of tools. And
whenever it needs any tool, it looks it
up through the folders. In the testing
they did, they discovered that dynamic
discovery of MCP tools reduced usage by
46.9%
which makes a huge difference if you are
working on a longunning system. This
implementation also helps in cases where
MCP servers accidentally get
disconnected or require
reauthentication. Normally the system
would just forget about those tools but
now the agent can actually notify the
user that reauthentication is required.
Claude also has an advanced search tool
that is specifically designed to address
this problem using a certain set of
flags to let Claude know whether to load
it or not. It implements Cursor's exact
idea of dynamic context discovery, but
this is limited to the developer
platform and only for those building
with APIs. We cannot modify how MCPS are
used in cloud code because they are
built into it by anthropic. Just as I
was looking for ways to implement this
in cloud code, I came across a hidden
flag. Without setting this flag, all the
MCP tools I had connected were exposed
in the context of clawed code. When I
set the enable experimental MCP CLI
flag, all the tools were removed from
the context window, freeing up space
that was previously occupied by the MCP
tools. But that does not mean the MCPS
get disconnected when this CLI is
enabled. The only difference is that
they are not exposed up front in the
context window. Instead of putting all
the schemas into the context, Claude now
uses a middle bash layer called MCPLI
which handles all MCP related tasks.
Claude uses this middle layer to search,
get information, and invoke the tools.
Whenever you ask Claude to perform any
task that requires an MCP tool call
instead of using the usual method, it
uses the MCPS via MCP CLI and performs
the task it is required to do. By using
this tool, Claude executes all the tasks
as usual, just through this middle
layer. Reporting terminal errors is hard
in cursor because of its limited access.
If the terminal showed any error, you
needed to add it to the chat and then
have it fixed. Cursor's solution for
this is also moving the terminal
sessions to files. So whenever you ask
it any questions, it references those
history files and uses GP to extract the
relevant output. Since server logs are
usually longunning and contain lots of
noise for the agent, using the Grep task
is more efficient because it lets the
agent pattern match. They got this idea
from CLI based coding agents which run
the commands but then the output is
injected into the context exactly the
way claude code and others do by
default. Even though claude
intelligently handles this on its own,
we can manage it even further by using
instructions in claude.md to instruct it
to add all terminal logs into a file in
the terminal folder inside the context
folder. Basically, if Claude runs any
npm command, it runs a special command
that logs both the output stream and the
input stream into the document files.
Here, two represents the standard error
stream and one represents the standard
output stream. It writes these logs to
the terminal folder marking them with a
timestamp. Then, whenever it needs to
search through them, it simply uses a GP
command with a specified pattern and
loads the last 20 lines to extract only
what matters. So whenever I tested my
development server, it used these
commands and kept writing the terminal
runs to files in accordance with the
claude.md file. After running the
server, it referred to the log files and
figured out what was causing the issue
and fixed the problem for me. Now, even
though this add-on to claude code might
seem insignificant because it doesn't
appear to have much impact on immediate
work, it can be very useful when you
want to refer back to your app's
functioning. Just like when I needed to
identify which service was causing my
app to crash, I simply told Claude to
refer to the test logs instead of
running the tests again, saving me from
rerunning a 2-minute test suite just to
reproduce an error I had already seen.
That brings us to the end of this video.
If you'd like to support the channel and
help us keep making videos like this,
you can do so by using the super thanks
button below. As always, thank you for
watching and I'll see you in the next
one.
Cursor just shipped native context management for ai coding. This cursor ai tutorial shows how to use cursor ai's new system and apply the same methods to claude code today. Discover how ZenRows can simplify web data extraction—explore now: https://rebrand.ly/zenrows Context engineering determines whether your ai tools give you garbage or gold. This video breaks down Cursor's five new dynamic context methods and shows you how to implement them yourself. If you're looking for a cursor ai tutorial or claude code tutorial, this covers both. I walk through the exact claude.md instructions for claude code skills and show how to use claude code with custom context management before Cursor's features fully roll out. Whether you're on cursor ai free, testing a cursor ai pro trial, or hunting for cursor ai free unlimited workarounds, these techniques help you get more from every token. The principles work the same way in chatgpt, google ai studio, or any ai agent you're building. This isn't vibe coding. It's systematic context control that makes artificial intelligence actually useful for coding. Consider this your starter story for building better with ai agents. What's covered: MCP response logging, chat history as retrieval, the hidden experimental MCP CLI flag in Claude Code, terminal session files, and how skills cut context usage by 46.9%. Hashtags: #ai #chatgpt #vibecoding #googleaistudio #cursor #starterstory #claude #coding #aitools #aiagents #artificialintelligence #aiagent