Plans, credit and usage

Operations#

Plans and entitlements#

A plan is free or premium. Entitlements are capabilities that a platform operator enables manually for the organization:

The plan document carries a version that increases with every change of plan or entitlements. A platform operator sends it back as expected_version, so a concurrent change is refused instead of overwritten. Organization members only read it.

The waitlist#

An organization asks for premium by joining the waitlist:

{ "interest": ["diagnostics", "private_apps"], "note": "Internal tools" }

interest accepts diagnostics, private_apps, premium_execution and workspace_development. An organization has one open entry; repeating the request updates it. The entry records the member who asked, and its state is waiting, invited, enabled or declined. Enablement and credit always go to the organization, never to the user.

Internal admission of people#

While the platform's admission policy is closed, management and preparation are open to the people Beyond has admitted, one by one, and to nobody else. Signing in, creating an organization or holding a role admits nobody: a member whose role allows an operation is refused with 403 ADMISSION_REQUIRED (details.policy names the policy) until an operator admits them. Reads of public content, session.read and the two operations below stay open to every signed-in person.

GET /v1/admission answers the caller's own standing — none, waiting, enabled or revoked — and reveals nothing about anyone else. PUT /v1/admission with an optional note adds the caller's person entry to the same waitlist, or updates its note; a person has one entry, repeating the request leaves the same state, and asking again never undoes an operator's decision, a revocation included. Admission is decided in the platform backoffice: it admits that person only, and it grants no role, organization, plan, credit or platform capability. A revocation refuses the person's next management or preparation request; work already queued or running is left to finish, and published content keeps its visibility. Under the open policy nobody is refused for admission alone.

Asking for Workspace development#

workspace_development asks Beyond to enable closed Workspace development for the organization. It travels on this waitlist and it is not a CDN entitlement:

• reviewing or approving such an entry changes no plan, no entitlement and no credit;
• access to Workspace is decided separately, in Beyond Projects, for the organization and for each member Beyond selects. Joining the waitlist enables nothing by itself;
• the organization can still ask for premium with the same entry or a later one.

In CDN administration, the waitlist form has the checkbox Development in Workspace (closed access) under What interests your organization, with the explanation "Asks the Beyond team to enable Workspace development for this organization and the members it selects. It is decided separately and never changes the CDN plan or credit." After such a request is approved, the page says "The Beyond team approved this request without changing the CDN plan: Workspace development is enabled separately, for the organization and for each selected member. You can still ask for Premium below." Only an owner or administrator of the organization can join the waitlist.

This part is Experimental: it is implemented and was run on a local installation, and nothing is hosted.

Credit#

Credit is trial cloud credit that an operator grants to the organization. It is never a per-user balance.

The ledger is append-only. Each entry has a kind (grant, reserve, settle, release), an amount and a unique key, so a retried settlement or grant is recorded once.

amount is always positive. The kind carries the direction: grant and release increase what is available, reserve holds it and settle consumes it. A release reports what returned to the balance, never a charge, and the ledger holds no zero charge. Work is admitted only if the organization's available credit and the platform's global budget can cover the reservation; otherwise the answer is 402 CREDIT_INSUFFICIENT or 503 BUDGET_EXHAUSTED.

Usage#

usage.read takes from, to, category, application, after and limit, and answers totals per category and a page of records. from is the start of the period, inclusive, and to is its end, exclusive, both as UTC instants. Without them the period is the current UTC month up to now.

A record carries ms, bytes, credits, cache_hit and the attempt that was measured. Each total adds hits.

Shared work is measured once#

A compatible shared unit is executed and measured once, and attributed to its first authorized payer. Every other consumer records a cache hit with zero credits. An attempt is unique, so it is never recorded twice, even when the same work is delivered twice to a worker.

The intent of future pricing is actual processing, not the number of modules. That intent is not a tariff.