I think the emerging best way is to do "agentic search" over files. If you think about it, Claude Code is quite good at navigating large codebases and finding the required context for a problem.
Further, instead of polluting the context of your main agent, you can run a subagent to do search and retrieve the important bits of information and report back to your main agent. This is what Claude Code does if you use the keyword "explore". It starts a subagent with Haiku which reads ten of thousands of tokens in seconds.
From my experience the only shortcoming of this approach right now is that it's slow, and sometimes haiku misses some details in what it reads. These will get better very soon (in one or two generations, we will likely see opus 4.5 level intelligence at haiku speeds/price). For now, if not missing a detail is important for your usecase, you can give the output from the first subagent to a second one and ask the second one to find important details the first one missed. I've found this additional step to catch most things the first search missed. You can try this for yourself with Claude Code: ask it to create a plan for your spec, and then pass the plan to a second Claude Code session and ask it to find gaps and missing files from the plan.
Gemini 3 Flash is very good at the search task (it benchmarks quite close to 3 Pro in coding tasks but is much faster). I believe Amp switch to Gemini Flash for their search agent because it is better.
I open 4 chat windows with Gemini 3.0 Pro. I paste in all file contents to each window. I ask them "which files would an AI need to do $TASK effectively?"
Each of the 4 responses will disagree, despite some overlap. I take the union of the 4 responses as the canonical set of files that an implementer would need to see.
This reduces the risk of missing key files, while increasing the risk of including marginally important files. An easy trade-off.
Then I paste the subset of files into GPT 5.2 Pro, and give it $TASK.
You could replace the upstream process with N codex sessions instead of N gemini chat windows. It doesn't matter.
This process can be automated with structured json outputs, but I haven't bothered yet.
It uses much inference compute. But it's better than missing key inputs and wasting time with hallucinated output.
If you know you will be pruning or otherwise reusing the context across multiple threads, the best place for context that will be retained is at the beginning due to prompt caching - it will reduce the cost and improve the speed.
If not, inserting new context any place other than at the end will cause cache misses and therefore slow down the response and increase cost.
Models also have some bias for tokens at start and end of the context window, so potentially there is a reason to put important instructions in one of those places.
Every time you send a request to a model you're already providing all of the context history along with it. To edit the context, just send a different context history. You can send whatever you want as history, it's entirely up to you and entirely arbitrary.
We only think in conversational turns because that's what we've expected a conversation to 'look like'. But that's just a very deeply ingrained convention.
Forget that there is such a thing as 'turns' in a LLM convo for now, imagine that it's all 'one-shot'.
So you ask A, it responds A1.
But when you and B, and expect B1 - which depends on A and A1 already being in the convo history - consider that you are actually sending that again anyhow.
Behind the scenes when you think you're sending just 'B' (next prompt) you're actually sending A + A1 + B aka including the history.
A and A1 are usually 'cached' but that's not the simplest way to do it, the caching is an optimization.
Without caching the model would just process all of A + A1 + B and B1 in return just the same.
And then A + A1 + B + B1 + C and expect C1 in return.
It just so happens it will cache the state of the convo at your previous turn, and so it's optimized but the key insight is that you can send whatever context you want at any time.
If after you send A + A1 + B + B1 + C and get C1, if you want to then send A + B + C + D and expect D1 ... (basically sending the prompts with no responses) - you can totally do that. It will have to re-process all of that aka no cached state, but it will definitely do it for you.
Heck you can send Z + A + X, or A + A1 + X + Y - or whatever you want.
So in that sense - what you are really sending (if you're using the simplest form API), is sending 'a bunch of content' and 'expecting a response'. That's it. Everything is actually 'one shot' (prefill => response) and that's it. It feels conversational but structural and operational convention.
So the very simple answer to your question is: send whatever context you want. That's it.
We ran into this while building GTWY.ai. What worked for us wasn’t trying to keep a single model “continuously informed”, but breaking work into smaller steps with explicit context passed between them. Long-lived context drifted fast. Short-lived, well-scoped context stayed predictable.
There is no such thing as continuous context. There is only context that you start and stop, which is the same as typing those words in the prompt. To make anything carry over to a second thread, it must be included in the second thread's context.
Rules are just context, too, and all elaborate AI control systems boil down to these contexts and tool calls.
In other words, you can rig it up anyway you like. Only the context in the actual thread (or "continuation," as it used to be called) is sent to the model, which has no memory or context outside that prompt.
I think the emerging best way is to do "agentic search" over files. If you think about it, Claude Code is quite good at navigating large codebases and finding the required context for a problem.
Further, instead of polluting the context of your main agent, you can run a subagent to do search and retrieve the important bits of information and report back to your main agent. This is what Claude Code does if you use the keyword "explore". It starts a subagent with Haiku which reads ten of thousands of tokens in seconds.
From my experience the only shortcoming of this approach right now is that it's slow, and sometimes haiku misses some details in what it reads. These will get better very soon (in one or two generations, we will likely see opus 4.5 level intelligence at haiku speeds/price). For now, if not missing a detail is important for your usecase, you can give the output from the first subagent to a second one and ask the second one to find important details the first one missed. I've found this additional step to catch most things the first search missed. You can try this for yourself with Claude Code: ask it to create a plan for your spec, and then pass the plan to a second Claude Code session and ask it to find gaps and missing files from the plan.
Gemini 3 Flash is very good at the search task (it benchmarks quite close to 3 Pro in coding tasks but is much faster). I believe Amp switch to Gemini Flash for their search agent because it is better.
I open 4 chat windows with Gemini 3.0 Pro. I paste in all file contents to each window. I ask them "which files would an AI need to do $TASK effectively?"
Each of the 4 responses will disagree, despite some overlap. I take the union of the 4 responses as the canonical set of files that an implementer would need to see.
This reduces the risk of missing key files, while increasing the risk of including marginally important files. An easy trade-off.
Then I paste the subset of files into GPT 5.2 Pro, and give it $TASK.
You could replace the upstream process with N codex sessions instead of N gemini chat windows. It doesn't matter.
This process can be automated with structured json outputs, but I haven't bothered yet.
It uses much inference compute. But it's better than missing key inputs and wasting time with hallucinated output.
If you know you will be pruning or otherwise reusing the context across multiple threads, the best place for context that will be retained is at the beginning due to prompt caching - it will reduce the cost and improve the speed.
If not, inserting new context any place other than at the end will cause cache misses and therefore slow down the response and increase cost.
Models also have some bias for tokens at start and end of the context window, so potentially there is a reason to put important instructions in one of those places.
I wonder how far you can take that. Basically can you jam a bunch of garbage in the middle and still get useful results
What would you cover not-continuous?
Best methods I’ve observed -progressive loading (claude skills) & symbolic search (serena mcp)
Every time you send a request to a model you're already providing all of the context history along with it. To edit the context, just send a different context history. You can send whatever you want as history, it's entirely up to you and entirely arbitrary.
We only think in conversational turns because that's what we've expected a conversation to 'look like'. But that's just a very deeply ingrained convention.
Forget that there is such a thing as 'turns' in a LLM convo for now, imagine that it's all 'one-shot'.
So you ask A, it responds A1.
But when you and B, and expect B1 - which depends on A and A1 already being in the convo history - consider that you are actually sending that again anyhow.
Behind the scenes when you think you're sending just 'B' (next prompt) you're actually sending A + A1 + B aka including the history.
A and A1 are usually 'cached' but that's not the simplest way to do it, the caching is an optimization.
Without caching the model would just process all of A + A1 + B and B1 in return just the same.
And then A + A1 + B + B1 + C and expect C1 in return.
It just so happens it will cache the state of the convo at your previous turn, and so it's optimized but the key insight is that you can send whatever context you want at any time.
If after you send A + A1 + B + B1 + C and get C1, if you want to then send A + B + C + D and expect D1 ... (basically sending the prompts with no responses) - you can totally do that. It will have to re-process all of that aka no cached state, but it will definitely do it for you.
Heck you can send Z + A + X, or A + A1 + X + Y - or whatever you want.
So in that sense - what you are really sending (if you're using the simplest form API), is sending 'a bunch of content' and 'expecting a response'. That's it. Everything is actually 'one shot' (prefill => response) and that's it. It feels conversational but structural and operational convention.
So the very simple answer to your question is: send whatever context you want. That's it.
I've been building https://www.usesatori.sh/ to give persistent context to agents
Would be happy to onboard you personally.
We ran into this while building GTWY.ai. What worked for us wasn’t trying to keep a single model “continuously informed”, but breaking work into smaller steps with explicit context passed between them. Long-lived context drifted fast. Short-lived, well-scoped context stayed predictable.
> what according to you is the best way to provide context to a model.
Are you talking about manually or in an automated fashion?
It's called continuous learning. You can't do it with an LLM service but you can if in training mode with bigger hardware.
Cursor and AI coding doesn't do it. It uses agentic subtasks.
There is no such thing as continuous context. There is only context that you start and stop, which is the same as typing those words in the prompt. To make anything carry over to a second thread, it must be included in the second thread's context.
Rules are just context, too, and all elaborate AI control systems boil down to these contexts and tool calls.
In other words, you can rig it up anyway you like. Only the context in the actual thread (or "continuation," as it used to be called) is sent to the model, which has no memory or context outside that prompt.
Furthermore, all of the major LLM APIs reward you for re-sending the same context with only appended data in the form of lower token costs (caching).
There may be a day when we retroactively edit context, but the system in it's current state is not very supportive of that.