lupin.Open console
Comparisons

Lupin vs SOAX: package routing rules and shared agent proxy management

Compare SOAX’s current residential and mobile proxy platform with Lupin’s configured traffic-allocation API.

Current availability matters more than a product label

SOAX’s current developer introduction describes residential and mobile proxies, package-based access and routing rules in connection credentials. It also describes additional surfaces in closed alpha, including a headful browser path with separate provisioning. Lupin exposes proxy-user allocation and usage management, while its browser sessions are a different product without custom Lupin proxy routing. A comparison should distinguish generally documented proxy access from experimental browser availability. Do not assume a closed-alpha capability is included in a standard proxy account or ready for a production dependency.

Routing rules can favor direct SOAX

SOAX documents a connection structure in which routing rules are supplied as the proxy username and a package key authenticates access. This can fit an application that needs direct control over location and session behavior in its client configuration. Lupin’s public contract returns supported connection details for configured proxy capacity and manages per-user traffic. Prefer SOAX when its documented routing and package model is a hard requirement. Prefer Lupin when the exposed route is sufficient and shared resource ownership is the main integration benefit.

DecisionLupinSOAX
Access modelWorkspace proxy user and allocationPackage key plus routing rules
Current network selectionConfigured capacity exposed by APIDocumented residential/mobile paths
Browser couplingCustom Lupin routing not supportedHeadful browser described as closed alpha

A package key is a secret even when embedded in a URL

SOAX’s documented connection format places authentication material in the proxy connection configuration. Lupin likewise returns username and password details for a proxy user. Redact complete connection strings from logs, exception reports and prompts, including values a client library prints automatically. Keep management credentials separate from workload access and record which customer owns each allocation or package reference. Configuration convenience does not remove the need to rotate exposed secrets or to prevent one agent from using capacity intended for another tenant.

Separate session continuity from experimental browser state

A proxy session rule concerns the network route. A stateful browser also has cookies, local application data and an execution lifecycle. SOAX’s closed-alpha browser description should be evaluated under its own current provisioning and contract, not inferred from a routing parameter. Lupin’s current browser retains state only while the session is open and does not consume custom Lupin proxy routing. If the workload needs coupled browser and network state, make that an explicit acceptance gate and verify availability before pricing or designing around either architecture.

Estimate package consumption and pool behavior explicitly

Use current SOAX terms for the selected network type, package capacity, request pattern and routing options. Lupin proxy usage is separately priced, and automatic refill draws from a finite configured workspace pool. Include retries, bytes transferred and support work for route failures in the same workload model. SOAX may be better when its direct package and routing design fits the application. Lupin may be better when supported proxy access is one resource among an agent’s inboxes, apps and execution environments. No network-size, speed or access-success ranking is derived from this source review.

Choose with an availability and routing exercise

List the exact required route, session behavior, client protocol and browser-state requirement. Check which SOAX features are available to your account and which need separate alpha provisioning; map Lupin only to its actually exposed proxy and browser surfaces. Use fixture configurations before a controlled authorized connection test. Prefer direct SOAX when its current proxy model satisfies the hard requirements. Prefer Lupin when its supported allocation layer and shared agent controls are sufficient. If a browser feature is essential but only experimental or unavailable, retain that as an unresolved requirement rather than treating a roadmap as shipped functionality.

A SOAX migration should inventory package keys, routing rules and any separately provisioned alpha dependencies. Recreate credentials and verify supported route behavior at the destination, while preserving task and usage history in the application. Do not copy SOAX-specific username rules into Lupin and assume identical session semantics.

Sources & verification

Official documentation and Lupin public documentation/source were reviewed on 2026-11-05. This is an architecture and operating-scope comparison, not a live benchmark, hands-on provider test or independent review of service quality.

Prepared with AI assistance by Lupin editorial. How we research and maintain these guides.

Put it into practice

Give your agent the right tools.

Review the API, workspace requirements and permissions before enabling a workflow.

Explore proxies