> ## Documentation Index > Fetch the complete documentation index at: https://docs.bitfield.so/llms.txt > Use this file to discover all available pages before exploring further. # Use Runtime Kit where it should run > How to use Runtime Kit without accidentally sending Bitfield request bytes from public pages.

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: ```text theme={null} 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 Decide what it needs

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

→
Runtime Run only where needed

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

→
Bill Count runtime identities

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

## Use Runtime Kit here | Use Runtime Kit when the surface needs... | Why | | ----------------------------------------- | ---------------------------------------------------------------------- | | Named Bitfield data | The surface needs Bitfield to provide current product data. | | Product actions | A button or action asks Bitfield to run something. | | Package boundaries | Product material belongs to packages instead of tangled app imports. | | Local state | The product needs Bitfield state on the device or runtime environment. | | Offline-capable behavior | The product should keep useful state close to where it runs. | | Replaceable product pieces | Packages can change without rewriting every screen. | That is real Runtime Kit work. ## Do not ask Bitfield to run just for this | Public page need | Better shape | | --------------------------------------- | --------------------------------- | | Static headline and body copy | Static or ordinary hosted output. | | Marketing images | Static image assets. | | A pricing page that only explains plans | Static or ordinary hosted output. | | A docs page | Static docs output. | | A public blog post | Static or ordinary hosted output. | | A button that links somewhere | Ordinary 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 | Symptom | What probably happened | First fix | | --------------------------------------------- | --------------------------------------------------------------- | ---------------------------------------------------------------------- | | A public page feels like it will create usage | Runtime Kit was added to static content | Keep the page static unless the page needs to ask Bitfield to run | | Visitors are being discussed like devices | Traffic and runtime identities were mixed together | Ask which device, server, or environment actually asks Bitfield to run | | An AI agent adds Runtime Kit to every page | The instruction did not separate marketing and product surfaces | Use the prompt below before the agent writes code | | A test machine keeps showing up | Old runtime identity was not cleaned up | Revoke old devices and test machines in the account portal | ## Three shapes ### Static public page ```text theme={null} 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: ```text theme={null} visitor page load -> no Bitfield envelope bytes -> no resolved slot -> no native handler -> no live-state read ``` ### Hosted Runtime Kit product ```text theme={null} 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: ```text theme={null} server request -> Bitfield envelope bytes -> resolved slot, native handler, or live-state read -> server runtime identity can count ``` ### Local or downloaded product ```text theme={null} 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: ```text theme={null} 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. | URL | Good shape | Billing meaning | | ---------- | --------------------------- | ------------------------------------------------------------------------------------- | | `/` | Static landing page | No Bitfield envelope bytes per visitor. Visitors do not create runtime usage. | | `/pricing` | Static pricing page | No Bitfield envelope bytes per visitor. Visitors do not create runtime usage. | | `/docs` | Static docs output | No Bitfield envelope bytes per visitor. Visitors do not create runtime usage. | | `/app` | Runtime Kit product surface | The 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 | Setup | Billing meaning | | ------------------------------------------------------------------------------ | ------------------------------------------------------------------------------ | | Same local Runtime Kit product opened in normal browser and incognito | Same local Bitfield runtime identity when both talk to the same local runtime. | | Same visitor changes IP address or uses a VPN | No new identity by itself. IP address is not used as the identity. | | Same visitor clears cookies | No new identity by itself when local Bitfield activation state remains. | | Product runs from one activated cloud server | The server identity can count once for the billing window. | | Product runs from multiple activated servers | Each activated server identity can count. | | Product runs in a throwaway container that activates from scratch every launch | Each new activation can create a new runtime identity. | | Product runs in a container with persisted Bitfield activation state | Same runtime identity across restarts. | | Public page is static but the build step used Bitfield | The 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: ```text theme={null} 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](/activation/what-you-pay-for), then use [Package to screen](/runtime-kit/package-to-screen) when you are ready to build the Runtime Kit part.