The contract is a lie. The code is the truth. OpenAI's shift from screenshots to event logs in Computer History is not a privacy upgrade; it is a structural optimization for a surveillance layer that now runs with less friction. The proof is silent; the code screams the truth.
Hook: The Token Arithmetic
OpenAI's new Computer History feature for ChatGPT and Codex drops screenshots entirely. Replaces them with a stream of clicks, keystrokes, app switches, and shortcut triggers. The reason is simple: a single screenshot, when encoded by a vision transformer, generates hundreds of tokens. A structured event log? Maybe a dozen. The cost reduction is not a feature; it is a survival mechanism. If every user's session produced pixel-level data, the inference budget would bleed into the stratosphere. This is not about privacy. It is about margin.
Context: From Chronicle to Computer History
The product was previously called Chronicle. It captured screenshots. Users hated it. Privacy advocates smelled blood. Now it is renamed Computer History, and the underlying data layer has been gutted. The new system records user actions—clicks, inputs, keyboard shortcuts, application switches—and organizes them into a local timeline. The data stays on-device. But the queries that access this data? They route through the cloud. That is the critical fracture. The system is designed to answer questions like "What file was I editing an hour ago?" and to suggest automations when it detects repetitive patterns. The first iteration is macOS-only, reserved for Pro, Business, and Enterprise subscribers. Default is off. Exclusion lists for specific apps and sites are offered. But these are design choices, not guarantees.
Core: The Architecture of a Memory Broker
Let me be precise. The switch from visual semantics to structured event logs is a product-level innovation, not a cryptographic breakthrough. But it is a meaningful one. The event log is a sequence of tuples: [timestamp, app, action, context]. The context field may contain file names, window titles, or even partial text input. This is not a vision model. This is a structured database with a natural language interface. The real question is how the local memory interacts with the cloud model. When a user asks "What was I doing yesterday?", the local storage must be queried. That query could be executed entirely on-device, with only the relevant summary sent to the API. Or it could dump the raw event log into the context window. The article does not clarify this. Based on my experience auditing zero-knowledge proving systems, I suspect the former. The token savings would be too significant to ignore. But the latter is cheaper to implement. The difference determines whether the user's activity history is truly private or just another vector for model training.
I do not trust the contract; I audit the logic. The automation suggestion feature is the most interesting signal. The system detects repetitive patterns—like opening the same three apps every morning—and suggests converting them into a Skill or Automation. This requires a pattern recognition layer on the event stream. It is not simple key-value storage. It is behavior sequence analysis. The system needs to identify clusters of actions and propose a deterministic script. This is a thin line between helpful and invasive. If the suggestion is wrong, it wastes user trust. If it is right, it becomes sticky. The product is designed to pivot from "remembering what you did" to "learning how you work." That is a subtle but powerful shift. It turns the product from a passive memory log into an active workflow optimizer.
Contrarian: The Blind Spot Is Not the Screenshot
The conventional wisdom is that removing screenshots solves the privacy problem. It does not. The event log is a behavioral fingerprint. It records every app switch, every keystroke, every click. This is a higher-fidelity surveillance signal than a screenshot, because it is structured and machine-readable. A screenshot requires OCR and vision analysis to extract meaning. An event log is already parsed. The privacy risk is not the modality; it is the granularity. The exclusion list for apps and sites is a token gesture. It cannot cover password fields in a browser, or incognito mode, unless the system hooks into the OS-level security boundary. And it does not. The default-off setting is a good start, but it is a user responsibility, not a system guarantee. For enterprise customers, this is a compliance headache. The event log, even if local, is a data source that can be subpoenaed. The fact that it is stored locally does not make it private. It makes it inaccessible to OpenAI's servers until queried. But the query itself is a data transfer. The system is not end-to-end encrypted. It is not a zero-knowledge proof. It is a local cache with a cloud interface.
Takeaway: The Infrastructure of Agentic Memory
Computer History is not a product. It is a data pipeline. It collects the raw material for a future Agent that can replicate user workflows. The automation suggestions are the first step. The next step is one-click execution. When that happens, the system will need an execution environment, and that environment must be sandboxed. The current architecture does not specify the sandboxing. The risk is that a malicious automation suggestion could trigger a destructive action—like deleting a file or sending a email—without the user's explicit approval. The proof is silent; the code screams the truth. The future of AI agents is not in the model. It is in the memory layer. And OpenAI is building a memory layer that is centralized, opaque, and platform-locked. The question is not whether it works. The question is whether we can trust the operator. I do not trust the contract; I audit the logic. The logic here is incomplete.
