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:
request bytes enter Bitfield
  -> Bitfield decodes an envelope
  -> the envelope address resolves to a slot, native handler, or live state
  -> Bitfield returns bytes
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

Use Runtime Kit when the surface needs…Why
Named Bitfield dataThe surface needs Bitfield to provide current product data.
Product actionsA button or action asks Bitfield to run something.
Package boundariesProduct material belongs to packages instead of tangled app imports.
Local stateThe product needs Bitfield state on the device or runtime environment.
Offline-capable behaviorThe product should keep useful state close to where it runs.
Replaceable product piecesPackages can change without rewriting every screen.
That is real Runtime Kit work.

​
Do not ask Bitfield to run just for this

Public page needBetter shape
Static headline and body copyStatic or ordinary hosted output.
Marketing imagesStatic image assets.
A pricing page that only explains plansStatic or ordinary hosted output.
A docs pageStatic docs output.
A public blog postStatic or ordinary hosted output.
A button that links somewhereOrdinary link or form behavior.
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

SymptomWhat probably happenedFirst fix
A public page feels like it will create usageRuntime Kit was added to static contentKeep the page static unless the page needs to ask Bitfield to run
Visitors are being discussed like devicesTraffic and runtime identities were mixed togetherAsk which device, server, or environment actually asks Bitfield to run
An AI agent adds Runtime Kit to every pageThe instruction did not separate marketing and product surfacesUse the prompt below before the agent writes code
A test machine keeps showing upOld runtime identity was not cleaned upRevoke old devices and test machines in the account portal

​
Three shapes

​
Static public page

build or export step
  -> HTML/CSS/JS/images
  -> web host serves files
  -> visitors read the 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:
visitor page load
  -> no Bitfield envelope bytes
  -> no resolved slot
  -> no native handler
  -> no live-state read

​
Hosted Runtime Kit product

server asks Bitfield to run
  -> product surface uses Runtime Kit
  -> visitors use the hosted 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:
server request
  -> Bitfield envelope bytes
  -> resolved slot, native handler, or live-state read
  -> server runtime identity can count

​
Local or downloaded product

customer device asks Bitfield to run
  -> Runtime Kit talks to local Bitfield state
  -> product runs on that machine
Result: each customer runtime identity that sends Bitfield request bytes can consume a runtime/device unit for the billing window.Technical check:
customer device action
  -> Bitfield envelope bytes
  -> resolved slot, native handler, or live-state read
  -> customer runtime identity can count

​
Mixed site example

acme.com can have both public pages and a Runtime Kit product.
URLGood shapeBilling meaning
/Static landing pageNo Bitfield envelope bytes per visitor. Visitors do not create runtime usage.
/pricingStatic pricing pageNo Bitfield envelope bytes per visitor. Visitors do not create runtime usage.
/docsStatic docs outputNo Bitfield envelope bytes per visitor. Visitors do not create runtime usage.
/appRuntime Kit product surfaceThe device, server, or environment that sends Bitfield envelope bytes can be counted.
The path name does not decide billing. Bitfield request bytes do.

​
Identity examples

SetupBilling meaning
Same local Runtime Kit product opened in normal browser and incognitoSame local Bitfield runtime identity when both talk to the same local runtime.
Same visitor changes IP address or uses a VPNNo new identity by itself. IP address is not used as the identity.
Same visitor clears cookiesNo new identity by itself when local Bitfield activation state remains.
Product runs from one activated cloud serverThe server identity can count once for the billing window.
Product runs from multiple activated serversEach activated server identity can count.
Product runs in a throwaway container that activates from scratch every launchEach new activation can create a new runtime identity.
Product runs in a container with persisted Bitfield activation stateSame runtime identity across restarts.
Public page is static but the build step used BitfieldThe build identity can count; visitors reading the exported files do not.

​
What to tell an AI agent

Use this when an AI agent is building a public site around Bitfield:
Build public marketing pages as static or ordinary hosted output unless the page needs to ask Bitfield to run.
Use Runtime Kit only for surfaces that need current Bitfield data, product actions, local Bitfield state, package runtime behavior, or offline-capable product behavior.
Never put a Bitfield key into public browser code.
Do not ask Bitfield to run just to render static copy, images, links, or a brochure page.

​
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