Automating ChatGPT and Claude through the web interface: how anti-bot protection and anti-detect browsers work

Would you like to try Octo Browser at а discount?
Use the promo code OCTOBLOG to get 30% off any subscription. This offer is valid only for new users.

Why automate the web interface when there is an API?

OpenAI and Anthropic provide official APIs with detailed documentation. Why build a complex infrastructure and contend with security checks then? There are three reasons.

1. Cost savings at scale. With an API, you pay for every piece of text processed. When generating content in bulk, translating large databases, or running agents, bills can reach thousands of dollars. ChatGPT Plus and Claude Pro subscriptions cost $20 per month each; higher-tier plans cost $200 for ChatGPT Pro and from $100 for Claude Max. Even with message limits, using the website can be several times cheaper.

2. Features not available through the API. AI websites are their flagship products. Web search, code execution, and certain models and tools are either unavailable through the API or arrive there later or with limitations.

3. Unofficial APIs. Much of the gray market consists of unofficial APIs built on top of AI websites. Developers run hundreds of browser sessions, turn the site into a familiar REST API, and sell access at one-tenth the price of official plans. This is how many Telegram bots that provide access to AI models without a VPN operate, for example.

A typical scenario: you have a spreadsheet with thousands of rows, and each row needs a model response. Doing this manually is impractical if not impossible, and using the API is too expensive, or the model you need simply is not available. That is when website automation starts to look worthwhile.

Why not just use Selenium or Puppeteer and write a simple script? The problem is that AI companies have to watch their costs, too. They want not only to sell subscriptions but also to move business customers to paid APIs. As a result, AI websites have robust protection, and a simple script running in a headless browser will not get the job done. In fact, such scripts struggle on many websites these days.

Why standard automation tools do not work

Before discussing a solution, let’s look at the problem. What happens if you access the ChatGPT or Claude website directly using a simple script?

Modern protection measures go far beyond IP-address blocking. It checks requests at several layers and stops automation in three main cases.

Layer 1. Connection: scripts without a browser (requests, axios)

In theory, a request from an ordinary script should be rejected—with a 403 or 429 error—before data exchange even begins. The security system looks at how the client establishes a secure connection, i.e. its TLS fingerprint. Every browser has a recognizable signature: a set and order of parameters sent to the server in the first packet (Client Hello). This is the basis of JA3 and JA4 fingerprints. Networking libraries such as OpenSSL or urllib have a different signature. If a script presents itself as desktop Chrome but establishes the connection like a library, the server will detect the mismatch and may terminate the connection.

In practice, the protection is subtler. If the IP address is not in a blocklist, the server may return 200 OK but deliver a blank page or a Cloudflare Challenge page instead of the working website. To proceed, the script needs to run an obfuscated JavaScript code. A script without a browser has no JS engine, so that is where it stops.

Example of a simple script in action

Layer 2. Browser: Puppeteer or Selenium without modifications

Since JavaScript execution is required, the next logical step is a headless browser, a browser without a user interface. It can establish a connection, load the page, and execute scripts, but it gets stuck at the invisible Cloudflare Turnstile check. From the outside, this looks like a “Just a moment…” page or a checkbox that spins endlessly.

Looking at the network requests, you can see the browser sending telemetry to challenge-platform endpoints and receiving responses, but the system repeatedly fails to issue the cf_clearance cookie token that grants access to the website.

The issue is not how the script clicks—we have not even reached the clicking stage. The browser itself reveals signs of automation to the security system:

• Automation flag. A browser controlled by a script marks itself with the navigator.webdriver = true property. Selenium works through WebDriver, while Puppeteer uses the CDP protocol, but both launch the browser with this flag set. Security systems can easily detect it, even if you try to hide it with simple JavaScript injections.

• Graphics without a GPU (WebGL/Canvas). A server or Docker container has no GPU, so the browser renders graphics using the CPU. The security system requests information about the graphics setup and sees typical server-side software rendering in WebGL Renderer—ANGLE on top of SwiftShader. It also quietly draws an image in a hidden Canvas element and compares its hash with the expected value.

When the system detects the automation flag and graphics rendering without a GPU, it recognizes that it is dealing with a server-side bot.

You are not blocked outright; instead, you are sent through endless checks and never get access to the AI model.

Layer 3. Behavior: the response gets cut off

The main difficulty comes next. The model’s response arrives in chunks over a persistent connection to the server—Server-Sent Events (SSE) or WebSocket. The system continues to assess the session throughout this process.

If it notices that the cursor jumps instantly to the required buttons instead of moving smoothly, with acceleration and slight jitter as a human cursor would, the response may be cut off during generation. In the case of WebSocket, the connection closes with code 1006, Abnormal Closure. The cursor movement is just one example: security systems analyze many more signals.

In the worst case, the account receives a shadowban. You remain logged in, and the script sends POST requests containing prompts, but the response is an empty JSON object or a “temporary generation error” message.

The dead end of standard solutions

Putting the three layers together, the picture is clear: HTTP clients are useless without a JS engine, while standard automation tools give themselves away through the navigator.webdriver flag, software-rendered graphics, and synthetic input events.

You can take the path of least resistance: patch Selenium or Puppeteer with a couple of JavaScript injections and add a CAPTCHA-solving service. Just make sure to budget for it, because you will encounter plenty of CAPTCHAs, and this still will not make the setup stable.

There is another approach: build a resilient system for working with LLM web interfaces. It needs to provide three things:

1. A full browser environment. A real browser engine that performs obfuscated checks just like regular Chrome.

2. Undetectable control. The control protocol must leave no traces in the window object—no automation flags or WebDriver variables.

3. Consistency with the hardware. Canvas and WebGL hashes, the set of fonts, and other parameters must match the stated GPU and operating system rather than reveal a virtual server.

How can you meet these requirements without rewriting the Chromium engine yourself?

An anti-detect browser as the foundation of an automation setup

The solution comes from the world of affiliate marketing and multi-accounting: anti-detect browsers, in this case Octo Browser. Their main difference from patched Puppeteer is the level at which fingerprints are spoofed. This happens not through JavaScript scripts, but in the Chromium engine’s source code.

It is important to understand that Puppeteer also uses the CDP protocol, so the difference is not the control method. The difference lies in the browser that the script connects to. What fingerprints it uses and whether it contains automation markers are the things that matter.

What does this provide in practice?

• Plausible GPU parameters. Instead of software rendering through SwiftShader, the browser exposes parameters corresponding to real hardware—Nvidia, AMD, or Apple Silicon. Canvas and WebGL hashes are consistent with the stated GPU.

• Profile isolation. Each ChatGPT or Claude account runs in a separate encrypted profile. Each profile has its own fonts, WebRTC settings, and time zone.

• Control through a local API and CDP. There is no need to use code to configure the environment. Profiles are launched through the browser’s local REST API, and the script connects to them via the CDP port.

In this setup, a Python or Node.js script handles only the logic. It takes the source data, builds a prompt, sends it to the AI web interface running in the anti-detect browser, and retrieves the result. The prepared environment is responsible for meeting anti-fraud systems’ requirements.

Solution architecture: saved profiles and a CDP connection

Ultimately, working with an AI web interface becomes a stable pipeline in which the anti-detect browser serves two roles.

• Initial setup environment. You open the interface once in a regular profile window and use it like an ordinary user: log in manually and complete a CAPTCHA if one appears. The browser saves cookies, cache, and authentication tokens in an isolated profile. To the server, this looks like an ordinary person who simply closed a tab.

• An infrastructure node. When you need to run automation, the script launches the already prepared profile through the local API and connects to it via CDP.

The profile is already authenticated, so navigating to chatgpt.com or claude.ai opens the chat interface immediately. No repeated login or CAPTCHA is required: to Cloudflare, this is a continuation of a previously verified session on a trusted device. You can have several such profiles.

The roles in this system are divided as follows: the anti-detect browser spoofs hardware parameters at the kernel level, connects proxies, and stores cookies; the script sends prompts and retrieves responses; and CDP connects the two. Essentially, the browser is used for its intended purpose, except that code controls it instead of a person.

Conclusion

LLM web interfaces check clients at three levels: how they establish a connection, the environment in which they run, and their behavior during a session. That is why isolated fixes such as stealth plugins, JavaScript patches, or changing proxies offer temporary results at best. They address one issue while leaving the others exposed.

Resilient automation starts with the environment, not the script. A browser with consistent fingerprints at the kernel level, preconfigured profiles, and CDP control take the burden of spoofing away from the code. The script is left to do its actual job: send prompts and process responses.

At the same time, the risks of such an architecture should be assessed realistically. Protection systems continue to evolve, and automated access to web interfaces conflicts with OpenAI’s and Anthropic’s terms. Any such setup requires maintenance, and it is important to understand how the protection you are dealing with works.