Personas

Why not just an IP?

Agents that maintain logins or operate accounts get flagged when their IP drifts mid-session, and accounts get linked when different agents share an exit. A Persona solves both: it is a dedicated egress — never shared with another customer — whose identity survives the whole lifetime of the work, not just one request.

Creating and using a Persona

Create a Persona in the console or via the REST API, choosing one of the launch regions (Japan, United States, Hong Kong, Singapore, United Kingdom). You get a stable handle with a p_ prefix.

POST /v1/personas
{
  "region": "jp",
  "intent": "account_ops",
  "name": "jp-shopper-01"
}

→ { "id": "p_jpshopper01", "status": "active", "region": "jp" }

Route any gateway connection through it with session-p_jpshopper01 in the proxy username, or pass persona="p_jpshopper01" to the MCP fetch_url tool.

Lifecycle and health

Personas have a state machine: active → migration watch (if the upstream exit must be replaced) → frozen grace (on insufficient balance, 7 days) → released. IP migration is treated as a degradation event, not a silent swap: you are notified, the Persona enters a watch period, and the event is recorded in its timeline. Health is tracked at the connection level (tunnel success rate and connect latency) in the MVP.

Persona vs. temporary sticky session

A sticky session (random session-<id>) pins a rotating exit for minutes to hours and costs nothing beyond traffic. A Persona is for identities that must persist for days or months: it carries a per-region occupancy fee (accrued daily) plus traffic.