Skip to main content

Runtime Kit is for surfaces where Bitfield needs to run while the product is being used. A static landing page does not need to ask Bitfield to run just because it lives beside the product.

The billing rule is not “how much runtime.” It is not “every visitor.” It is not “installed somewhere.” The useful question is: does this page or environment ask Bitfield to run?The count comes from signed Bitfield observations for the runtime identity that crossed that line. Today the public pricing label for that is active device. The label can change by policy; the public rule stays the same: no Bitfield request bytes, no runtime/device usage for that visitor.That has a concrete technical meaning:
No envelope bytes, no slot, no native handler, no live-state read means Bitfield did not run for that page view.When Bitfield does run, the count follows the runtime identity that sent the request bytes. For local Bitfield, that identity comes from activation state, not cookies, IP address, browser tabs, or VPNs.
Page

Static copy can stay static. Product behavior may need Runtime Kit.

Runtime

The runtime identity asks Bitfield to run only where the product needs it.

Bill

Traffic reading already-published files does not become runtime usage.

Use Runtime Kit here

That is real Runtime Kit work.

Do not ask Bitfield to run just for this

This is not anti-Bitfield. It is cost-aware Bitfield. Use Runtime Kit where Bitfield needs to run. Keep plain public pages plain.

Start with the symptom

Three shapes

Static public page

Result: visitors do not send Bitfield request bytes.The build machine can still be a Bitfield runtime identity if the build itself asks Bitfield to run. The public visitor reading already-published files does not become one.Technical check:

Hosted Runtime Kit product

Result: the server runtime identity is the counted runtime/device unit. Visitors are not counted separately unless their own device or browser also asks Bitfield to run.Technical check:

Local or downloaded product

Result: each customer runtime identity that sends Bitfield request bytes can consume a runtime/device unit for the billing window.Technical check:

Mixed site example

acme.com can have both public pages and a Runtime Kit product.The path name does not decide billing. Bitfield request bytes do.

Identity examples

What to tell an AI agent

Use this when an AI agent is building a public site around Bitfield:

Launch checklist

Before launch, answer these plainly:
  1. Which devices, servers, or runtime environments will send request bytes to Bitfield?
  2. Which public pages are just static output?
  3. Which product surfaces really need Runtime Kit?
  4. Are any Bitfield keys or activation files exposed to public browser code?
  5. Are old test machines and dead runtime identities revoked in the account portal?
The bill should follow the first answer, not the number of people who read already-published files.Do not copy one device’s local activation folder to another device. Activate the runtime identity properly from the account path.

Verify

The page is wired correctly when you can point to each public URL and answer one question: does opening this URL ask Bitfield to run?Static pages should load without a Bitfield key in public browser code. Runtime Kit product surfaces should use the public Runtime Kit calls and account-owned activation path. The component renders real data only when the named data exists and Bitfield request bytes are actually needed.

Next

Read What you pay for, then use Package to screen when you are ready to build the Runtime Kit part.
Last modified on May 11, 2026