Settings & billing

/dashboard/settings is the only surface in the Account group. Profile and Organization keep their state when you switch between them, so a half-typed edit is not thrown away by a click.

Your personal details, shown across the Console and to your team: display name, company, phone, website, timezone and a short bio. Email is displayed but not editable here, because it is the identity the auth provider holds.

Below the form, two read-only facts worth knowing when you are debugging an access problem: which auth provider signed you in, and the first eight characters of your user id.

Settings › Security turns it on for your account. Scan the QR code with any authenticator app, or type the key, then enter the 6-digit code. After that, every login asks for a code before the Console opens, and so does connecting the Lobstack app.

You can add more than one authenticator. Adding or removing one goes on the audit record of every organization you belong to.

An owner can require it of everyone under Permissions, once their own account has it. Members without an authenticator set one up before they see the Console. Until a session has entered its code, changing keys, provider keys, webhooks, caps, clients, members, invites or permissions, and reading the audit log, members, keys or webhooks, answer 403 MFA_REQUIRED.

Requiring it needs migration 20261003e_org_require_mfa.sql. Until that is applied, the switch is unavailable and reads as off.

Add a second authenticator when you set up the first; Settings › Security suggests it. With two, losing a phone is a non-event: log in with the other and remove it.

With none left, email hello@lobstack.ai from the address on your account. We confirm it is you before changing anything, then remove the authenticator so you can log in and set up a new one. The removal is on your organizations' audit record.

An organization is what owns things. Keys, request traces and billing history attach to it rather than to a person, which is what makes them survive somebody leaving. Everyone starts with a personal organization.

The tab opens on a list of the workspaces you belong to with your role in each. Selecting one shows its profile — name, description, website, industry, size — and its members.

Owner and admin are the two roles that count as administrative. Members create and manage their own API keys; admins manage every key. On Agency and Scale, an owner can narrow this under Permissions. Three rules constrain the members list: you cannot change your own role, only an owner can act on another owner, and the role dropdown offers Owner only when you are one. Role changes apply optimistically and roll back visibly if the server refuses.

Admins invite by email with a role attached, and the picker prints what that role means before the invite is sent. An invite expires seven days after it is created; pending ones are listed with their expiry and can be revoked.

When the invite email cannot be delivered, the Console says so and hands you the link instead of failing silently — the invite itself was created either way, and the link is copyable from the pending list.

Every person in the organization takes a seat, and so does every invite that is still waiting. When all of your plan's seats are taken, a new invite is refused with 402 SEAT_LIMIT; remove someone or cancel a waiting invite to free one. If your organization has more people than its plan includes (after a downgrade), everyone stays — you just can't invite anyone new. Seats per plan are listed on Pricing & plans.

Beyond the personal organization, creating workspaces is limited to one additional organization on every plan, and to five on the legacy enterprise tier. Exceeding the limit returns a refusal naming the limit rather than a generic error.

On a paid plan — Developer, Agency or Scale — you can add your own API key for Anthropic, OpenAI, Google, xAI or DeepSeek. One key per provider; saving a new one replaces the old.

When the router (auto) picks, or the caller names, a model on a provider you hold a key for, the call runs on your key. It is metered and gets the normal receipt, with x-lobstack-mode: byok. It is not marked up and does not spend the plan's dollar allowance. Calls to other providers run on Lobstack's keys as usual.

If the allowance runs out, calls to providers you hold a key for still go through. Without a key of your own, an exhausted allowance is a 402.

Only owners and admins can add or remove a key. Members see which providers have one and its last four characters. Keys are encrypted with AES-256-GCM before they are stored, and are decrypted only to call the provider that issued them; how is on Security.

There is no default model to set. A call uses the model it names, or auto, where Nex picks one per request.

The Billing tab shows the plan, its price and when it renews, and says when a subscription is set to cancel. Upgrading, downgrading, cancelling, changing the card and downloading invoices happen in Stripe's customer portal, which the tab opens. An account that has never paid is shown the plans instead, since there is nothing yet to manage.

Usage carries the full allowance panel for the billing period, in whichever unit the account was sold — dollars of model spend, requests on the BYOK plan (no longer sold), or messages on a legacy subscription — and the top-up buttons for plans that sell them. Plan prices, allowances and the three meters are on Pricing & plans.

On the Agency and Scale plans an owner can change these in Settings › Permissions: whether members or only owners and admins can create API keys (approving a Lobstack app sign-in creates one, so it follows the same rule), and whether admins or only owners can change spend caps and client budgets. The same tab can require two-step verification for every member. A refused request answers 403. Every change is on the audit record, and settings chosen on a higher plan keep applying after a downgrade.

Settings › Spend caps sets a monthly limit on what each person, or each API key, can spend, on the Agency and Scale plans. A person's cap covers every key they created. Stop calls refuses further calls with 402 PERSON_CAP_REACHED or 402 KEY_CAP_REACHED once the month's spend reaches the cap; Alert only keeps serving. Both email the organization's owners (and, for a person's cap, that person) at 80% and 100%.

The counter moves after each call, so a cap stops calls within one call rather than to the cent, and a change takes up to a minute to reach every server. Months are UTC. Only calls made with an API key count toward these caps. Budgets per client are under Clients. Caps already set keep working after a downgrade, and can always be removed.

Settings › Audit lists who did what in the organization, newest first: API keys created, changed and revoked, people joining, leaving and changing role, invites, clients, spend caps, webhooks, provider keys, permission changes and two-step verification. Filter by person, kind of action and dates, and export everything the filters match as CSV or JSON Lines. Owners and admins can see it, on the Agency and Scale plans.

Records are written on every plan and kept for as long as the organization exists, unless an owner chooses a shorter period, so upgrading shows the history from before. On Scale, each record is also sent as it is written to any webhook subscribed to audit.event. The same list is GET /api/v1/audit (?format=csv or ?format=ndjson for a file).

Keep audit history for is Forever by default. An owner can choose 2 years, 1 year or 90 days instead, on the Agency and Scale plans; Forever can be chosen again on any plan. A shorter period starts 7 days after it is saved, so a wrong choice can be put back before anything is removed.

After that, a daily job removes records older than the period and writes one record saying how many it removed and from before when. Nothing from the last 90 days is ever removed, and changing the period is itself on the record. The setting is also PUT /api/v1/audit/retention with {"days": 365}, or null for Forever.

Pull it on a schedule, receive it as it happens, or both. Either way your SIEM keeps its own copy, for as long as you need it, whatever the period above.

An owner or admin creates an API key with only the audit:read scope. It reads the record for as long as the person who made it is still an owner or admin. Ask for JSON Lines: records oldest first, one object per line, 1,000 per page unless limit says otherwise (up to 5,000).

The screen's filters work here too: actor, action (one action, or a group such as api_key.), from and to. Without to, a page stops 5 seconds short of now, so a record that is still being written arrives on the next pull rather than being stepped over.

On Scale, subscribe an endpoint to audit.event under Webhooks. Each delivery is signed and retried, and its data carries the record's id and created_at, so a collector that also pulls can drop the duplicates.

Lobstack used to run agents in hosted VMs. That product was retired on 11 September 2026; these notes stay for anyone who used it. The Server and Agent tabs — tier, region, rebuild, the type-DESTROY teardown, the messenger picker and the tool-approval switch — operated that VM and are gone. Nothing replaces them: there is no machine to size, move, restart or destroy. The Model tab wrote a model, a mode and a key to the organization's agent row, which organization API keys do not read. Provider keys replaced it on 2026-09-28.