diff --git a/docs.json b/docs.json index 60e88ff..0dec9f8 100644 --- a/docs.json +++ b/docs.json @@ -274,6 +274,7 @@ "browsers/faq", "info/concepts", "info/pricing", + "info/spending-caps", "info/support", "info/unikernels", "info/zero-data-retention" diff --git a/info/pricing.mdx b/info/pricing.mdx index 7ee71cd..33db41e 100644 --- a/info/pricing.mdx +++ b/info/pricing.mdx @@ -4,6 +4,8 @@ title: "Pricing & Limits" With Kernel, you only pay for what you use and nothing more. You don't pay for idle time thanks to [Standby Mode](/browsers/standby), idle browsers in a browser pool incur no usage charges, and you're never charged for proxies. +Use [Spending Caps](/info/spending-caps) to warn at 80% of a monthly usage limit and pause new browser sessions and app invocations at 100%. You can set one cap across your organization or isolate individual workloads with project caps. + ## Pricing | Browser type | Price ($/sec) | diff --git a/info/projects.mdx b/info/projects.mdx index 46f9b85..22b61ac 100644 --- a/info/projects.mdx +++ b/info/projects.mdx @@ -317,6 +317,8 @@ A project's effective cap resolves in this order: A per-project cap never lets a project exceed your organization's concurrency limit. +Concurrency limits control how many browsers can run at once. To control monthly usage cost instead, see [Spending Caps](/info/spending-caps). + | Method | Path | Description | | --- | --- | --- | | `GET` | `/org/limits` | Get the org concurrency limit and the default per-project cap | diff --git a/info/spending-caps.mdx b/info/spending-caps.mdx new file mode 100644 index 0000000..89a3550 --- /dev/null +++ b/info/spending-caps.mdx @@ -0,0 +1,172 @@ +--- +title: "Spending Caps" +description: "Choose a monthly spending guardrail for your organization, a project, or both" +--- + +A retry loop, traffic spike, or long-running agent can raise usage faster than you expect. Spending caps warn you before that usage reaches the amount you choose, then pause new work for the affected scope. + +If you only set one cap, start with an organization cap. It protects the total bill. Add project caps when a team, environment, customer, or experiment needs a tighter boundary. + +## Which cap should you use? + + + + + + +Use both for a multi-project production setup: one organization cap for the total bill, plus lower project caps where a single workload needs tighter control. + +Subscription fees don't count toward either cap. Spending caps apply to usage charges. + +## Set a cap + + + + Go to the [KERNEL billing page](https://dashboard.onkernel.com/billing) as an organization admin. + + + In **Spending Cap**, select **Organization** or **Project**. For a project cap, select the project you want to control. + + + Enter the usage amount in usd and save. The card shows month-to-date progress against the limit. + + + + + Availability varies by scope: + + - **Organization caps:** Available to eligible self-serve organizations. Enterprise access is in limited preview. + - **Project caps:** In limited preview for all organizations. + + [Email support@kernel.sh](mailto:support@kernel.sh?subject=Spending%20cap%20preview%20access) to request preview access. + + + + Set an organization spending cap or manage the project caps available to your organization. + + +## What happens during the month + + + + KERNEL evaluates each cap from the first day of the month at 00:00 utc. Organization and project usage accumulate independently. + + + KERNEL sends a warning email. Existing and new work continue. + + + New browser sessions and app invocations return a `403` for the affected scope. Running work continues until it ends. + + + New work resumes when the next monthly period starts. An organization admin can also increase or remove the cap at any time. + + + + + A spending cap is an admission guardrail, not a transactional hard ceiling. Billing events take time to evaluate, and already-running work can continue adding usage after the threshold is reached. Leave headroom below any budget that must not be exceeded. + + +## How spend is counted + + + + An organization cap measures usage after KERNEL applies your included monthly credits: + + ```text + out-of-pocket usage = gross usage - included monthly credits + ``` + + For example, an organization with \$50 in monthly usage credits sets a \$100 cap: + + - KERNEL sends the 80% warning at \$130 in gross usage: \$50 in credits plus \$80 in out-of-pocket usage. + - KERNEL pauses new usage at \$150 in gross usage: \$50 in credits plus the \$100 cap. + - The plan's subscription fee remains separate. + + Choose this cap when your main requirement is a predictable maximum for monthly usage charges, regardless of which project creates the spend. + + + A project cap measures that project's gross usage. Organization credits aren't divided or assigned to individual projects. + + For example, a \$25 project cap warns at \$20 and pauses new usage for that project at \$25. Other projects continue until they reach their own caps or the organization cap. + + Requests without an explicit project resolve to your [default project](/info/projects#the-default-project) and count toward that project's cap. + + Choose this cap when one workload must not consume an open-ended share of the organization's budget. + + + +## Layer organization and project caps + +Organization and project caps are independent. KERNEL doesn't allocate the organization cap among projects, and project caps don't have to add up to it. + + + + KERNEL pauses new work for that project. Other projects continue. + + + KERNEL pauses new work across every project, even if individual project caps have room left. + + + The organization cap takes precedence because it applies to the full organization. + + + +If a project cap is higher than the organization cap plus monthly credits, the organization cap can trigger first. The dashboard warns you about this configuration but still lets you save it because later changes to credits or either cap can change which threshold comes first. + +## Common setups + +| Your setup | Recommended caps | +| --- | --- | +| One production workload | Start with an organization cap above normal monthly usage. | +| Production plus staging or experiments | Use an organization cap, then lower project caps for non-production work. | +| Multiple teams | Use an organization cap, then project caps to isolate each team's usage. | +| Customer-specific workloads | Put each customer in a [project](/info/projects), cap each project, and keep an organization cap as the final boundary. | + +## Operational details + + + Already-running browser sessions and app invocations continue until they end. Read and delete requests remain available, along with selected non-billable administrative operations such as managing projects, limits, and api keys. + + Browser pools can maintain idle capacity, but you can't acquire a new browser for a capped scope. + + + + The scope can enter the reached state as soon as billing data finishes evaluating. Raise or remove the cap if you need to resume new work before the next monthly period. + + + + Organization members can view cap status. Only organization admins can set, edit, or remove caps. + + + + Spending caps bound monthly usage cost. [Concurrency limits](/info/pricing#concurrency-limits) bound simultaneous browser capacity. A spending cap doesn't reserve throughput, and a concurrency limit doesn't bound monthly spend. +