Plans and usage

Every Disco Parrot workspace runs on a plan, and the plan decides two things: the capabilities the workspace can reach, and the limits on the countable parts of it. A higher tier turns on more of the platform, email and Teams notifications, bring-your-own sandbox hosting, audit export, and raises the caps on projects, flow runs, and sandbox compute. You manage all of it from one place, Settings → Plan and Usage, where the current tier, what it includes, and how much of it you are using sit on a single page.

This page is about that model: the ladder of plans and what each one is for, the Plan and Usage page itself, the 14-day pilot, the way to ask for more capacity, and the default tier a workspace runs on before any plan is set. The companion page, usage metering and quotas, goes deep on the limits themselves and how they are measured, and the plans, entitlements, and quotas reference is the flat catalog of every plan, capability, and cap.

The plan ladder

Disco Parrot offers four standing plans and a time-boxed pilot, each a superset of the one below it.

• Free is the starting point: the platform's core, agents, flows, planning, and shared sandbox compute, at modest caps. It is enough to run a real project and see how the work model fits your team.
• Team adds the things a working team reaches for first: bringing your own model-provider key, attaching documents from Google Drive and OneDrive, and reading the audit log and version history. The caps rise with it.
• Business is the tier most growing organizations land on. It turns on the capabilities a department runs on: GitHub Enterprise, bring-your-own sandbox hosting, custom MCP servers, skill templates, domain auto-join, and email and Microsoft Teams notifications. Most of its caps become uncapped.
• Enterprise is for organizations that need the platform to meet them where their security and procurement live: model selection across providers, audit export, a tenant-scoped Key Vault, a 24x7 support commitment, and IP indemnification. It carries a 25-seat minimum, and its sandbox compute is set by contract.

The 14-day pilot sits alongside the ladder rather than on it. It gives a workspace Team-level capabilities for two weeks so a team can evaluate the platform with real work before deciding where to land, with the trial end date in plain view on the Plan and Usage page the whole time. A pilot is a real, time-boxed grant rather than a teaser: the capabilities work exactly as they would on the paid tier while it runs, and when it ends the workspace returns to its prior footing until a plan is set. It is arranged through the platform team as part of getting started rather than flipped on from a button, so a conversation, not a credit card, opens it.

Which capability belongs to which tier is the subject of the what's supported today matrix; this page is about how the plan itself works once you are on one.

Which plan fits

The tiers are a superset chain, so the question is less "which features" than "how far up does my team's shape reach." Four readings cover most teams.

A team trying the work model starts on Free. The core platform, agents, flows, and planning all run, at caps sized for a real first project rather than a toy one. You learn whether the model fits before any plan conversation, and the 14-day pilot is there when you want to try the fuller capabilities on the same work.

A working team that has decided to stay lands on Team. The tells are wanting your own model-provider key, pulling documents in from Google Drive or OneDrive, and reading the audit log and version history. The caps rise to match a team that is now running real sprints rather than evaluating.

A department standardizing on the platform is the Business case, and most growing organizations land here. The tells are GitHub Enterprise, running sandboxes on your own hosting, custom MCP servers, domain auto-join, and email or Teams notifications reaching the team. Most caps go uncapped at this tier, and sandbox compute pools across the team instead of metering per seat.

An organization with security and procurement to satisfy is Enterprise: model selection across providers, audit export, a tenant-scoped Key Vault, a 24x7 support commitment, and IP indemnification, with a 25-seat minimum and sandbox compute set by contract. The reading here is less about a cap you outgrew and more about terms your organization needs in writing.

Capability by capability, the what's supported today matrix is the full map; this is the shape that tells you roughly where on it to start.

The Plan and Usage page

Everything about your plan lives at Settings → Plan and Usage. The page opens under that heading with the line Workspace plan, enforced quotas, and included capabilities, and it is built in four parts that answer four questions.

A plan summary at the top says where the workspace stands: its tier, a status badge (a default tier, a trial, an active plan, or an expired one), the number of purchased seats, the trial end date when one applies, and when the record was last updated. A Usage panel, Runtime-enforced limits for this workspace, shows each cap and how much of it is consumed, the subject of the usage and quotas page. A Capabilities panel, What the current plan enables for this workspace, lists what the tier turns on. And a Request capacity panel is where you ask for more, covered below.

You reach the page from the Plan and Usage entry in the Settings rail, and also from the workspace's own settings, where a Plan and Usage section carries a shortcut to it.

Seats

A seat is the right for one person to be an active member of the workspace. The plan summary shows seats purchased, the number the plan provides, and the Usage panel shows active members against that figure, so the two read together: how many seats you bought, and how many are filled. The gap between them is your room to grow, and a seat frees the moment a member is removed, so the count tracks the team rather than a high-water mark.

Seats are the limit a team feels first as it grows, which is why they sit at the top of the plan summary rather than buried in the usage rows. When the active-member count reaches purchased seats, the next person to join waits for a seat to open, the same clean stop every quota uses, covered on the usage and quotas page. The Enterprise tier carries a 25-seat minimum, the one place the floor is set rather than the ceiling, because the tier is shaped for organizations buying for a department or a company rather than a single team. How a seat is counted as members come and go is the subject of members and invitations.

Tracking AI spend

Alongside the shortcut to the page sits an AI spend tracking switch, the one control on this subject. With it on, the workspace records what its AI usage costs, and the month's running total shows in the Usage panel beside the quota rows, so the cost of the work sits in the same place as the limits that bound it. The figure is the workspace's own model usage costed for the calendar month, a running month-to-date total that rolls over at the start of each month, so it reads as a single number you can watch climb and reconcile at month's end. The switch is on by default; turning it off and saving is a workspace updater's call, and it governs whether new usage is recorded, not whether the figure is shown. How that figure reads against the rest of the usage is the subject of the usage metering and quotas page.

What your plan includes

The Capabilities panel is the live list of what the current tier turns on. Each item is a capability the platform gates on the plan: a check beside Email notifications means the workspace can deliver them, a check beside BYO sandbox hosting means it can register its own Kubernetes or Docker host. The panel lists what your tier includes, the implemented capabilities the plan grants, so a capability you are looking for and do not find is one that sits at a higher tier. The absence is the answer: present means on, not in the list means a plan change away.

This is why a feature that needs a higher tier does not fail quietly when you reach for it. The capability is gated at the plan, the Capabilities panel shows what your tier includes, and the path to turning on something that is not there is a plan change rather than a setting. For the full picture of which capability sits at which tier, the what's supported today matrix is the reference; the Capabilities panel is the same view, scoped to your workspace.

Sarah Chen wants to attach a design doc from Google Drive to an initiative and finds the option is not lit. Rather than guess, she opens Plan and Usage and scans the Capabilities panel; document attachments are not among the checks, so she knows the capability is real but sits a tier up, not a setting she missed. The matrix confirms it lands on Team, and the fix is a plan change. One look told her where the capability lived and what it would take to turn it on.

Asking for more capacity

When a workspace needs a tier it is not on, the move is to ask for it, and the Request capacity panel is where you do that. A short form, your name and email, sends the request, and the button on it fits where you stand: it reads Upgrade to Team on Free, Request upgrade on Team, Contact sales for Enterprise on Business, and Contact account team on Enterprise, so the ask is always the natural next one for your tier. Submitting it files a sales request and returns a confirmation with a reference number. The request records your interest and routes it to the team that can act on it; it does not change the plan on its own, so nothing about your workspace shifts the moment you send it.

The deliberate shape here is that a workspace does not raise its own ceiling. Changing a plan is a decision with a commercial side, so the workspace's lever is to request the change and the platform team applies it. What you keep entirely in your own hands is the visibility, the tier, the capabilities, the usage, and the request, all on the page in front of you. The 14-day pilot is the same shape pointed at evaluation: a grant the platform team arranges so a team can try the fuller capabilities on real work before committing.

Marcus Reed runs a pilot before taking Disco Parrot to procurement. For two weeks his team works the Insights project on Team-level capabilities, real flows, real sandboxes, their own provider key, with the trial end date in plain view on the Plan and Usage page the whole time. When the pilot ends he is not deciding from a demo; he is deciding from two weeks of his own team's work, and the Request capacity form is one short note to start the plan.

The permissive default tier

A brand-new workspace runs on no license record at all, and that default tier is permissive on purpose: everything is allowed and nothing is capped, so a team can start working the moment they sign in without waiting on a plan to be provisioned. The permissive default holds only while there is no record at all. The first time a license record is set for the workspace, by the platform team applying a plan, the workspace moves onto that plan, its capabilities and caps take effect, and from then on the workspace is governed by what the plan grants rather than by the open default.

Maya Rodriguez signs in to a brand-new workspace and starts building the Insights project the same minute, no plan to wait on, nothing capped. A week in, the team wants their own model-provider key and a look at the audit log, both of which sit at Team. She opens Plan and Usage, sees the Default badge on the summary and every quota reading Uncapped, and files a Request capacity note. When the platform team applies the Team plan, the badge turns to Active, the caps take effect, and the week of work she already did is exactly where she left it.

A plan's lifecycle

Once a plan is in place it moves through a small set of states, shown as the status badge on the Plan and Usage page.

The two ends of that table are worth keeping apart. The default tier is the open one, no record, everything allowed. An inactive plan, one that has expired, been canceled, or lapsed from a pilot, is a record that has set its capabilities aside and its seat count to zero, a stricter footing than the open default rather than a return to it. Either way the line is the same: a plan governs what a workspace can reach, never what it has already built. A pilot that lapses or a plan that expires leaves every project, plan, and sandbox exactly where it was, ready for the day a plan turns the fuller capabilities back on.

Who can see the plan, and who can ask

Reading the plan is open to the people who help run the workspace, and asking for a change is held a little tighter.

Seeing the Plan and Usage page takes the licensing.read scope, which the administrators who run roles and permissions hold. The Request capacity form appears for the people who can speak for the workspace's needs: anyone who can manage members, update the workspace, or who holds the dedicated Billing Manager role, the role shaped for exactly this, licensing and usage without the rest of administration. Setting the caps and entitlements themselves is the platform team's job, applied to your workspace when a plan is set or changed, so the page you manage is a clear window onto the plan rather than a console for editing it.

Why plans work this way

The plan model follows from one idea: a workspace should be able to start instantly and grow deliberately. The permissive default is the first half of that, a team works from the first minute, with nothing to provision before they can create a project or start a flow. The plan ladder is the second half, capacity and capability arrive as a decision, made once, that the platform applies to the workspace, rather than as a pile of switches each person could flip.

Keeping the plan readable but not self-editable is the quiet choice underneath. The Plan and Usage page shows everything, the tier, what it enables, what is in use, the trial clock, so anyone running the workspace has the full picture. Changing the plan is a commercial act, so it routes through a request the platform team fulfills. The split gives a workspace complete visibility into its own footing and a clear, single path to change it, without turning a billing decision into a setting a stray click could move.

For a team lead, the Plan and Usage page is where you see whether your tier is keeping up with the work. When a cap starts to bite or a capability you need sits one tier up, the Request capacity form is one short note to the people who can lift it.

For an administrator, it is the one window onto the workspace's commercial footing: the tier, its status, the seats, the capabilities it turns on, and the usage against every cap, without having to assemble the picture from a dozen places.

For someone evaluating Disco Parrot, the 14-day pilot is a real two weeks of Team-level capability against your own work, not a sandbox demo. You build something that matters, see how the model fits, and decide from evidence.

For a Billing Manager, the role exists so the commercial side of the workspace has an owner who does not also need the keys to everything else. You see the plan and usage and you carry the request, and that is the whole of what the seat is for.