The April 2026 OpenAI API changelog, one phrase at a time, from someone shipping a desktop agent that does not use screenshots

Three confirmed entries on the developer changelog. April 15: an Agents SDK update that added running agents in controlled sandboxes, inspecting and customizing the open-source harness, and controlling when memories are created and where they are stored. April 21: GPT Image 2, a new image generation and editing model with flexible image sizes, high-fidelity image inputs, token-based image pricing, and Batch API support at a 50 percent discount. April 24: GPT-5.5 to the Chat Completions and Responses API, plus GPT-5.5 pro for more computationally intensive tasks. GPT-5.5 advertises a 1M token context window, image input, structured outputs, function calling, prompt caching, Batch, tool search, built-in computer use, hosted shell, apply patch, Skills, MCP, and web search. Reasoning effort defaults to medium. Extended prompt caching is the only caching method supported.

It means the model is trained to look at a screenshot of a computer screen, in pixels, and emit grounded actions like click(x, y), type(text), or scroll(delta). The harness sends a screenshot back to the API in the prompt, the model returns coordinates, the harness performs the click and screenshots again. The 'built-in' part is that the action vocabulary and the screenshot-conditioning are baked into the model. The harness is open source and inspectable per the April 15 Agents SDK note. The grounding signal is still raw pixels: pixels in, pixel-coordinate actions out.

An accessibility-API agent does not look at pixels. It queries the operating system for the structured tree the OS already maintains for screen readers, automation, and assistive tech. On macOS the call is AXUIElementCreateApplication for a process, then AXUIElementCopyAttributeValue for kAXFocusedWindowAttribute, kAXChildrenAttribute, kAXTitleAttribute, kAXValueAttribute, and kAXRoleAttribute. The returned values are strings, not pixels. The agent reasons about a textual tree of buttons, text fields, menu items, and rows. Actions target elements by reference, not by coordinate. There is no JPEG in the prompt for that branch. The two architectures both call themselves 'computer use' and both can drive a Mac, but they ground against entirely different signals.

Look at acp-bridge/src/index.ts in the open source Fazm repo. Line 63 names a binary path: Contents/MacOS/mcp-server-macos-use. Lines 1058 to 1066 register that binary as an MCP server called macos-use, alongside playwright for browser automation and a Catalyst-app whatsapp-mcp. Then look at Desktop/Sources/AppState.swift at line 439, which calls AXUIElementCreateApplication(frontApp.processIdentifier) and follows up with AXUIElementCopyAttributeValue for kAXFocusedWindowAttribute. That is the entire grounding path: process id to AXUIElement, attribute by attribute, no screen capture involved unless the user explicitly asks 'what is on my screen' and a separate capture_screenshot tool is invoked.

Not really, because they ground against different signals. A pixel-grounded agent like the GPT-5.5 reference harness can in principle drive any application, including one that ships zero accessibility metadata. An accessibility-tree agent cannot drive an OpenGL canvas, a Qt app with no AX hooks, or a custom-rendered game. On the other hand the accessibility-tree path is faster, deterministic, robust to font rendering and DPI changes, and does not need a screenshot in the prompt for every step. For long Mac workflows that are mostly Mail, Calendar, Notes, Messages, Slack, browser, and Google Workspace, the AX tree path is meaningfully cheaper per step. For drawing in Photoshop or playing a 3D game, pixel grounding wins. They are complementary tools, not competitors. The interesting line on the changelog is not 'computer use shipped, everyone else dies', it is 'computer use is now a primitive at the model level, so you can stop bolting on a screenshot tool and start picking which grounding signal your task actually needs'.

Yes, indirectly. The sandbox is where a server-side agent gets to do its work. It is the place a hosted shell, a hosted code interpreter, and the computer-use harness can run without touching the user's actual machine. That is the architecturally interesting part for desktop agent builders: server-side computer use runs against a server-side virtual desktop, which is great for repeatable end-to-end tasks (signing into a SaaS, scraping a page) but is by definition not your laptop. If the task is 'open the Notes file I started this morning and turn it into an email draft in Mail.app', a sandbox agent has nothing to look at. A local accessibility-tree agent has the actual Notes window in its tree.

Indirectly. GPT Image 2 is a generation and editing model, not a perception model. It does not help an agent click a button. It would matter if you were building a pipeline where the agent generates illustrations or edits screenshots inside a workflow. The 50 percent Batch API discount and token-based pricing make 'agent edits an image, posts it' workflows cheaper to run at scale, which fits the small-business automation use case. It is unrelated to grounding-against-screen and so is mostly orthogonal to the computer-use thread on this same changelog.

Several of those announcements appear in roundups but are not the dated entries on the developers.openai.com/changelog feed for April 2026. The developer-facing API changelog for April 2026 confirms three dated entries: Agents SDK update on April 15, GPT Image 2 on April 21, and GPT-5.5 plus GPT-5.5 pro on April 24. Other April announcements live on adjacent surfaces (release notes, ChatGPT release notes, marketing posts) and are best read on those specific feeds rather than mixed into the API changelog. This page deliberately stays inside the developer API changelog scope.