The Tool Desk
Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →Outbyte PC Repair FREEClear out junk files and repair common Windows errorsFree Scan →A long-running agent does not remember earlier work just because its process starts again. To continue, the application or provider must supply persisted conversation state to a new model call. That state may be replayed from application storage, loaded by an SDK session, continued through a provider-managed conversation, or compressed through compaction. These mechanisms solve related but different problems: restoring history, resuming an interrupted run, and keeping the active context from growing without bound.
What context means when an agent starts again
A model call works from the input supplied for that call and the context window available to it. A cold start is a fresh run: the process may have no in-memory history, so something outside the model must assemble or retrieve the information needed to continue. Restarting a program alone does not restore that information.
As an Amazon Associate I earn from qualifying purchases.
It helps to separate three things:
- Persisted state: conversation items or other data stored by the application or provider between calls.
- Active input: the messages, instructions, tool results, and other items actually supplied to the current model run.
- Carried-forward summary or selection: a compacted or filtered representation used to keep later input manageable.
Persisted state is not automatically active context. An application must retrieve and include it, an SDK session must load it, or a provider-managed continuation mechanism must be used as documented. Likewise, a summary can preserve useful working state without preserving every original detail.
Recommended Free Tools
Four ways to carry a conversation forward
OpenAI’s running-agent guide describes four continuation approaches. They differ mainly in who owns history and what the caller must provide on the next run.
#1 Best Overall
| Approach | Who manages state | What continuation looks like | Useful when |
|---|---|---|---|
Application-managed history (result.history) |
Your application | Store prior items, then select or replay relevant history in the next input. | You need direct control over storage, filtering, or portability. |
| Agents SDK session | The session integration and its configured storage | The session retrieves prior items before a run and saves newly produced items afterward. | You want session-managed history and a documented path for resuming interrupted runs. |
Conversations API (conversationId) |
OpenAI’s server-managed conversation state | Supply the conversation identifier according to the API’s continuation pattern. | Server-managed state shared across workers or services is a better fit. |
Responses API (previousResponseId) |
OpenAI’s server-managed response chain | Use the prior response identifier to continue the chain, following the documented input pattern. | You want a lighter server-managed continuation rather than managing a full replay yourself. |
These are not interchangeable storage labels. Application replay means your code decides what enters the next input. An SDK session performs history retrieval and persistence through its session integration. A conversation ID or previous response ID uses the provider’s server-side continuation semantics. The OpenAI guide generally recommends one strategy per conversation: replaying client-managed history while also continuing server-managed state can duplicate context.
How an Agents SDK session restores and saves state
In the documented OpenAI Agents SDK for Python session pattern, the session integration handles a before-and-after cycle around a run:
- Before the run: retrieve the session’s previous items and prepend them to the new input.
- Run the agent: process the new request together with that retrieved history.
- After the run: persist all new items, including the user’s input, assistant responses, and tool calls.
This makes the session storage, rather than the live process, the continuity point between ordinary turns. For an approval interruption, the documented SDK pattern can resume with the same session instance, or with another instance using the same session ID and underlying storage backend. A new process therefore needs access to the corresponding session storage; an ID without the underlying state is not itself the conversation history.
What happens during a cold start or interrupted run
For a new conversational turn after a process restart, first decide which continuation mechanism owns the conversation. With application-managed history, load the saved items, filter or select the relevant material, and assemble the next input. With an SDK session, initialize the session against the same storage so its integration can retrieve prior items. With a server-managed method, send the identifier and new input in the form required by that API.
Rank #3
An interrupted run is a different boundary from a normal next turn. A conversation continuation starts another turn using earlier state; resuming a paused run continues work that did not complete. OpenAI’s SDK session documentation specifically describes resuming an approval-interrupted run through the same session storage. Do not assume every conversation ID or response ID is a general-purpose mechanism for resuming arbitrary in-progress work; follow the particular orchestration API’s interruption semantics.
Why context grows and what compaction changes
Replaying every prior message is straightforward, but the active input can grow as turns, tool calls, and outputs accumulate. Filtering removes history the application decides not to send. Compaction instead carries forward a reduced representation intended to retain state needed for later turns.
OpenAI’s Compaction API documentation describes compaction as a way to reduce context size while preserving state needed for subsequent turns. That describes the goal, not a guarantee that every original detail survives or a benchmark of recall quality. Treat compacted context as a bounded working state, not a verbatim archive.
Do these 3 things before closing this tab:
1Clear out junk files and repair common Windows errors2Scan for outdated or missing drivers - takes under a minute3Repair Windows errors before they cause bigger problemsOpenAI server-side compaction
OpenAI documents threshold-based server-side compaction for Responses requests: when a configured token threshold is reached, compaction occurs during the request and the response stream includes an encrypted compaction item. The item is opaque and is not intended to be human-interpretable.
Best Value
- In a stateless input-array chain, continue by appending the response output items, including the compaction item, to the next input.
- When continuing with
previous_response_id, pass the new user message and keep the response chain.
OpenAI also documents a standalone compact endpoint. It accepts a full context window and returns a compacted window, which can include retained earlier items as well as the compaction item. For the next request, pass the returned window through as-is rather than pruning items from it.
Anthropic threshold and on-demand compaction
Anthropic’s Claude Platform documentation describes automatic threshold compaction and on-demand compaction. In threshold mode, older context is summarized once the configured input threshold is reached, a compaction block is created, and the interaction continues with compacted context. This is Anthropic’s documented behavior; its configuration and semantics should not be assumed to match OpenAI’s.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Choosing a continuation design
- Choose application-managed history when your system needs to control the history store and decide what to replay or filter. This gives the application control over its stored state, but also makes input construction its responsibility.
- Choose an SDK session when the SDK’s retrieval-and-save lifecycle fits your application and you need its documented session-based interrupted-run resume behavior.
- Choose a conversation ID when provider-managed conversation state needs to be used across workers or services.
- Choose a previous response ID when the provider’s response-chain continuation is sufficient and you do not need to reconstruct a full client-managed history for each request.
- Add compaction or filtering when history growth makes sending the full interaction impractical. Decide what information must remain available for later actions, and retain an appropriate durable record separately if exact past details matter.
Application-managed storage offers more control over how state is stored and supplied; provider-managed continuation is tied to the corresponding API. The official documentation describes these ownership and usage patterns, but does not establish a neutral portability ranking or a comparative quality benchmark.
PC Slower Than It Used to Be?
A free scan shows the junk files, broken settings and background clutter dragging Windows down - then fixes them in one click.Free scan · Windows 10 & 11Outdated Drivers Are Slowing You Down
One free scan finds every outdated or missing driver and matches the right update for your exact hardware.Free scan · exact hardware matchQuick Recap
Practical safeguards for reliable resumes
- Persist state at the boundary your recovery plan requires; saving only at normal completion will not help if a run can be interrupted before then.
- Keep the storage identity stable across restarts. For an SDK session resume, the session ID must resolve to the same underlying storage backend.
- Choose a single history owner for each conversation unless there is a deliberate design for reconciling duplicated state.
- Keep durable records distinct from compacted working context when later decisions depend on exact tool outputs, user instructions, or other details.
- For OpenAI’s standalone compact endpoint, use the returned compacted window as supplied. For other continuation and compaction modes, follow that provider’s documented input pattern rather than assuming identical behavior.
Product prices and availability are accurate as of the date/time indicated and are subject to change. Any price and availability information displayed on Amazon at the time of purchase will apply.




