Plans, entitlements, and quotas
The five commercial plans, the capabilities each one turns on, and the quotas the platform enforces. The licensing reference behind what your workspace can do and how much.
A plan sets two things: the entitlements it turns on, which are the capabilities your workspace can use, and the quotas it carries, which are the limits the platform enforces. This page is the reference for both. It lists the five plans and what each includes, the full catalog of entitlements with what each one turns on, and every quota with how it is read and where it is enforced. When you are choosing a plan, confirming whether a capability is included, or explaining a limit a team just hit, this is where you check.
The how-to of viewing your plan and usage lives on plans and usage and usage metering and quotas. This page is the flat reference those pages point back to. Your plan and the limits it sets are read-only in the product: you see them on the Plan and Usage page, and you change them by talking to the platform team, not by editing a field.
The five plans
| Plan | Price | For | Headline limits |
|---|---|---|---|
| Free | Free | Individuals evaluating the platform | 1 project, 5 flow runs a day, 2 compute hours a day |
| Team | $25 per seat per month | Small teams | 3 projects, 20 flow runs a day, 5 compute hours a day |
| Business | $59 per seat per month | Engineering organizations | Unlimited projects and flow runs, 20 compute hours a day pooled |
| Enterprise | From $119 per seat per month | Larger organizations, 25 seats and up | Everything uncapped, compute set by contract |
| 14-day Pilot | Free for 14 days | A team running a self-serve trial | The same limits as Team |
The four tiers build on one another, each adding capabilities and lifting limits. The Pilot sits beside them, a time-boxed run on Team's terms.
Free is for one person trying the platform out. It runs flows and sandboxes inside bounded limits and carries community support.
Team adds the capabilities a small team works with: bringing your own model key, attaching documents from Google Drive and OneDrive, and the audit history. It is the first paid tier, priced per seat.
Business is the tier built for an engineering organization. It lifts the project and flow-run limits, and it turns on the capabilities an engineering organization runs on day to day: GitHub Enterprise, bring-your-own sandbox hosts, custom MCP tools, tenant-authored skills, email and Microsoft Teams notifications, and domain auto-join.
Enterprise is for larger organizations and starts at twenty-five seats. It carries everything Business has and adds audit export, a tenant-scoped Key Vault, model routing across providers, and the contract terms a procurement team needs. Its compute is set by the contract rather than a fixed daily cap.
The 14-day Pilot is a time-boxed trial that mirrors Team's capabilities and limits, so a team can run the platform on real work for two weeks. It is arranged with the platform team rather than started from a button in the product.
What each plan turns on
An entitlement is one named capability a plan turns on. The table below is the full catalog, grouped by what it does for you. The status column is honest about where each one stands: an active entitlement works today; a partial one works in part; a roadmap one is a capability a tier is built toward and is not live yet; and a label is a display name for a support level or a limit rather than a capability of its own, with the real number in the quota tables below.
Several entitlements are display labels for a limit rather than a capability of their own. The real project limit is the projects.count quota below, not the "limited projects" label, and the real compute limit is the compute quota, not the "shared compute" label. Those are marked as labels so you read the quota for the real number. In the Plans column, a roadmap capability that is tied to a tier names that tier; one that reads "not yet tiered" is on the roadmap with its plan placement set when it ships.
Models and code
| Capability | What it turns on | Status | Plans |
|---|---|---|---|
| Bring your own model key | Use your own Anthropic or OpenAI key | Active | Team and up |
| Model routing across providers | Choose the model per project, skill, or environment | Partial | Enterprise |
| Azure OpenAI as a provider | Use a tenant-owned Azure OpenAI deployment | Roadmap | Business and up |
| AWS Bedrock as a provider | Use a tenant-owned Bedrock deployment | Roadmap | Not yet tiered |
| GitHub Enterprise | Use GitHub Enterprise Managed Users as a provider | Active | Business and up |
| Bring your own GitHub App | Register your own GitHub App | Roadmap | Not yet tiered |
Work and automation
| Capability | What it turns on | Status | Plans |
|---|---|---|---|
| Flows | Named, multi-step flows with checkpoints, resume, retry | Active | All plans |
| Custom MCP tools | Connect your own MCP servers | Active | Business and up |
| Tenant skills | Author your own skills and bind them to statuses | Active | Business and up |
| Document attachments | Attach Drive and OneDrive files to work | Active | Team and up |
| Skills marketplace | Share skills across workspaces | Roadmap | Not yet tiered |
| Dependency engine | A cross-record dependency graph with suggested edges | Roadmap | Not yet tiered |
Hosting and security
| Capability | What it turns on | Status | Plans |
|---|---|---|---|
| Bring your own host | Register your own Kubernetes sandbox hosts | Active | Business and up |
| Tenant Key Vault | A tenant-scoped Azure Key Vault for secrets | Partial | Enterprise |
| Audit history | Read the audit log and version history | Active | Team and up |
| Audit export | Export the audit log to a SIEM | Active | Enterprise |
| Domain auto-join | Verified domains place new users into the workspace | Active | Business and up |
| Single sign-on (SAML or OIDC) | A tenant SAML or OIDC identity provider for sign-in | Roadmap | Business and up |
| SCIM provisioning | IdP-driven user lifecycle | Roadmap | Enterprise |
| IP allowlist | Restrict workspace access to corporate IP ranges | Roadmap | Enterprise |
Notifications and support
| Capability | What it turns on | Status | Plans |
|---|---|---|---|
| Email notifications | The email notification channel | Active | Business and up |
| Microsoft Teams notifications | The Teams notification channel | Active | Business and up |
| Community support | Community support | Label | Free and Team |
| Business-hours support | Business-hours support with a one-day response | Label | Business |
| 24x7 support | A 24x7 service level and a dedicated contact | Label | Enterprise |
| IP indemnification | Contract IP indemnification and security review support | Label | Enterprise |
A roadmap capability is documented as a plan line item, not a working setup flow. Single sign-on is built toward the Business tier, and SCIM and the IP allowlist toward Enterprise; until they ship, sign-in is through Microsoft Entra and Google, with multi-factor handled at your identity provider.
Quotas
A quota is a numeric limit the platform enforces. Reading one is governed by a single rule worth settling first.
A missing cap means uncapped. If your plan sets no cap on a quota, that action is unlimited. A cap of zero means turned off. A quota set to zero disables the action it gates. So a blank in the table below is not an oversight; it is the uncapped value, and a reader confirming a limit should treat absent and zero as two different answers.
Quotas are set by your plan and applied by the platform. You cannot edit them in the product; a workspace with no plan record on file runs fully uncapped by default, and an expired or canceled plan zeros the seat count until it is renewed.
The quota catalog
| Quota | What it limits | How it is enforced |
|---|---|---|
| Seats | Active members in the workspace | Checked when a member becomes active. The cap is the number of seats you purchased. |
| Projects | Active projects | Checked when you create or restore a project. |
| Flow templates | Flow templates your team has created or customized | Checked when you create or customize a template. Built-in templates do not count. |
| Flow runs a day | Flow runs started in a day | Checked when a run starts, and the count resets at midnight UTC. |
| Initiatives | Active initiatives | Checked when you create an initiative. |
| Plans | Active plans | Checked when you create a plan. |
| Compute hours a day | Sandbox compute used in a day | Checked when a sandbox starts, holding a short reservation so a run cannot begin if it would push the day over the cap. |
The catalog above is what each quota limits and where it is checked. The table below is the actual cap each plan sets on it.
| Quota | Free | Team | Business | Enterprise |
|---|---|---|---|---|
| Seats | Seats you purchase | Seats you purchase | Seats you purchase | Seats you purchase, 25 minimum |
| Projects | 1 | 3 | Uncapped | Uncapped |
| Flow templates | 1 | 3 | 10 | Uncapped |
| Flow runs a day | 5 | 20 | Uncapped | Uncapped |
| Initiatives | 3 | Uncapped | Uncapped | Uncapped |
| Plans | 5 | Uncapped | Uncapped | Uncapped |
| Compute hours a day | 2 per seat | 5 per seat | 20 pooled | Set by contract |
The Pilot carries Team's caps. A workspace with no plan on file is uncapped on every row.
One limit, looked up. A team on the Team plan finds a flow refusing to start late in the day. The quota catalog says flow runs a day is checked when a run starts and resets at midnight UTC; the per-plan table says Team caps it at twenty and Business lifts it to uncapped. So the answer is not a bug, it is the twentieth run of the day, and the fix is either tomorrow's reset or a move to Business. Two tables, one question settled.
Compute, metered and pooled
Sandbox compute is the one quota measured in hours rather than a count, and a few details are worth knowing. Only managed compute is metered. Sandboxes running on the platform's managed hosts count against the cap; sandboxes on a host you brought run on your own compute and are not metered at all. The cap is pooled across your seats, so a daily cap of five hours per seat on a ten-seat workspace is fifty hours a day across the team, not five per person. The Plan and Usage page shows where you stand with a status: OK, near the limit, at the limit, over the limit, uncapped, or unavailable when there is nothing yet to measure.
AI spend
Two usage rows always appear on the Plan and Usage page, whatever your plan: your monthly AI spend in dollars, and your unpriced AI usage, the model usage that does not yet carry a price. They appear even before there is anything to show, as a placeholder, so the number is never missing when you go looking for it. Recording this usage is governed by an AI-spend-tracking setting that is on by default; turning it off stops the recording, not the display.
What you see, and what you change
The customer surface for all of this is the Plan and Usage page, at Settings. It shows your plan, the quotas in force with how much you have used, and the capabilities your plan includes, and it is read-only. You do not edit caps or entitlements there; the plan you are on, and any change to it, is set with the platform team.
There is no self-serve upgrade button in the product. When you need more, the one control on the page is Request capacity, a form that reaches the team that arranges plans. The Pilot is arranged the same way rather than started from a button.
Why plans work this way
A plan is two lists kept deliberately apart: the entitlements it turns on and the quotas it enforces. That split is what keeps the model honest. An entitlement is a yes or no: your plan either turns on custom MCP tools or it does not. A quota is a number: your plan lets you run so many flows a day, or as many as you like. Keeping the two apart means a plan is described by a short list of capabilities and a short list of numbers, both of which the platform actually reads, rather than a marketing sheet that says one thing while the product does another. When this page tells you Business turns on bring-your-own hosts and caps flow templates at ten, those are the exact values the license carries.
That same honesty is why this page marks a roadmap capability as roadmap. A plan is a promise, and the promise is worth more when it distinguishes what works today from what a tier is built toward. Single sign-on is on the Enterprise roadmap; it is not a setup flow you can complete today, and saying so plainly is what lets the rest of the list be trusted.
For an administrator, this is the page behind a plan decision and a quota conversation. When a team hits a limit, the quota catalog says what was capped and the per-plan table says which plan lifts it.
For a power user, the entitlement catalog explains why a capability is or is not available to you. A control your workspace does not have is usually an entitlement a higher plan turns on, and this page names which.
For an enterprise reviewer, the value is that the plan is made of enforceable pieces. Every quota here is checked in the running product, and every entitlement's status is stated plainly, so a procurement question has a precise answer rather than a brochure one.
For a prospect, the takeaway is the shape of the offering: a free tier to evaluate, two paid tiers that scale with a team, an enterprise tier for the controls a larger organization needs, and a pilot to try it all on real work first.