Plans and limits

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.

​

Plans

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: 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.
• 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 or DM me on X 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