How to Give an AI Agent a Browser With Persistent Logins

Solari gives an AI agent persistent logins through profiles: sign in once, save the state, and every session created with that profileId opens already signed in, with session create in 8 ms on Steel's open-source benchmark. Without that, your agent signs in, finishes the job, and the next run starts logged out, with a login form, a 2FA prompt or a captcha standing between the agent and its work.

To give an AI agent a browser with persistent logins, save the browser's state after one sign-in (its cookies and per-site localStorage) and load that state into every new session the agent starts. On Solari that saved state is a profile: you create it, sign in once in the console or upload a Playwright storageState file, then pass its profileId when you create a session. The session opens already signed in.

Why Agents Lose Their Logins Between Runs

A cloud browser session starts clean by default, so the cookies from yesterday's login are gone today. The agent has to sign in again on every run, which means handling the login form, 2FA prompts and captchas each time. And as Steel's profiles docs put it, the site then sees a fresh browser on every run instead of a returning one.

The fix is the same on every provider: keep the browser state somewhere durable and seed new sessions from it. What differs is the format of that state, who saves it and when.

How to Set Up Persistent Logins on Solari

Solari sets up a persistent login in three calls: create a profile, put a login in it, attach it to a session. The Solari profiles guide has the full reference.

Create a profile.

const profile = await client.profiles.create({ name: "amazon-seller" })
console.log(profile.id) // "prof_abc123"

const profile = await client.profiles.create({ name: "amazon-seller" })
console.log(profile.id) // "prof_abc123"

const profile = await client.profiles.create({ name: "amazon-seller" })
console.log(profile.id) // "prof_abc123"

Put a login in it. For sites with 2FA or captchas, open the profile in the console (Profiles, then Open editor), drive the live browser in your tab, sign in, and hit Save. If you already have a working Playwright storageState.json, upload it instead:

const storageState = JSON.parse(await readFile("./storage-state.json", "utf-8"))
await client.profiles.save(profile.id, storageState)

const storageState = JSON.parse(await readFile("./storage-state.json", "utf-8"))
await client.profiles.save(profile.id, storageState)

const storageState = JSON.parse(await readFile("./storage-state.json", "utf-8"))
await client.profiles.save(profile.id, storageState)

Attach it to a session.

const session = await client.sessions.create({ profileId: "prof_abc123" })
console.log(session.storageState?.cookies?.length, "cookies loaded")

const session = await client.sessions.create({ profileId: "prof_abc123" })
console.log(session.storageState?.cookies?.length, "cookies loaded")

const session = await client.sessions.create({ profileId: "prof_abc123" })
console.log(session.storageState?.cookies?.length, "cookies loaded")

Every session created with that profileId now starts signed in. Solari profiles use Playwright's standard storageState, the same JSON that context.storageState({ path }) writes, so a login exported from a local Playwright script moves over without conversion. Solari runs this in production at Pinetree Health, its sister company: the Canva scheduling agent signs in once and reopens the same profile on every run.

Solari starts sessions fast, and that matters here, because a profiled agent tends to open many short sessions. On Steel's open-source benchmark, across 5,000 runs, a Solari session was created in 8 ms at the median and the full run from create to release averaged 199.9 ms. Solari's results sit in an open PR on that repo, so anyone can rerun them.

The One Context Rule

A Solari profile seeds the session's default browser context. The profiles docs explain why: a profile is applied at the moment a context is created, so the cookies go in at creation time.

In practice:

• Use session.context or session.newPage() from the launch() wrapper, which creates the seeded context for you.

• Don't assume browser.contexts()[0] is the seeded one.

• A context you create yourself, with session.newContext() or raw CDP, starts clean. Apply session.storageState to it at creation time when it needs the login too.

This is the most common reason an agent seems to lose a login that is actually saved.

How Browserbase, Steel and Kernel Handle Persistent Logins

Solari stores logins as portable Playwright storageState; Browserbase, Steel and Kernel store Chromium's full data directory. Browserbase calls the feature Contexts, Steel and Kernel call it profiles.

Browserbase says its Contexts live indefinitely on its infrastructure and recommends one Context per site, per login, in its Contexts docs. Steel says the strongest setup for account-based agents is one profile plus one dedicated IP per account, in its Profiles API docs. Kernel pairs profiles with Managed Auth, which creates and refreshes logins, and Vaults, which let an agent sign in without seeing raw credentials, in its profiles docs.

The difference is portability. A storageState file is plain JSON you can export from any Playwright script, inspect and version, and move in or out of Solari in one call. A full browser data directory stays with the provider that stores it.

What Persistent Logins Cost

Solari includes profiles on every plan: 3 on Free, 20 on Starter, 500 on Professional and unlimited on Team and Enterprise, as the Solari pricing page shows. A profiled session bills like any other browser session, and Solari's Professional plan bills browsers at $0.07 per hour.

For comparison, Browserbase says its Developer plan is $20 a month with 25 concurrent browsers and 100 browser hours, on its pricing page.

Limits and Security

A persistent login is a real credential, and it comes with a few rules.

• Treat profiles like passwords. Anyone with your API key can attach a profile and act as that account. Use a separate key per environment, as the profiles docs recommend.

• Don't record the login. Session recording is opt-in, and it captures input values by default. Sign in through the profile editor or a session without the recording flag, and restrict who can read any replay that touches a password.

• Sites still expire sessions. A saved cookie works until the site invalidates it. Have your agent check for a logged-out state, sign in again, export the new state with Playwright's context.storageState() and write it back with profiles.save.

• Bot defenses need more than cookies. For account-bound work on sites behind Cloudflare, DataDome, Akamai or PerimeterX, run the session in Solari's stealth mode, included from the Starter plan up, which also powers proxies and captcha solving.

Conclusion

Persistent logins come down to one habit: sign in once, save the state, and seed every session from it. On Solari that state is a profile in Playwright's own storageState format, attached by profileId, with the default-context rule as the one detail to get right. Browserbase is the more established vendor with the larger ecosystem; Solari is the younger company and moves faster on speed and price. If your agent signs in to the same accounts every day, create a profile on Solari's Free plan, sign in once in the console editor, and your next session will open already signed in; Introducing Solari shows the browsers, sandboxes and desktops that run behind the same API key.

FAQ QUESTIONS:

1. How does an AI agent stay logged in between browser sessions?

2. Can I reuse a Playwright storageState file in a cloud browser?

3. Are saved browser logins safe to store with a browser provider?