Bitfield Docs

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.

So the charging model is not “installed forever.” It is not “runtime seconds.” It is not “visitors.” It is Bitfield being asked to run, counted by runtime identity during the billing window.

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:

request bytes enter Bitfield
  -> Bitfield decodes an envelope
  -> the envelope address resolves to a slot, native handler, or live state
  -> Bitfield returns bytes

That is Bitfield running.Static web hosting is different:

visitor requests page
  -> web host returns HTML/CSS/JS/images it already has
  -> no request bytes enter Bitfield

That is not Bitfield running for the visitor.Plain names:

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:

this runtime has local device key material
  -> Bitfield derives a device public key hash
  -> activation uses an activation ID
  -> by default, that activation ID is the device public key hash
  -> billing counts that activation/runtime identity for the billing window

That is why repeat use does not multiply the count. Once Jane’s laptop identity has counted for the billing window, Jane can use it again and again in that same window without creating a second laptop identity.For custom or hosted setups, the same rule still applies: the runtime identity must be stable. A server, worker, browser runtime, kiosk, or customer device needs a stable activation/runtime identity so Bitfield can count the identity once instead of guessing from traffic.

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.

If you keep a paid plan, the plan subscription still exists. The request-byte rule explains what consumes the included runtime/device units and what does not.

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.

The plain test is: did this runtime identity actually ask Bitfield to run during this billing window?

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

Manage account access and runtime identities from account.bitfield.so.

Read Trials and billing for plan cadence, Active devices for the public term, and Use Runtime Kit where it should run for build guidance.

Build a product

Activation

What you pay for

The short version

What “asked to run” means in code

The exact boundary

How the identity is determined

Do not mix up these two things

What counts

What does not count by itself

Identity edge cases

Common scenarios

Installed but not used

Same machine, heavy use

Local app on customer machines

Hosted product

Static public page

More examples

How to avoid surprise bills

Common failures

Next

​The short version

​What “asked to run” means in code

​The exact boundary

​How the identity is determined

​Do not mix up these two things

​What counts

​What does not count by itself

​Identity edge cases

​Common scenarios

​Installed but not used

​Same machine, heavy use

​Local app on customer machines

​Hosted product

​Static public page

​More examples

​How to avoid surprise bills

​Common failures

​Next

The short version

What “asked to run” means in code

The exact boundary

How the identity is determined

Do not mix up these two things

What counts

What does not count by itself

Identity edge cases

Common scenarios

Installed but not used

Same machine, heavy use

Local app on customer machines

Hosted product

Static public page

More examples

How to avoid surprise bills

Common failures

Next