You ask a model to compare several files. It reads the records, cleans the data, and calculates a summary. Then you add another file and change one rule.
The next step needs the working data and the code that shaped it. This is why VARIANT-1 gives each chat a persistent Python environment: while it stays alive, the model can continue with the actual values and helpers from earlier calls.
Build on the previous step
A live working environment gives the follow-up somewhere concrete to begin. The model can inspect a table, adjust a function, and calculate a new result without rebuilding every intermediate step.
It still needs to check the new file. Columns may differ, records may be incomplete, and an earlier assumption may no longer hold. Retained data helps when it can be examined and revised.
Know what is being kept
Chat history records the conversation. Live Python holds variables and objects in a running process. Output files are saved to a destination. Approved memory keeps facts you explicitly save or approve.
These have different jobs. A conversation can describe a table that is no longer loaded; a saved report can still exist after the runtime that created it has ended. Keeping those distinctions clear makes it easier to resume work.
Keep the work ready for the next question.
A restart changes what is available
Python state stays available across calls and follow-up messages within a live runtime. A reset, restart, eviction, or process failure can end that runtime.
Optional checkpoints can preserve supported values. Checkpointing and restoration are off by default, and they cannot restore every open file, browser connection, thread, or other live object.
After a restart, the next step is to check the current data, saved files, and restored values before deciding what needs rebuilding.
Keep the method within reach
The work includes more than the final answer. A helper can be read. An intermediate table can be checked. A report can be opened in the application where it will be used.
Those checks are useful during revision and after an interruption. If a task changed an external resource before stopping, inspect that resource before repeating the action.
Does it help the next task?
The aim is to spend less effort reconstructing work and more effort improving it. That needs testing across real follow-ups, changed inputs, and restarts, including the time spent checking and recovering state.
Persistent Python is a design choice we are developing and evaluating. Its value has to show up in the work people can complete with it.