A workspace is the tenant: its members, its billing, and everything published into it. It's the trust boundary, so most access questions resolve to "which workspace, and what role".
Your account can belong to several - one for your own work, one per team or client. Instances are connected to your account, so they see every workspace you're in and can target a specific one when it matters.
Roles
| Role | Can do |
|---|---|
| Owner | Everything, including billing, deleting the workspace, approving promoted memory, and the oversight view |
| Admin | Membership, settings, the workspace guide, exports and oversight - not the things reserved to owners |
| Member | Publish, recall, remember, comment, approve |
| Viewer | Read. Free - a viewer consumes no seat |
Owners and admins also hold the audit-logged oversight view of content members have kept private, so a workspace's stewards can always account for what's in it.
Set a member's role in Settings -> Members.
Inviting people
Settings -> Members -> invite. They get a link, sign in, and join with the role you gave them.
Before you invite, check it's the right mechanism. If the person only needs to look at one project and react to it, a share code is free, scoped to a single tag, and revocable in one click. Invite people who are part of the team; use a code for everyone else.
Removing a member cuts their access. What they published stays in the workspace, correctly attributed - the record doesn't develop holes when someone leaves.
Seats and what you pay for
You're billed for signed-in human members who can write. Not for:
- viewer-role members - a read-only member of the workspace is free, however many of them you add,
- your AI instances - connect as many as you like, on as many machines,
- guests on share codes - viewing, commenting and approving are free,
- workspaces themselves.
That's deliberate. Charging per agent would make you ration the thing the product is for, and charging a reviewer for leaving a comment would stop the review loop happening. Reading is free for the same reason: a wiki you have to buy seats for is a wiki nobody in the wider company reads.
Give someone viewer and they read the workspace and its wikis at no cost. Give them anything else and they're a seat, so if you're unsure which a person needs, the free one is the safe place to start.
Current plans and prices are on the pricing page - that's the source of truth, not this page. See Plans and billing for how seats behave.
Several workspaces
Common shapes:
- Personal + team. Your own workspace for scratch work and your own memory; the team's for shared context. Promote from one to the other when something has earned it.
- One per client. Total separation, and ending an engagement is a workspace decision rather than an audit.
A collection can be shared between workspaces you belong to, and memory can be promoted with a review gate. Tools take an optional space parameter (by id or name) - the CLI/MCP name for a workspace; omit it when you're only in one workspace and it resolves automatically.
kythe spaces # list the workspaces you belong toDeleting a workspace
Deleting a workspace irreversibly erases its data - collections, artifacts, memory, tags, members, and the stored bytes in the object store. Export first if there's any chance you'll want it: see Exporting your data.