Toen OpenAI Codex voor (bijna) alles uitbracht, stond de techwereld op. AI schrijft al jaren code en concepteert e-mails, maar de bewering dat Codex nu macOS kan besturen — “door te zien, te klikken en te typen met een eigen cursor” — vormt een fundamenteel andere capaciteit.
De kloof overbruggen tussen een cloudbased taalmodel en een lokaal besturingssysteem is berucht moeilijk. Decennialang steunde automatisering op broze Application Programming Interfaces (APIs) of DOM-schrapende scripts die stuklopen zodra één interfacce-element verandert.
De kern van de technische inzicht: Codex heeft code-level integratie losgelaten ten gunste van uitvoering op pixelniveau. Door multimodale visie te combineren met low-level injectie van kernel-events, heeft OpenAI de Graphical User Interface (GUI) omgevormd tot een universele API.
Hier is de technische architectuur die dit mogelijk maakt.
De architectuur van een Mac-native agent
Om een applicatie te testen of een frontend-ontwerp te itereren zonder menselijke tussenkomst, heeft een AI een continue Waarnemen-Redeneren-Handelen-lus nodig. Hieronder staat hoe Codex elke fase waarschijnlijk op macOS implementeert.
1. Waarneming: semantische visie en de grounding-engine
Traditionele automatiseringstools zoals AppleScript lezen de toegankelijkheidsboom (accessibility tree) van de interface. Deze aanpak is snel, maar faalt bij custom Electron-apps, webcanvassen of games waar UI-elementen de juiste toegankelijkheidslabels missen.
OpenAI stelt dat Codex applicaties gebruikt door ze te “zien”, wat betekent dat het leunt op Computer Vision. De hostapplicatie op de Mac maakt hoogfrequente frame-captures van het bureaublad. Een multimodaal model ontleedt deze frames vervolgens met semantische segmentatie — het zoekt niet naar HTML-tags, maar herkent visueel de vorm en context van interface-elementen zoals knoppen, zoekbalken en menu’s.
De belangrijkste technische uitdaging hier is Grounding. Zodra de AI een doelwit identificeert, voert het een berekening uit om het semantische object te mappen naar precieze pixelcoördinaten op het scherm. Het vertaalt “klik op de sluiten-knop” naar exacte (x, y)-posities, gecorrigeerd voor de specifieke schermresolutie en schaalfactor.
| Fase | Wat er gebeurt | Technologie |
|---|---|---|
| Frame Capture | Hoogfrequente screenshots van het bureaublad | Hostapplicatie |
| Semantische Parsing | UI-elementen herkennen op visuele verschijning, niet op code | Multimodaal visiemodel |
| Grounding | Semantische doelen mappen naar pixelcoördinaten | Coördinaatregressiemodel |
| Action Dispatch | Gesynthetiseerde input-events injecteren in het OS | Systeemframework-hooks |
2. Actie: OS-level events injecteren
Weten waar te klikken is alleen nuttig als de software de actie ook daadwerkelijk kan triggeren. Codex omzeilt fysieke hardware volledig.
Om op native niveau met macOS te interageren, maakt Codex vrijwel zeker gebruik van de diepste systeemframeworks van Apple: Quartz Event Services en de Accessibility API.
Wanneer Codex beslist te klikken, synthetiseert het een virtueel CGEvent — een mouseDown gevolgd door een mouseUp — en injecteert het direct in de macOS-systeemeventqueue. Vanuit het perspectief van het besturingssysteem is dit synthetische event niet te onderscheiden van een fysieke trackpad-druk. Daarom kan Codex elke applicatie besturen: als een mens het kan klikken, kan Codex het klikken.
3. Isolatie: de “ghost cursor”-mechanismen
Misschien wel de meest technisch ambitieuze bewering is dat Codex “op de achtergrond draait zonder je computer over te nemen.” Iedereen die ooit een macro-recorder heeft gebruikt, weet dat traditionele automatisering de muiscursor volledig kaapt.
Om gelijktijdige uitvoering te bereiken, moet het systeem de inputs van de AI isoleren van de fysieke inputs van de gebruiker. Er zijn twee waarschijnlijke implementatiebenaderingen:
| Benadering | Hoe het werkt | Afweging |
|---|---|---|
| Gerichte Window-Routing | macOS staat toe events naar specifieke Process Identifiers (PIDs) te sturen. Codex routeert gesynthetiseerde klikken direct naar de eventloop van de doelapplicatie, voorbij de globale hardware-cursor. | Lagere overhead; vereist precieze window-targeting. |
| Virtuele Framebuffers | Het systeem draait een headless virtuele bureaubladlaag op. Codex “ziet” en opereert binnen deze onzichtbare werkruimte, terwijl de gebruiker ongestoord verder werkt in de primaire werkruimte. | Hoger geheugengebruik; sterkere isolatiegaranties. |
De virtuele-framebuffer-benadering sluit aan bij de mechanismen die werden waargenomen toen Anthropic hun eigen Computer Use-capaciteit uitbracht, wat suggereert dat dit een opkomende industriestandaardpatroon voor desktop-AI-agents is.
De vooruitblik: een post-API-wereld
De stroomafwaartse impact reikt veel verder dan de technische implementatie. Door de visie-naar-actie-pipeline op OS-niveau op te lossen, heeft OpenAI traditionele APIs optioneel gemaakt. We betreden het tijdperk van de Large Action Model (LAM).
Bekijk de praktische implicaties:
- Integratie van legacy-software: Enterprise-tools uit 2008 zonder API? Codex heeft er geen nodig. Het opent de applicatie, navigeert de interface, kopieert data en plakt het in een modern dashboard.
- Platformbeperkingen: Platforms die ontwikkelaarstoegang beperken via agressieve API-rate-limiting? Codex opent de webbrowser en bestuurt de interface direct, net als een menselijke gebruiker zou doen.
- Cross-applicatie-workflows: Taken die eerder custom middleware vereisten tussen ontkoppelde applicaties, kunnen nu worden georchestreerd via één enkele instructie in natuurlijke taal.
De software-industrie heeft decennialang bruggen gebouwd tussen applicaties. Nu Codex de macOS-GUI beheerst, hoeven applicaties niet langer met elkaar te praten. De AI gebruikt ze namens ons.
FAQ
Hoe “ziet” Codex het scherm op macOS?
Codex gebruikt een hostapplicatie die hoogfrequente screenshots van het bureaublad maakt. Een multimodaal visiemodel voert vervolgens semantische segmentatie uit op deze frames, waarbij UI-elementen zoals knoppen, menu’s en tekstvelden worden herkend op basis van hun visuele verschijning in plaats van onderliggende code of toegankelijkheidslabels.
Welke macOS-frameworks gebruikt Codex om klikken en toetsaanslagen te simuleren?
Codex maakt naar alle waarschijnlijkheid gebruik van de Quartz Event Services en de Accessibility API van Apple. Het synthetiseert virtuele CGEvents (zoals mouseDown en mouseUp) en injecteert deze in de macOS-systeemeventqueue, waardoor deze inputs niet te onderscheiden zijn van fysieke hardware-events.
Hoe kan Codex op de achtergrond werken zonder de cursor te kapen?
Het systeem gebruikt waarschijnlijk óf gerichte window-routing — events direct naar specifieke Process Identifiers (PIDs) sturen — óf virtuele framebuffers, die een onzichtbare bureaubladwerkruimte creëren waarin de AI onafhankelijk opereert terwijl de fysieke cursor van de gebruiker onaangetast blijft.
Wat is een Large Action Model (LAM) en hoe verschilt het van een LLM?
Een Large Action Model breidt de capaciteiten van een Large Language Model uit van tekstgeneratie naar uitvoering van taken in de echte wereld. Waar een LLM antwoorden genereert, neemt een LAM zijn omgeving waar via visie, redeneert over welke acties te nemen, en voert die acties uit via systeem-niveau input-injectie. Codex vertegenwoordigt een praktische implementatie van het LAM-concept.
