To build a GPT-5.6 browser agent that works beyond a demo, separate model reasoning from browser execution. GPT-5.6 should define the goal, evaluate evidence, and decide whether to continue. BrowserAct should own the live browser, named session, page interaction, and structured observation. This tutorial builds a narrow monitoring agent: open a pricing page, select the required page state, extract evidence, and return a verified record. The same pattern extends to research, QA, authenticated das

Prerequisites

You need:

• Python 3.10 or newer and uv for the BrowserAct CLI.
• Chrome or Chromium for local browser types.
• Node.js 20+ for the orchestration example.
• An OpenAI API key with access to GPT-5.6.
• A BrowserAct API key only if you use hosted stealth browsers and related managed features.

Install the two clients:

uv tool install browser-act
npm install openai
browser-act --version

The official OpenAI model catalog lists gpt-5.6-sol, gpt-5.6-terra, and gpt-5.6-luna. The gpt-5.6 alias routes to Sol. All three support the Responses API and function calling.

Pro Tip: Start with gpt-5.6-sol while the workflow is new. Once evidence and failure states are stable, move routine decisions to Terra and bounded normalization to Luna.

Step 1: Define a task contract

Do not begin with “research this company.” Define the outcome the program can verify.

{
  "task": "capture_pricing",
  "target_url": "https://example.com/pricing",
  "required_state": {
    "market": "US",
    "billing_period": "annual"
  },
  "required_fields": [
    "plan",
    "price",
    "currency",
    "billing_period",
    "source_url",
    "observed_at",
    "evidence_text"
  ],
  "allowed_actions": ["navigate", "click", "read"],
  "approval_required": ["submit", "purchase", "send_message"]
}

This contract prevents a common failure: the model returns a plausible price without proving which market or billing interval was selected.

Step 2: Open a named BrowserAct session

List the browsers available to the agent and choose the approved browser ID:

browser-act browser list

Open the target in a session whose name describes its purpose:

browser-act --session pricing-check browser open <browser-id> https://example.com/pricing
browser-act --session pricing-check state

If the annual billing control is element 5:

browser-act --session pricing-check click 5
browser-act --session pricing-check get markdown

Close the session after the workflow finishes:

browser-act --session pricing-check session close pricing-check

Named sessions make ownership and lifecycle explicit. Separate jobs can run without taking over each other's browser window.

Step 3: Ask GPT-5.6 to plan the next browser step

The minimal OpenAI Responses API call is:

import OpenAI from "openai";
 
const openai = new OpenAI();
 
const response = await openai.responses.create({
  model: "gpt-5.6-sol",
  input: `You are planning one step of a browser task.
Return JSON only with: action, element_index, reason, expected_state.
Allowed actions: click, read, finish, request_human.
 
Task contract:
${JSON.stringify(taskContract)}
 
Current browser state:
${browserState}`,
});
 
const decision = JSON.parse(response.output_text);

For production, use Structured Outputs or a function tool instead of trusting arbitrary JSON text. The important boundary remains the same: GPT-5.6 proposes an allowed action; the orchestrator validates it before BrowserAct executes it.

Pro Tip: Never let the model construct an unrestricted shell command. Map a small action enum to code you own and reject values outside the task contract.

Step 4: Connect the decision to BrowserAct

The following Node.js helper executes BrowserAct without a shell and returns stdout:

import { spawn } from "node:child_process";
 
function browserAct(args) {
  return new Promise((resolve, reject) => {
    const child = spawn("browser-act", args, { shell: false });
    let stdout = "";
    let stderr = "";
 
    child.stdout.on("data", chunk => (stdout += chunk));
    child.stderr.on("data", chunk => (stderr += chunk));
    child.on("close", code => {
      if (code === 0) resolve(stdout);
      else reject(new Error(`browser-act exited ${code}: ${stderr}`));
    });
  });
}
 
async function executeDecision(session, decision) {
  if (decision.action === "click") {
    if (!Number.isInteger(decision.element_index)) {
      throw new Error("Missing element index");
    }
    return browserAct([
      "--session", session,
      "click", String(decision.element_index),
    ]);
  }
 
  if (decision.action === "read") {
    return browserAct(["--session", session, "get", "markdown"]);
  }
 
  if (["finish", "request_human"].includes(decision.action)) {
    return decision;
  }
 
  throw new Error(`Rejected action: ${decision.action}`);
}

This design prevents the model from changing the executable or injecting extra flags. The application controls the command shape.

Step 5: Return structured evidence

After the correct page state is visible, ask GPT-5.6 to map the retrieved markdown into the required record:

{
  "plan": "Pro",
  "price": 49,
  "currency": "USD",
  "billing_period": "annual",
  "source_url": "https://example.com/pricing",
  "observed_at": "2026-07-13T15:30:00+08:00",
  "evidence_text": "$49 per month, billed annually",
  "status": "verified"
}

Validate the schema in normal application code. Check that the URL matches the approved domain, the price is numeric, the billing period matches the required state, and the evidence text is present.

Pro Tip: Add a schema_version to every browser result. When a website or required field changes, downstream systems can reject old records explicitly instead of silently mixing incompatible evidence.

The GPT-5.6 browser automation architecture explains why this evidence layer should remain model-neutral.

Step 6: Add recovery without infinite retries

Classify failures before retrying:

Step 7: Put approval before side effects

Reading a public price and submitting an order are different authority levels. The task contract should allow read-only actions automatically and stop before sensitive actions.

const sensitive = new Set(["submit", "purchase", "send_message"]);
 
if (sensitive.has(decision.action)) {
  return {
    status: "approval_required",
    proposed_action: decision,
    session: "pricing-check",
  };
}

Preserve the live session so the reviewer can inspect the exact state. Do not close it until the person approves, rejects, or cancels the workflow.

Step 8: Measure the completed workflow

Record:

• Verified completion rate.
• Exact field accuracy.
• Browser retries and recovery rate.
• Median completion time.
• Human approval and rescue rates separately.
• Model, browser, and tool cost per completed task.
• Evidence completeness.

The GPT-5.6 pricing guide shows why retries and human rescue belong in the cost calculation.

A production-ready pattern

The complete loop is intentionally boring:

Task contract
  → GPT-5.6 proposes one bounded action
  → application validates the action
  → BrowserAct executes it in a named session
  → application validates page evidence
  → retry, finish, or request approval

That separation makes the agent easier to test, route, and upgrade. Terra or Luna can replace Sol in stable stages without changing the browser workflow. BrowserAct sessions and reusable agent skills remain the execution contract.

Install BrowserAct and build the workflow →

Sources

• OpenAI model catalog
• OpenAI GPT-5.6 Sol model
• OpenAI API quickstart
• BrowserAct documentation
• BrowserAct Skills

Frequently asked questions

Which model ID should a GPT-5.6 browser agent use?

Use gpt-5.6-sol or the gpt-5.6 alias for the strongest default. Use gpt-5.6-terra for balanced workloads and gpt-5.6-luna for bounded high-volume processing.

Does GPT-5.6 include browser automation?

GPT-5.6 supports computer use and tool calling, but an application still needs a browser environment, session lifecycle, evidence validation, recovery, and permission controls.

How do you install BrowserAct?

Install the CLI with uv tool install browser-act, verify it with browser-act --version, then list or configure an approved browser.

Why use a named browser session?

A named session provides clear ownership, isolated navigation, shared authorized browser state, and an explicit lifecycle for parallel agent work.

Should the model generate BrowserAct shell commands?

No. Let the model choose from a bounded action schema, then map that action to fixed command arguments in application code.

When should the browser agent request human approval?

Require approval before messages, submissions, purchases, permission changes, or other actions with meaningful external side effects.