An active device is the customer-friendly name for a Bitfield runtime identity where Bitfield was asked to run in the billing window.
That runtime identity can be a laptop, phone, server, worker, kiosk, CI runner, browser environment, or local box. The shape can be local or cloud. The important thing is simple: Bitfield was asked to run for that identity.Active device is the current public pricing label over signed Bitfield observations. It is not a separate local-only counter, and it is not a page-view counter.Technically, that means request bytes entered Bitfield, Bitfield decoded an envelope, and the address resolved to a slot, native handler, or live state.For local Bitfield, the identity is activation-based. Bitfield creates or readsthis-device.key, derives a device public key hash, and uses an activation ID for that runtime. By default, that activation ID is the device public key hash.So the identity is not a cookie, incognito tab, IP address, VPN address, route name, project name, package name, or page view.Plan
The account has a plan with a runtime/device range.
→
Request
A runtime identity actually asks Bitfield to run.
→
Portal
The account portal handles activation, replacement, and revocation.
What counts
A laptop can count. A phone can count. A tablet can count. A server can count. A Raspberry Pi can count. A runtime environment can count.The working rule: if Bitfield was asked to run there during the billing window, that runtime identity can count.What does not count
A static page does not become a new active device for every person who reads it because those visitors are only receiving already-published files. No Bitfield envelope bytes means no slot, no native handler, and no live-state read for that visitor. A dormant install does not count just because files exist. A package folder does not count just because it is present. One runtime doing a lot of work is not a lot of units.One runtime identity can do a lot of work in one billing window and still be one identity. Different devices, different activated servers, or fresh ephemeral runtimes can count separately because they have different runtime identities.How moving a spot works
If you stop using one runtime identity, revoke it in the account portal. That frees the spot so a replacement device, server, or runtime identity can use your key.Why pricing uses this word
Bitfield pricing is based on active runtime/device units because the product is not priced per app, per project, per seat, token, install, revenue share, page view, click, or runtime second.Common confusion
| Confusion | Correct model |
|---|---|
| ”Is an active device the same as a user?” | No. It is an identity where Bitfield was asked to run. |
| ”Does a project count?” | No. A project is not the billing unit. |
| ”Does every website visitor count?” | No. Visitors reading already-published files are not asking Bitfield to run. |
| ”Does an old install count forever?” | No. Dormant files send no Bitfield request bytes. |
| ”Does incognito count again?” | No, not when it talks to the same local Bitfield runtime identity. |
| ”Does a VPN count again?” | No. IP address is not the identity. |
| ”Do two devices count separately?” | Yes, when both send Bitfield request bytes. |
| ”Does a server count?” | It can when it asks Bitfield to run. |
| ”Where do I manage this?” | Use account.bitfield.so. |
Next
- Get access and activate your first runtime identity: Get your key
- See concrete billing examples: What you pay for
- Read the account lifecycle: Account and key flow
- Build across devices and servers: Device and deployment shape