Workspace Billing, Access, and Collaboration
What author pays vs collaborator pays means, how purchase requirements work, and how edit collaborators are granted or restricted.
Where you see this in the app
These controls also live in the post-level Workspace config & automations panel under the Config tab.
They decide who can open or edit the workspace, who is billed for AI usage, and how collaborators are granted access.
Workspace and artifact billing modes
The most important billing choices are:
| Setting | What it means |
|---|---|
| Workspace billing mode | Who is charged when workspace AI usage occurs |
| Artifact AI billing mode | Who is charged when the published artifact app makes AI requests |
The user-facing meanings are:
| Option | Plain-English meaning |
|---|---|
Author pays | The post owner absorbs the AI usage cost |
Collaborator pays | The person using the workspace is billed for that usage |
Viewer pays | For artifact AI billing, the viewer using the published artifact app is billed |
The main decision is economic, not technical. Choose the mode based on whether the creator is sponsoring usage or expects each collaborator/viewer to cover their own AI activity.
Purchase requirements
The workspace and artifact purchase requirements are separate controls.
| Setting | Plain-English meaning |
|---|---|
| Workspace purchase requirement | Whether a non-buyer can open the workspace in view mode |
| Artifact purchase requirement | Whether a non-buyer can open the published artifact site |
This separation matters because a creator may want:
- the artifact site to be publicly viewable while the deeper workspace stays paid,
- the workspace to be available for preview but the final artifact to stay purchase-gated,
- both surfaces to require purchase.
Do not treat workspace access and artifact-site access as the same switch.
Shared edit sessions and view-mode CLI
Two settings strongly affect collaboration behavior:
| Setting | Plain-English meaning |
|---|---|
| Shared edit sessions | Whether collaborative edit sessions are allowed when the feature is available |
| View-mode CLI | Whether viewers get preview-only access or a read-only terminal/Codex experience |
View-mode CLI in Disabled (preview only) means the viewer only gets the preview layer.
Read-only terminal/Codex means the viewer can inspect through a read-only workspace terminal experience, but that does not make them an editor.
The UI also warns that in read-only collaborator mode, only the post owner can start edit sessions. That warning should be taken literally.
Edit collaborators by tags and email
Edit access can be granted in two main ways:
| Setting | What it does |
|---|---|
| Edit collaborators (audience tags) | Grants edit eligibility to members whose relationship tags match the listed tags |
| Edit collaborators (explicit user emails) | Grants edit eligibility directly to named users |
The audience tags version supports custom membership tags and the special __signed_in__ tag.
That means a creator can choose between:
- broad signed-in access,
- tag-based collaborator groups,
- a short allowlist of specific users.
If collaboration is unexpectedly unavailable, check these access controls before assuming the workspace itself is broken.
See it in action
Previous
Workspace Automation Controls
The end-user guide to schedule setup, webhook triggers, Telegram and WhatsApp controls, and what each workspace automation setting changes.
Next
Workspace Rules and Trigger States
How the Rules tab works, what enabled or disabled rules mean, and how schedules, webhook rules, and system triggers are surfaced to end users.