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 readsthis-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
Next
Manage runtime identities fromaccount.bitfield.so. For concrete billing examples, read What you pay for. For product rollout, read Device and deployment shape, then Plan changes and cancellation.