OpenAI Computer Use
Working baseline established for the selected browser-action and reservation workflow.
A browser task, executed actions, and a confirmed result.
The native computer-use application carried controlled Responses tool calls into executed JavaScript and real Playwright browser actions. It filtered the local booking lab, completed the requested form and confirmed the exact fictional reservation, with screenshot feedback and independent state readback.
Expectations met
Browser inputs executed
Screenshot feedback images
What was verified
All six declared behavior expectations were met in the selected workflow.
- Browser screenshots returned as observations in the controlled model feedback loop.
- Proposed JavaScript reached the application's native browser executor.
- Executed browser inputs created the exact requested fictional reservation.
- Responses and tool calls remained connected through the screenshot feedback chain.
- The native run completed and its recorded replay remained accessible.
- The selected requests, proposals and browser actions were accounted for.
Coverage of this run
Six selected scenarios cover the local browser workflow. Each verification count retains its own scope.
- Selected workflow expectations: 6 of 6 met; all six selected scenarios established
- Native SDK verification: 51 of 51 stated criteria passed
- Native application verification: 37 of 37 stated criteria passed
- Independent consequence verification: 38 of 38 stated criteria passed
- Behavior verification: 14 of 14 verifier criteria passed
- Native workflow visual review: 5 of 5 stated criteria passed
- Live-model perception and generated action quality: Further verification scope
- Production deployment, customer authorization and restart persistence: Further verification scope
- Desktop control, arbitrary external websites and real bookings: Outside this selected workflow
The recorded workflow uses a local copied booking lab and controlled provider responses, with no live model inference or real commercial reservation. The source application's model labels identify its interface configuration, not proof of live-model use. Browser replay accessibility does not establish persistence across an application restart.
Verified workflow
Eleven browser inputs performed the booking. Read-only observation stages were counted separately.
Observe
Read the browser without input. Initial local booking state captured.
Filter
Select the neighborhood, check two amenities and search. Marina District, breakfast and workspace filters applied.
Complete the form
Select the hotel and fill five fields. Fictional guest, dates and arrival request entered.
Confirm
Click the visible confirmation control. The requested reservation was created.
Verify
Read the completed browser state without input. Exact reservation independently observed.
Supporting evidence
Three selected browser captures and seven curated evidence summaries. Five native screenshot feedback images were assessed in the original workflow.
Accepted workflow result
The selected application run passed candidate, build, runtime and browser-workflow gates. Six frozen expectations were met in the local booking workflow.
Native SDK verification
All 51 stated SDK criteria passed for the native JavaScript computer-use path. This count describes SDK verification, separate from application acceptance.
Application verification
All 37 stated application criteria passed, covering the source-native runner, production console, bounded browser task and recorded result.
Independent state verification
All 38 stated consequence criteria passed. Executed browser inputs, selected hotel, fictional guest details, dates and the confirmed reservation were joined to independent state evidence.
Behavior verification
Six selected expectations were met. Fourteen verifier criteria checked the assessment and its evidence binding; they are not an additional fourteen workflow scenarios.
Action and screenshot feedback
One user submission led to five native continuations, six controlled-provider attempts and five tool proposals. Eleven executed browser inputs and five feedback images were recorded; read-only stages were counted separately.
Recorded visual review
All five native visual-review criteria passed. Three reviewed captures are selected for this public sample; console captures exposing private workspace or run identifiers are omitted.
Recommended next verification
Verify live-model computer use.
Select an authorized, bounded browser task and explicit criteria for perception, action quality and recovery before evaluating a configured live provider.
Extend the booking and recovery paths.
Declare expectations for changed availability, invalid inputs, interrupted sessions, restart persistence and customer authorization, then verify those paths separately.
Qualify additional applications.
Apply the same proposal, browser-action and state-evidence checks to each new application and setup. Keep its verified scope explicit.