ServBay AI Gateway is a gateway, not a switcher. A switcher answers which provider a request should be routed to. A gateway answers how that request travels once the choice is made, which protocol it gets converted into, which credential it carries, and which channel absorbs the traffic when the current one stops responding. Teams comparing options for a cc-switch alternative usually need the second set of answers, since picking a provider is the easy half.
Browser automation is where the two layers meet. jev-ultrafast, the open-source project released by the Browser-Use team on top of Jev, passed 21,000 stars on GitHub after launch. Jev is a judgment model focused on evaluating discrete action probabilities, built to replace the high-latency operating pattern browser agents used to depend on.
The mechanism is specific. Page elements are mapped into a numbered interaction table, Jev completes action selection and target localization within tens of milliseconds, and a text model is called only when particular content has to be entered. In testing, the project carried out an entire Google Flights search and comparison workflow in about 7 seconds, handling modern single-page applications, dynamic dropdown menus, multi-step interaction wizards, and overlay pop-ups that appear mid-task.
That class of high-frequency, low-latency web operation has a place in daily development work. AI code assistants finish business logic quickly, yet setting up GitHub OAuth authorization, Stripe payment callbacks, object storage parameters, or the API keys of model providers still involves switching between browser tabs and completing logins, form submissions, and key copying by hand. Cloud platform consoles rarely expose developer-facing meta-configuration interfaces, and traditional scripts break as soon as the front-end structure changes. Combining the local AI gateway from ServBay with the human-like interaction model of Browser-Use gives a workable path to an automated cloud console operation and environment configuration system.
Three Primitives in the Jev Decision Model
A numbered interaction table instead of a visual snapshot
Browser-Use converts rendered page elements into an interaction list with structured numbering. The decision model reads that list together with the surrounding context to choose the next action, so element location stays tied to page structure rather than to fixed CSS or XPath selectors, or to a rendered image that has to be interpreted.
Discrete action scoring within tens of milliseconds
Jev evaluates the probability distribution over candidate interactive elements instead of generating an explanation before every click. In standard mode, the agent waits for a general-purpose large model to produce a response for each step, and a single step takes several seconds or more. The Jev path returns an operation instruction within milliseconds, which compresses the overall execution cycle of a multi-step web task. In the jev-ultrafast implementation this covers millisecond-level clicks, closing overlays, and locating buttons.
Text generation stays at the planning layer
The general-purpose LLM handles macro-level workflow planning. For a task such as creating an OAuth application, it breaks the work into discrete stages like opening the settings page, entering the developer options, creating a new application, and filling in the callback URL. Those calls are infrequent and focused on logical completeness. Per-page decisions belong to Jev. When a user agreement update, a promotional overlay, or a floating element appears, Jev scores the interactive elements on the page and issues a click or ignore instruction with no additional wait on text generation.
The Gateway Half: Protocol, Channels, and Keys
ServBay is an all-in-one AI development management tool that supports multiple operating systems and ships commonly used development components such as PHP, Node.js, MariaDB, and Redis out of the box. Its built-in AI Gateway provides centralized traffic scheduling and API management for the local development environment.
Bidirectional protocol conversion
The gateway converts between the OpenAI, Anthropic, and Gemini API protocols in both directions. Upper-layer applications follow a common client specification, and the gateway handles protocol mapping and parameter reconstruction.
Channels, hot switching, and model remapping
Channels can be official AI APIs, personal subscription accounts, or third-party relay services. The provider list spans OpenAI, Anthropic, Gemini, Azure, AWS Bedrock, Groq, Qwen, DeepSeek, Kimi, GLM, Baidu Qianfan, Tencent TokenHub, and OpenRouter, with local Ollama available alongside them. When one endpoint hits a network timeout or a 429 rate limit, the gateway moves traffic to a backup channel automatically. Model alias remapping lets a specific model identifier be redirected to another model, which is how an expensive call can be pointed at a lower-cost, higher-performance alternative.
Project-level virtual keys and resource isolation
Independent local virtual keys can be generated for different local development projects, token consumption can be tracked per project, and access permissions can be configured per key. A single script or project does not need to hold an upstream official credential at all.
Running the Two Layers Together
Planner and executor
The system uses a two-layer control architecture that combines ServBay's network routing with Browser-Use's human-like interaction. The split avoids the latency accumulation and logic drift that a single large model produces across long workflows.
Login state reuse over CDP
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. On start, the system inherits existing login cookies and sessions, so CAPTCHA and SMS confirmation steps are bypassed. When a security challenge does block the way, the system pauses and waits for a one-time human interaction, then continues executing the task. The control layout looks like this.
│ │
│ [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] │
└────────────────────────────────────────────────────────────┘
Setup: Packages, Drivers, and a Gateway Channel
Running this system requires a supported operating system environment such as macOS or Windows, Python 3.10 or higher, and a locally installed Google Chrome browser.
Python and browser drivers
ServBay provides a one-click Python environment installation. Find Python in the Packages panel and download and install it with one click. Then use the uv tool to isolate and sync dependencies in 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, a self-check command diagnoses the debugging connection status of the local Chrome.
uv run browser-harness --doctor
Adding a channel and issuing a virtual key
In the AI Gateway panel, add a channel and follow the prompts. Fill in the channel name and API key, and ServBay detects the available models from that channel. The virtual key issued by the gateway is configured next, from Access Management.
Protocol conversion at the endpoint
Because the gateway converts across protocols, code that sends requests with the OpenAI SDK in Python can still reach Anthropic or another provider, since the conversion happens at the underlying layer without changes to the calling code.
SDK Usage: Provisioning Channels and Project Credentials
Provisioning an upstream channel
When the model quota of a gateway upstream channel runs low, or a new official API has to be added, the system can top up channels 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 is passed back to the local gateway, which removes manual login and copy-paste steps from channel maintenance.
Third-party credentials for a local project
When a web application is initialized in ServBay and the project root is missing an .env configuration, the console operator supplies the external service parameters that the project needs. With GitHub OAuth login as the example, once the local development port is known, such as http://127.0.0.1:3000/api/auth/callback/github, the system completes the following steps.
- 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
Engineering Boundaries
How the approaches compare
| 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 |
Credential redaction and dangerous actions
- In-memory credential redaction. When the console generates a password or Secret, the extraction logic reads the text node locally over the CDP protocol. Full-screen rendered images are not uploaded to an external large model, so the sensitive string cannot leak.
- Isolation of high-risk actions. For destructive operations such as account cancellation, deleting existing resources, or changing the billing method, a keyword blocklist inside the task planner interrupts the flow as soon as a match occurs and prompts for human intervention.
Virtual key lifecycle per script
ServBay can assign a dedicated virtual key to each individual script, restricted to a specific subset of models and a rate quota, so that an anomaly in a single piece of logic does not drain the main account balance.
What Changes in the Development Workflow
Division of labor, restated
The pairing has clearly separated responsibilities. At the system level, ServBay covers infrastructure concerns such as inconsistent protocols for multi-model access, channel failover, and project-level asset isolation. Browser-Use, working together with the Jev ultra-fast judgment model, crosses the manual operation barrier in consoles that expose no API.
Where this leads
The collaboration opens an automated flow for local projects to obtain external cloud resources, and it makes the local gateway self-sufficient with respect to upstream channels. As local development environments and large-model agent technology keep converging, console interaction migrates toward silently executed background services, and engineering teams spend their attention on business innovation and system design rather than backend configuration work.
Top comments (0)