Plans & limits

The pricing page shows the limits most people compare when choosing a plan. This page is the complete reference, including the caps that rarely bind and so aren't worth putting on a marketing card.

#Limits by plan

Workspace seats are for the people who build in your workspace. Anyone who merely uses a site you publish, including people who sign in to view or edit gated content, never consumes a seat, and is unlimited on every plan. When a visitor signs in, Tessryx gives your app a stable, private identifier for them; deciding what each person is allowed to do is something you build into your app on top of that identifier, not a seat you pay for.

On Pro and Agency, you can add custom domains beyond your plan's included count for $8/month each, so a third client site doesn't require moving up a tier.

Media egress isn't metered: assets and published datafiles serve from a CDN with no bandwidth charge.

No website required. A published site is one thing you can build, not something a plan depends on. Every plan runs headless: you can drive your workflows entirely over MCP (no browser, no domain) and never publish a page. Executions cost the same whichever way they're triggered.

#How credits work

For the full mental model (why caching makes a site nearly free to run, and what happens if you run out), see Credits and caching. In short:

A credit pays for an execution (a workflow run, or a direct call to an API template), however it was started: a visitor loading a page, an API request, a scheduled job, a test run in the editor, or your AI agent calling it over MCP. The trigger makes no difference; what costs is the work done. A credit covers up to 10 seconds of an execution, rounded up:

• A typical page render finishes in milliseconds, so it's 1 credit.
• An execution that takes 60 seconds is 6 credits.
• Concurrent iterations each count: a fan-out running ten 10-second iterations is 10 credits, not 1.
• A bare API-template call is one execution too, so it's ~1 credit (they're near-instant).

Cached views are free. A cached page is served straight from the edge without running anything, so a well-cached site uses a tiny fraction of its allowance: a small marketing site runs around 500 credits a month against Pro's 100,000. Building is free too: browsing, drafting, editing, and saving never use credits. Only running does.

How credits expire. On a paid plan, an unused monthly allocation rolls over once: it stays usable through the following month, then expires. On the free tier, the allocation resets each month and doesn't roll over. Credits you buy as top-ups never expire and aren't touched by a change of plan. Changing plan (up or down) clears your included allocation, including anything rolled over, and issues your new plan's allocation less what you've already used this month. Credits you bought separately are never affected. Credits have no cash value and are not refundable.

Note: You're never billed for going over. Credits are prepaid and metering absorbs the small overshoot from a run already in progress. There is no automatic charge: running low prompts you to top up or upgrade, and you decide.

#What happens at a limit

Running out of credits stops executions: pages, API routes, scheduled jobs, editor test runs, and anything your agent calls over MCP stop together, because they all draw on the same balance. It's a single event, not a staged one. Reading and editing keep working. What keeps serving:

• Cached pages, until their cache expires.
• Published datafiles and media, which are static files and serve regardless.

How long cached pages last is set by you: a page with a one-hour cache keeps serving for about an hour; a page with caching off (the default) stops immediately. Topping up or upgrading restores everything instantly. Nothing is deleted and nothing is owed: running out of credits is not a payment problem.

Hitting a plan cap. Creating one entity past a per-kind limit gives you a clear message naming the limit and how to lift it, never a silent failure. A run that exceeds your plan's max run length works differently: it isn't refused up front, it runs as far as the limit allows and then times out. The time it used is still counted: a run is metered whether it finishes or times out, and credits are never clawed back. This mostly bites after a downgrade, when a workflow that fit the old, longer limit starts timing out; it's worth re-checking your longer jobs when you move down a tier.

Datafile writes are paced, not refused. Each run gets an allowance of datafile writes. A run that writes past it isn't stopped; the extra writes are slowed down, so a workflow that hammers a datafile in a loop finishes later rather than failing. Batch your writes where you can.

Moving to a smaller plan. When you switch to a plan whose limits are below what you're currently using, nothing is deleted: the excess is set aside rather than removed. Custom domains beyond the new plan's included count keep serving through the end of the period you've already paid for, then stop resolving. Workspace members over the new seat limit lose access to the workspace entirely: the most recently added members are dropped first, and the owner always keeps a seat. Every member holds a seat regardless of role, so there's no read-only fallback; those dropped can't sign in to it at all until a seat frees up. (Using a site you've published is separate and stays unlimited. This only affects who can build in the workspace.) Scheduled jobs beyond the new count, or set to run more often than the new plan's minimum interval, stop or slow to that interval. In every case your definitions and data stay intact and dormant; upgrading again restores them exactly as they were.

#Free tier specifics

Free sites are served from a tessryx.app subdomain. Two things follow from that, both disclosed in the Customer Terms:

• A "Served by Tessryx" badge is shown on your pages.
• Pages are marked noindex, so search engines don't index them.

Both lift the moment you connect a custom domain on a paid plan: indexing follows your own domain, which is a real technical fact rather than an artificial gate.

Run traces. Every workflow run is recorded and listed on every plan: you always see what ran, when, and whether it succeeded. What differs on the free tier is the detailed step-by-step trace: it's kept only for runs you start yourself, like a test run or preview in the editor. For an unattended run (a scheduled job, a live page serve, or an agent calling over MCP), the free tier still lists the run and its outcome, but doesn't store its step trace. Paid plans keep the full trace for every run.

Inactivity. Free accounts with no activity for 90 days (no request at our servers, no workflow or schedule runs, no dashboard sign-in, and no MCP access) are warned by email, then their media is archived and the account removed. Any one of those resets the clock, so an internal tool used daily but never re-published is never reaped. An agent counts: a workspace driven entirely over MCP (no browser sign-in) stays alive on that alone. Cache-served requests don't reach our servers, so they aren't counted; activity is measured at origin. Paid accounts have no inactivity clock.