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: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
Hosted Runtime Kit product
Local or downloaded product
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:- Which devices, servers, or runtime environments will send request bytes to Bitfield?
- Which public pages are just static output?
- Which product surfaces really need Runtime Kit?
- Are any Bitfield keys or activation files exposed to public browser code?
- Are old test machines and dead runtime identities revoked in the account portal?