Running accounts at scale

Orbe gives each account its own real-looking machine, its own IP and human input. Running many at once is mostly about respecting those boundaries — not about pushing more actions through faster. This guide is how to do it safely with what ships today.

One profile, one machine

Each profile is a separate browser with its own fingerprint, cookies and proxy. When you automate, you open one session per profile — see the SDK reference. Two consequences shape how many you run at once:

Orbe doesn't limit the number of profiles. How many you open at once is limited by your machine.

Let discipline pace you

Every session runs through Orbe's discipline layer (always on — see Safe by default). At scale, the right mindset is to work with it, not around it:

• Name the platform. Pass the platform hint (or let it be inferred from the URL) so the right checkpoint phrases and usual-hours warning apply. Different platforms tolerate different rhythms.
• Mind usual hours. Orbe never stops a run because of the time, but while pacing is on it warns once per session when a profile works outside its usual hours in the proxy's timezone — accounts active at unusual hours are more likely to be reviewed. Spread a large batch across the day instead of firing everything at one hour.
• Let a block stop you. A checkpoint or a proxy problem raises instead of silently continuing. That is the feature — a stopped run is cheaper than a locked account.

Structure your run

The Python SDK has no built-in scheduler — you write the loop, which keeps you in full control. A complete, runnable version is on this site as examples/fleet_multi_profile.py (it runs a batch with concurrent.futures, each profile keeping its own behaviour). The shape that holds up: iterate your profiles, open one session at a time (or a small batch), do the work, catch blocks, and move on.

import orbe, time

PROFILES = ["acct-01", "acct-02", "acct-03"]   # your ids

for pid in PROFILES:
    try:
        with orbe.Trinh(pid, platform="example") as t:
            t.goto("https://example.com/home")
            if not t.wait_for("Home", timeout=20):
                t.screenshot(f"{pid}-not-loaded.png")
                continue
            # ... your per-account work, spaced with t.wait(...) ...
    except orbe.Blocked as e:
        log(f"{pid} blocked: {e}")   # stop this one, keep the run going
    time.sleep(stagger_seconds())    # don't start the next one instantly
# `log` and `stagger_seconds` are your own helpers; see examples/fleet_multi_profile.py
# for a complete, runnable version.

• One session per profile, inside with so it always closes.
• Confirm the page loaded with wait_for before acting; screenshot and skip if it did not.
• Catch blocks per profile so one stopped account does not end the whole run.
• Stagger starts — a short, varied gap between profiles beats a synchronized burst.

Prefer to drive from an AI assistant? The MCP server holds several profiles at once and the same discipline applies to every tool.

When a profile is blocked

Blocks are signals, not errors to retry through. Handle each by its condition (full list in Handling a block):

Proxies at scale

• One IP per profile. Sharing an IP across accounts links them — the thing separate machines are meant to prevent.
• Residential or mobile (4G) proxies are recommended for account work; datacenter IPs are easier to flag.
• WebRTC is forced through the proxy, so a page cannot read the real IP behind it — one less leak to manage per profile.
• Match the country to the account. Discipline checks the proxy is alive and, where it can, that the region is right before opening.

Do & don't