Bitfield billing has two pieces: your plan subscription, and the runtime/device units that get counted when Bitfield is actually asked to run.
That word matters: asked to run. Files sitting on a machine are not the same thing as Bitfield running. A visitor reading static files from a web host is not the same thing as Bitfield running for that visitor. A million clicks on the same already-counted runtime are not a million runtime/device units.The public pricing word you will see is active device. It means a device, server, or runtime identity where Bitfield was asked to run during the billing window.Behind the scenes, Bitfield does not count pages, projects, clicks, or routes. It records signed observations and counts the runtime identity selected by the active pricing policy. Active device is the current public label for that count, not a separate billing path.Plan
Your plan starts after the trial unless you cancel first.
→
Request
A device, server, or runtime environment calls into Bitfield.
→
Count
The count comes from those calls, not from visitors or page labels.
The short version
| Situation | What happens |
|---|---|
| You keep a paid plan after the trial. | The plan subscription bills on its cadence. |
| Bitfield is installed somewhere but never opened or asked to run in the billing window. | That dormant install does not create a runtime/device unit by itself. |
| Bitfield is asked to run once on your laptop this month. | That laptop uses 1 runtime/device unit for the window. |
| The same laptop uses Bitfield 1,000,000 times this month. | Still the same runtime/device unit, not 1,000,000 units. |
| Bitfield is asked to run on laptop, phone, and one server this month. | 3 runtime/device units. |
| 100,000 people view a static public page. | They are only receiving already-published files. Bitfield is not being asked to run for each visitor. |
| A package folder sits in a repo and nobody runs it. | Nothing new is counted. |
What “asked to run” means in code
Asked to run means request bytes entered Bitfield for a real device, server, or runtime environment.When that succeeds, Bitfield remembers that identity for the billing window. The count does not come from route names, page labels, marketing pages, package names, or how many people looked at a page.The exact boundary
This is the line:| Word | Meaning here |
|---|---|
| Envelope | The request Bitfield receives. It has an address and payload bytes. |
| Slot | A Bitfield runtime target that can answer the envelope. |
| Native handler | Built-in Bitfield code that can answer the envelope. |
| Live state | Current Bitfield state read by address. |
| Static files | HTML, CSS, JS, and images already published to a web host. |
How the identity is determined
For a local Bitfield runtime, identity does not come from IP address, cookies, browser tabs, or the person’s name.It comes from activation:Do not mix up these two things
| Thing | Plain meaning |
|---|---|
| Plan subscription | The base plan you chose after the trial. |
| Runtime/device unit | One device, server, or runtime identity where Bitfield was asked to run inside the billing window. |
What counts
| Thing | Counts when |
|---|---|
| Laptop or desktop | Bitfield is asked to run there during the billing window. |
| Phone or tablet | Bitfield is asked to run there during the billing window. |
| Server or worker | Bitfield is asked to run there during the billing window. |
| Local box, kiosk, or test machine | Bitfield is asked to run there during the billing window. |
| Customer device | That customer’s environment asks Bitfield to run. |
What does not count by itself
| Thing | Why |
|---|---|
| Dormant install | Files sitting there are not Bitfield running. |
| Package folder | Product material is not runtime usage. |
| Project | A project is not the billing unit. |
| Static page view | The visitor receives already-published files. Bitfield is not asked to run for that visitor. |
| Website visitor | A visitor is not a runtime identity unless their environment actually asks Bitfield to run. |
| Click count | Pricing is not per click. |
| Runtime duration | Pricing is not per second or per minute. |
| Revenue | Pricing is not a revenue share. |
Identity edge cases
| Scenario | What happens |
|---|---|
| Jane uses the same activated laptop 10,000,000 times in the same billing window. | 1 runtime/device unit. Same activation identity. |
| Jane opens the same local product in Safari, Chrome, and an incognito window on the same machine. | Still 1 runtime/device unit when those browsers talk to the same local Bitfield runtime identity. |
| Jane clears browser cookies, browser cache, or uses private browsing. | That does not change the local Bitfield identity by itself. Browser storage is not the billing identity. |
| Jane turns on a VPN or changes IP address. | Still the same runtime/device unit. IP address is not the billing identity. |
| Jane uses a laptop and a phone. | 2 runtime/device units if both devices send request bytes to Bitfield in the billing window. |
| Jane reinstalls the app but the local Bitfield activation state remains. | Same runtime/device unit. |
| Jane deletes the local activation state and activates again. | That can create a new runtime identity. Revoke old identities you no longer want active. |
| A hosted product serves 100,000 visitors from one activated server. | 1 server runtime/device unit, unless the visitors’ own browsers also send Bitfield request bytes. |
| The same hosted product runs on 10 activated servers. | Up to 10 server runtime/device units for that billing window. |
| A background worker and the web server share the same activation identity. | 1 runtime/device unit. |
| A background worker has its own activation identity. | It can count separately from the web server. |
| CI uses a persistent activated runner. | The runner can count once for the billing window. |
| CI creates a fresh activated runner every run. | Each new activated runtime identity can count. Persist the activation state when you want the same identity. |
| A Docker container or VM keeps the same Bitfield activation state across restarts. | Same runtime/device unit. |
| A Docker container or VM throws away activation state and activates again. | That can create new runtime identities. |
| Someone copies one device’s activation folder to another machine. | Do not do this. It is not the supported way to move a spot; revoke or replace through the account portal. |
| A static page was built with Bitfield, then published as files. | The build identity can count if Bitfield ran during the build. Later visitors only reading the files do not count. |
| A public page directly sends Bitfield request bytes from the visitor’s browser. | That browser/runtime identity can count. |
| A package folder exists in a repo. | Nothing counts until some device, server, or runtime identity sends request bytes to Bitfield. |
Common scenarios
Installed but not used
You installed Bitfield on a laptop months ago. This month you never open it, start it, or ask Bitfield to run.Result: your active plan still follows its subscription cadence, but that dormant laptop does not create a new runtime/device unit by itself.Same machine, heavy use
You ask Bitfield to run on your laptop once, then use the product all month.Result: that laptop is one runtime/device unit for the billing window. It is not per action, per click, or per second.Local app on customer machines
You ship a Bitfield-powered local app to 100 customer machines, and each one asks Bitfield to run in the billing window.Result: those 100 runtime identities are the count.Hosted product
You run a hosted product from one server, and that server asks Bitfield to run.Result: the server runtime identity is what gets counted. Visitors do not become separate runtime/device units just by viewing output from that server.Static public page
You publish a landing page as ordinary static or hosted output.Result: visitors are not counted. They are receiving files the web host already has. Bitfield is not being asked to run for each visitor.More examples
| Scenario | Did request bytes enter Bitfield? | Billing meaning |
|---|---|---|
| Jane visits a static landing page. | No. The web host only returns already-published files. | Jane does not create a runtime/device unit. |
| You used Bitfield during the build to produce the static page. | Yes, for the build machine or build server. No, for later visitors. | The build identity can count. Visitors do not count just by reading the output. |
| A hosted app server calls Bitfield while serving product screens. | Yes, on the server. | The server runtime identity can count. Visitors do not become separate units unless their own browser also calls Bitfield. |
| Jane’s browser directly calls Runtime Kit and sends Bitfield request bytes. | Yes, in Jane’s browser/runtime environment. | Jane’s browser/runtime identity can count for the window. |
| A downloaded desktop app calls Bitfield locally. | Yes, on that customer device. | That customer device can count for the window. |
| A package folder exists but nothing sends request bytes to Bitfield. | No. | Nothing new is counted. |
How to avoid surprise bills
- Use Bitfield where you need Bitfield runtime behavior.
- Keep static marketing pages static when they only need copy, images, links, and forms.
- Do not ask Bitfield to run just to display public text or images.
- Revoke old devices, servers, and test machines that should not be used anymore.
- Do not put a Bitfield key into public browser code.
- Check the account portal before rolling out to a fleet, team, or customer set.
Common failures
| Symptom | Cause | Fix |
|---|---|---|
| Someone thinks a dormant install is charged forever | Install and runtime request got mixed together | Say files sitting there send no Bitfield request bytes |
| Someone thinks every visitor is charged | Static traffic and Bitfield running got mixed together | Say static visitors only receive already-published files |
| Someone thinks heavy use becomes per-click billing | Runtime request count and usage amount got mixed together | Say the same runtime identity is not counted once per click |
| Someone puts a key in public browser code | Public page and runtime identity were not separated | Keep keys in the activation/runtime path, not public page code |