Bitfield Docs

Active device is the public pricing word for a device, server, or runtime identity where Bitfield was actually asked to run during the billing window.

It does not mean “installed once forever.” It does not mean “authorized in theory.” It does not mean “how many seconds the runtime ran.” It means Bitfield was actually asked to run for that identity in the billing window.Active device is a pricing label over signed Bitfield observations. It is not a second billing system beside Runtime Kit, and it is not a special rule for local installs only.The technical line is simple: request bytes entered Bitfield, Bitfield decoded an envelope, and the address resolved to a slot, native handler, or live state. That identity can count. Static files being served do not cross that line.For local Bitfield, the identity starts from local device key material. Bitfield creates or reads this-device.key, derives a device public key hash, and uses an activation ID for that runtime. By default, the activation ID is the device public key hash.That means active device is not a cookie, browser tab, IP address, VPN address, or page view. It is the activated runtime identity.

Plan

Your plan includes a range of runtime/device units.

→

Request

A device, server, or runtime identity calls into Bitfield.

→

Manage

The account portal manages runtime identities you no longer want active.

What counts

Runtime identity	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, cloud runtime, or local box	Bitfield is asked to run there during the billing window.
Test machine or CI runner	Bitfield is asked to run there during the billing window.
Customer device	That customer environment asks Bitfield to run.

What does not count by itself

Thing	Why
Old installed files	Dormant files send no Bitfield request bytes.
Public website visitor	Viewing already-published output sends no Bitfield envelope bytes.
Static exported page	Visitors reading static files do not resolve a Bitfield slot, native handler, or live-state read.
Same runtime doing lots of work	Usage amount is not the unit.
Package folder	A package is product material, not request bytes entering Bitfield.

Repeat use and split identities

Situation	Count model
Same activated laptop, many actions	One runtime/device unit for the billing window.
Same laptop, different browsers or incognito	Still one unit when they talk to the same local Bitfield runtime identity.
Same laptop, VPN on or off	Still one unit. IP address is not the identity.
Same laptop, cookies cleared	Still one unit when local Bitfield activation state remains.
Laptop plus phone	Two units when both send Bitfield request bytes.
One activated server serving many visitors	One server unit unless visitor browsers also send Bitfield request bytes.
Ten activated servers	Up to ten server units.
Persistent CI runner	One runner identity can count once for the window.
Fresh ephemeral CI runner every run	Each newly activated runner can count separately.
Deleted activation state and activated again	Can become a new identity. Revoke old identities from the account portal.

Local activation state

Runtime Kit package state and engine storage live under ~/.bitfield/, and activation has its own sibling lane for this device’s signed permission. That local state is not something the customer should edit by hand.

Local idea	Customer rule
Device key material	Created by the activation flow, not invented manually
Signed permission	Comes from account-owned activation
Old blocked permissions	Remembered so revoked access does not silently return
Runtime Kit package state	Separate from activation; do not mix the two

Common failures

Symptom	Likely cause	Fix
New computer cannot run Bitfield	Device path was not activated yet	Use the account portal activation flow
Old computer still appears active	Runtime identity was not revoked or replaced	Manage active devices in the account portal
User copies one device’s local activation folder to another	Local permission was treated like a portable key	Activate the second runtime identity properly
Package tooling tries to own activation	Runtime Kit and activation boundaries got mixed	Keep activation in the account/key lane
Billing is explained as runtime seconds	Runtime request count and runtime amount were mixed up	Say one identity where Bitfield was asked to run, not per second

Verify

The active-device model is clear when the user can tell the difference between:

the plan subscription
a runtime/device unit that sent Bitfield request bytes
local activation state
Runtime Kit package state
public static traffic

Manage runtime identities from account.bitfield.so. For concrete billing examples, read What you pay for. For product rollout, read Device and deployment shape, then Plan changes and cancellation.

Build a product

Activation

Active devices

What counts

What does not count by itself

Repeat use and split identities

Local activation state

Common failures

Verify

Next

​What counts

​What does not count by itself

​Repeat use and split identities

​Local activation state

​Common failures

​Verify

​Next

What counts

What does not count by itself

Repeat use and split identities

Local activation state

Common failures

Verify

Next