> ## Documentation Index
> Fetch the complete documentation index at: https://docs.chatblocks.ai/llms.txt
> Use this file to discover all available pages before exploring further.

# Plans and limits

> Three plans (Free, Builder, Enterprise), hard per-resource caps, and a workspace.get MCP tool that surfaces your current usage.

Chatblocks has three plans. Limits are enforced at create-time on the server — there's no soft cap or "grace" behavior; over-limit writes return `LIMIT_REACHED` and the resource isn't created.

<Note>
  **Coding agents:** call the MCP `workspace.get` tool **before** writes to fetch the current `limits` payload. Each resource includes `used` / `max` / `resetsAt` so you can preflight and skip the write rather than burning a tool call on a 4xx. For period-based limits (builds, AI generation), `resetsAt` is the first of next month in UTC; count-based limits return `null` for `resetsAt`.
</Note>

## Plans

| Plan           | Price                    | Who it's for                                                         |
| -------------- | ------------------------ | -------------------------------------------------------------------- |
| **Free**       | \$0                      | Trying out the platform. Hard caps on everything that costs money.   |
| **Builder**    | $9 / month or $89 / year | Solo operators. Single-paying-owner model with read-only co-members. |
| **Enterprise** | Contact sales            | Teams, custom caps, manual plan flip — no Stripe subscription.       |

The customer-facing plans are Free, Builder, and Enterprise. Internally, anonymous homepage playground sessions use a temporary `"anon"` plan with tighter caps and a 24-hour cleanup window.

## Per-resource caps

These are the current launch limits, sourced from `apps/web/convex/lib/limits.ts`:

| Resource                      | Free | Builder   | Enterprise |
| ----------------------------- | ---- | --------- | ---------- |
| Blocks                        | 10   | 100       | 10,000     |
| Canvases                      | 2    | 20        | 1,000      |
| Scheduled runs (Beta)         | 0    | 5         | 500        |
| Data sources (Beta, per type) | 0    | 10        | 100        |
| BYOK keys                     | 0    | 3         | 50         |
| Workspace members             | 1    | unlimited | unlimited  |
| Builds per month              | 100  | 1,000     | 100,000    |
| AI-generated blocks per month | 0    | 30        | 10,000     |
| MCP requests per minute       | 60   | 600       | 6,000      |

Notes on a few of these:

* **Data sources are Builder beta.** Stripe, Postgres, inbound webhooks, and outbound MCP are all behind Builder while connector performance and edge cases are still being hardened.
* **BYOK keys = 0 on Free.** You can't bring an Anthropic or OpenAI key on Free, which means you can't run scheduled-run agents or use `blocks.create` AI generation. Free authoring still works two ways: the in-app editor, or your own coding agent over MCP (`blocks.init` → `blocks.setFiles` → `blocks.build` → `blocks.publish`). Builder unlocks AI generation, data sources, BYOK, scheduled runs, and stores.
* **Scheduled runs are Builder beta.** Free workspaces can read the docs, but creation, preview, run-now, pause/resume, and deletion all return `PRO_REQUIRED`.
* **AI-generated blocks per month = 0 on Free** — `blocks.create` (the streaming AI-generation tool) is Builder-only. Free users can scaffold and edit blocks in the in-app editor; Builder unlocks the MCP scaffold/build/publish loop.
* **Members.** Builder is *one operator*: the owner has write powers, and any co-members are viewers (read-only). See [Workspaces → Builder co-member model](/concepts/workspaces).
* **MCP rate limit** is per-key, sliding window. Different keys on the same workspace get independent budgets.

## Refund policy

**No published refund policy.** Builder is a small solo-operator product — `/settings/billing` leads with a warm support pitch, and refunds are handled case-by-case if you reach out.

## Upgrading

The workspace **owner** triggers an upgrade from `/settings/billing` → "Upgrade to Builder" → Stripe Checkout (hosted, no UI on our side). On `checkout.session.completed`, the workspace's `plan` flips to `builder` and the limit table jumps immediately. Co-members can see the page but only the owner can start a checkout — billing follows the paying account.

Plan switching, cancellation, and card updates all happen in the **Stripe Customer Portal**, also hosted. The portal link is on `/settings/billing` for the owner of a paid workspace.

Enterprise plans are flipped manually — there's no self-serve path. [Email me](mailto:me@kevinfang.tech) or [DM me on X](https://x.com/sofangtastic) if you need higher caps or a non-Stripe billing arrangement.

## Reading limits programmatically

Two endpoints surface the same `limits` payload:

* **MCP `workspace.get`** — for agents. Returns `{ id, name, slug, plan, member_count, limits: { blocks, canvases, schedules, buildsPerMonth, aiGenPerMonth, dataSources, byokKeys, members, storeBlocks } }`. Each resource includes `used`, `max`, and `resetsAt`.
* **Convex `api.mcp.tools.getMyWorkspaceLimits`** — for the web UI. Same payload, member-gated, used by `/settings/billing`.

`max: null` represents `Infinity` on the wire (members on Builder/Enterprise). `used: null` on `buildsPerMonth` and `aiGenPerMonth` means the rate-limiter doesn't expose current consumption — only the cap. Period-based limits return a monthly `resetsAt`; count-based limits return `null`.

## What's next

<CardGroup cols={2}>
  <Card title="Billing → Plans" icon="credit-card" href="/billing/plans">
    Pricing detail, line items, what's included.
  </Card>

  <Card title="Customer Portal" icon="receipt" href="/billing/portal">
    Cancel, switch plans, and update your card via the hosted Stripe portal.
  </Card>
</CardGroup>