jev-ultrafast passed 21,000 stars on GitHub shortly after the Browser-Use team open sourced it, and the reason is not hard to find. It never asks a general purpose model to write a paragraph of analysis before a click. It maps the elements of the current page into a numbered interaction table, lets Jev select the action and locate the target in tens of milliseconds, and only calls a text model when something actually has to be entered. In tests the project completes the whole Google Flights search and comparison workflow in about 7 seconds on its own, including dynamic dropdown menus, multi-step interaction wizards and overlay pop-ups that appear without warning.
The speed is not the part I keep thinking about. The split is. One model plans, another model clicks, and the clicking side has been moved off the general purpose model completely.
That split matters because browser automation around a development workflow fails in a familiar place. AI code assistants got good at writing business logic a while ago. What is left is the surrounding work. GitHub OAuth authorization, Stripe payment callbacks, object storage parameters, the API keys of model providers. Cloud platform backends rarely expose developer-facing meta-configuration interfaces, and traditional scripts break the moment the front-end structure changes.
The setup I ended up with pairs the local AI gateway in ServBay, which runs on macOS and Windows, with the human-like interaction model from Browser-Use. Together they cover cloud console operation and environment configuration as background work.
ServBay AI Gateway is not a switcher, it is a gateway. A switcher answers which provider is in use. A gateway answers how the traffic moves. Anyone who landed here from a search for a cc-switch alternative will find the second question is the interesting one, because a gateway is what makes the rest of this automation possible.
Why the click decisions should not go through a large model
What Browser-Use does with a page
Browser-Use converts rendered page elements into an interaction list with structured numbering, and lets a model decide the next action by reading context and intent.
In the standard mode, every click waits on a general purpose model to generate a response, and a single step takes several seconds or more. The Jev model used by jev-ultrafast does probabilistic evaluation of discrete actions instead, returns an operation instruction in milliseconds, and compresses the total execution cycle of a multi-step web task.
What still deserves a full LLM
Not every decision should be pushed down to the fast model. Macro-level workflow planning stays with the general purpose LLM. Given the goal of creating an OAuth application, it breaks the work into stages such as opening the settings page, entering developer options, creating a new application and filling in the callback URL. Those calls are infrequent, and what they need to deliver is logical completeness rather than latency.
The two pieces
Browser-Use and the Jev judgment model
Jev is a judgment model that evaluates discrete action probabilities. When a user agreement update, a promotional overlay or a floating element shows up on the page, Jev evaluates the probability distribution over the interactive elements and issues a click or an ignore instruction without waiting on text generation. That is what makes high-frequency interaction practical instead of theoretical.
The local gateway layer
ServBay is an all-in-one AI development management tool. It runs on macOS and Windows and ships PHP, Node.js, MariaDB and Redis out of the box. Its AI Gateway provides centralized traffic scheduling and API management for the local development environment.
Four areas of the gateway matter for this build.
- Full protocol bidirectional conversion across the OpenAI, Anthropic and Gemini API protocols. An upper layer application follows one common client specification, and the gateway handles protocol mapping and parameter reconstruction.
- Multi-channel fusion with automatic hot switching. Official APIs, personal subscription accounts and third-party relay channels can all be attached. When an endpoint hits a network timeout or HTTP 429 rate limiting, traffic moves to a backup channel.
- Model alias remapping, which lets one model identifier be redirected to another model, so an expensive call can be pointed at a low-cost alternative.
- Project-level virtual keys and resource isolation. Separate local virtual keys can be generated for separate projects, with Token consumption tracked per project and access permissions configured per key.
Getting the runtime in place
Python and driver dependencies
The system needs a supported operating system such as macOS or Windows, Python 3.10 or higher, and a locally installed Google Chrome.
ServBay provides a one-click Python install. Open the Packages panel, find Python, and install it.
Then use the uv tool to isolate and sync dependencies inside the local project directory.
# Clone the ultrafast implementation repository git clone https://github.com/browser-use/jev-ultrafast.git cd jev-ultrafast # Sync project dependencies based on the Python environment provided by ServBay uv sync # Install browser debugging and control components uv run playwright install chromium After installation, one self-check command diagnoses the debugging connection status of the local Chrome.
uv run browser-harness --doctor Adding a channel and a virtual key
In ServBay's AI Gateway, add a channel and follow the prompts step by step.
The virtual key is issued separately.
Because ServBay performs cross-protocol conversion, a request sent from Python code with the OpenAI SDK is converted at the underlying layer into the protocol format of Anthropic or another provider. The application side does not have to know which provider ends up serving the call.
Two-layer control flow
The architecture keeps network routing and interaction decisions in separate places, which avoids the latency accumulation and logic drift a single large model produces over a long workflow.
│ [System One: Jev Ultra-Fast Judge] │ - ms-level robust clicks, close overlays, locate buttons │ └───────────────────────────┬────────────────────────────────┘ │ CDP protocol control ▼ ┌────────────────────────────────────────────────────────────┐ │ Developer's local Chrome (reuses real login state) │ │ │ │ [Third-party platforms / LLM consoles / infrastructure] │ └────────────────────────────────────────────────────────────┘ Planning and execution
- Macro-level workflow planning. The general purpose LLM parses the initial goal. For the task of creating an OAuth application, it splits the work into discrete stages such as opening the settings page, entering the developer options, creating a new application and filling in the callback URL. Calls at this layer are infrequent and focus on logical completeness.
- Micro-level action decisions. On each individual page, the Jev model handles the interaction decisions. When a user agreement update, a promotional overlay or a floating element appears, Jev quickly evaluates the probability distribution of the interactive elements and issues a click or ignore instruction, with no extra wait on text generation.
Login state reuse
Most cloud platform consoles use two-factor authentication. This approach mounts the developer's local default Chrome User Data Profile and launches a browser instance with a remote debugging port attached. Once the system starts, it inherits the existing login cookies and sessions and bypasses CAPTCHA and SMS confirmation steps. When an occasional security challenge blocks the way, the system pauses for a human to complete the one-time interaction, then continues the task.
Two loops I run
Topping up an upstream channel automatically
When the model quota of an upstream channel in the ServBay gateway runs low, or a new official API has to be added, the system can provision the channel unattended.
import os from jev_ultrafast import Agent def auto_provision_upstream_channel(): target_url = "https://aistudio.google.com/app/apikey" task_prompt = "Find the Create API Key button, generate a key for a new project, and return the key text." # Attach to the developer's local, already logged-in Chrome environment with Agent(target_url, task_prompt) as agent: api_key = None for step in agent.run(): if step.get("status") == "success" and "result" in step: api_key = step["result"] break if api_key: # Once the key is obtained, it can be registered into the ServBay channel pool via the local REST interface print(f"Successfully obtained API key: {api_key[:8]}******") if __name__ == "__main__": auto_provision_upstream_channel() The whole process runs in the background, and the captured key goes straight back to the local gateway. Manual login and copy-paste disappear from the workflow.
Wiring third-party credentials into a local project
When a web application is initialized in ServBay and the project root has no .env configuration, the console operator supplies the required external service parameters.
Taking GitHub OAuth login as an example, once the local development port arrives, such as http://127.0.0.1:3000/api/auth/callback/github, the system does the following automatically.
- Drives the local Chrome to the GitHub developer settings page.
- Fills in the application name and configures the development callback URL.
- Clicks create and generates a new Client Secret.
- Reads the generated parameters, formats them, and writes them into the project's .env.local file.
- Notifies the local runtime to hot-reload the environment configuration.
How this compares with the alternatives
Comparison at a glance
| Evaluation Dimension | Traditional Automation Scripts (Playwright, etc.) | Monolithic Browser Agent Approach | ServBay + Browser-Use Collaborative Approach |
|---|---|---|---|
| Element Location Mechanism | Heavily relies on fixed CSS or XPath selectors | Relies on visual snapshots and general-purpose LLM judgment | Combines structured DOM labels with Jev probabilistic decision-making |
| Resistance to Page Changes | Extremely weak — a minor DOM structure change breaks the script | Relatively strong, but parsing is easily disturbed by redundant information | Strong, with semantic self-healing and overlay-skipping capabilities |
| Interaction Response Latency | Millisecond-level (but extremely costly to write and maintain) | 3 to 8 seconds per step; workflows are extremely slow | Core interactions in tens of milliseconds; smooth workflows |
| API Call Cost | No LLM API cost | Each operation consumes a large number of vision tokens | Combined with ServBay model remapping, cost is significantly reduced |
| Network Fault Tolerance | No intelligent network routing involved | Errors out and exits immediately on HTTP 429 or network loss | ServBay automatically performs seamless cross-channel hot switching |
| Local Development Integration | Requires additional data-transfer logic | Just a standalone script, lacking environment support | Seamlessly unified with the ServBay local environment and virtual keys |
Production safety notes
What I lock down
- In-memory credential redaction. When the console generates a password or a Secret, the extraction logic reads the text node locally over the CDP protocol. Full-screen rendered images are never uploaded to an external large model, so sensitive strings cannot leak through that path.
- Isolation of high-risk actions. For destructive operations such as account cancellation, deleting existing resources or changing the billing method, a keyword blocklist sits inside the task planner. As soon as a match occurs, the flow is interrupted and a human is prompted.
- Local virtual key lifecycle management. Each individual script gets its own virtual Key, restricted to a specific subset of models and a rate quota, so an anomaly in one piece of logic cannot drain the main account balance.
What I take away
Console work moving to the background
Software engineering is shifting from code completion assistance toward automation that spans runtime environments, cloud credentials and service orchestration. Writing business code was never the whole job. Provisioning external resources, authentication handshakes and environment integration take up the rest of it.
The pairing described here has clearly divided responsibilities. ServBay handles the infrastructure problems, which include inconsistent protocols across model providers, channel failover and project-level asset isolation. Browser-Use, working with the Jev ultra-fast judgment model, crosses the barrier of consoles that have no API, and takes on the human-like interaction role.
Their collaboration opens an automated flow for local projects to obtain external cloud resources, and it makes the local gateway self-sufficient with respect to its upstream channels. As local development environments and large-model agent technology keep converging, console interaction gradually migrates to silent background services, which leaves engineering teams working on business logic and system design instead of backend configuration.
