What skill usage counts

Availability

Skill usage counting is available in every workspace; no separate activation is needed. A member’s loads count only while the workspace switch and the member’s own switch are both on. MCP read_skill loads count too, but MCP stays Partly measured: an older server version may still serve during a deploy without counting loads, and that window cannot be proved closed, so no absence is claimed from MCP. No tool is Measured today; the coverage table below shows each tool’s proven load paths and gaps.

Installs show who has installed a Skill. They are not loads, adoption, successful use or quality. The existing installation view and its older skill-usage URL remain install-only.

What counts as a load

Counting covers only managed workspace skills that the member can currently see. Bundled ArtifactBridge skills and non-managed skills are excluded. A count means the agent loaded the skill body, not that it followed the instructions or produced a good result. One session-day is counted per environment, server, workspace, tool, parent session, skill and UTC day. Subagent loads merge into the parent session-day. Loads on two days count on both days; MCP read_skill loads without a usable session id are deduplicated per skill, member, client family and UTC day. Model, user and subagent flags can overlap and do not sum to the session count.

The local reader must prove that the loaded path belonged to ArtifactBridge at that load time. Same-name project or plugin skills, directory listings and reference reads do not count. The earliest proven load determines the version hash, trigger and day; a later scan can correct an earlier observation. A load after a local edit can carry local_edit; an edit is not proof of a load.

Controls and recovery

Counting is on by default for every member and workspace. A member’s loads count from the moment both switches are on, and each time counting starts again (the member or the workspace turns it back on, a suspended member is reinstated, or a member rejoins) it counts from that moment. Nothing loaded earlier is backfilled.

The Count my skill use control is one server preference across web and CLI for the workspace. Off stops all sources and deletes existing daily, coverage, quiet, MCP and staged usage in the same transaction. An ordinary active workspace owner can turn counting off for the workspace; an admin or document owner alone cannot. Workspace off disables the personal control. Reviewer and counting controls are independent.

Every real member/workspace switch or lifecycle transition advances a generation. Removal and suspension stop counting; reinstatement and rejoin start a new counting interval. Reinstatement and rejoin never turn a personal off preference on. A new generation discards local old counts, pending evidence and unsent usage, and sets a new exact collection cutoff. Old sessions are not backfilled. Turning on cannot restore deleted totals. The first partial UTC day is not a full watched day.

A lost response is not proof that a switch changed or stayed unchanged. The original request key recovers applied evidence, a superseding named change, bounded in-progress, or no record yet. Lookup does not resubmit, mutate or repair. Permission loss wins over saved evidence. The same boolean value is not proof that a request applied. The server refuses to start a mutation more than 50 seconds after the trusted attempt stamp, including waits; in-progress is bounded to 60 seconds including margin. A delayed request with no record still has an unknown outcome.

There are 12 fresh ordinary switch keys per actor/workspace/server UTC day, shared across web and CLI and member/workspace targets. Replay and lookup do not charge again. Fresh already-current requests do charge. A real on-to-off privacy change bypasses the cap; already-off spam does not. A rate refusal preserves all old recovery evidence and returns the time until the next UTC day. Recovery keys and preferences survive off, reset, removal and rejoin until account/workspace deletion.

In the web app, Settings › Account › Privacy settings shows Count my skill use for the current workspace, and for workspace owners Settings › General › Workspace settings shows Skill usage analytics. Turning either off asks first and says what is deleted. If the answer is lost, the setting keeps its last confirmed value and offers Check again, which only looks the request up.

In the CLI, artifactbridge skills usage shows your own use on this computer in the last 30 days. It lists session-days, last used day and tools per skill. It also lists the skills installed here with no observed use, and coverage per tool. When this computer can't tell, it says why. It reads only this computer's records. With --json, it gives null and a no_data_reason for a value it cannot state. artifactbridge skills usage status shows your own control for the current workspace, and artifactbridge skills usage on or off changes it. These need your own sign-in; an agent is refused. Off asks for confirmation at a terminal; --yes skips it, and without a terminal and without --yes nothing changes (exit 2). If the reply is lost, the command exits 75 and keeps its request key: --check looks the key up without changing anything, and running the same command again sends the same key.

Who can see counts

Only skill managers see usage: workspace owners and admins for every skill they can see, and a skill’s document owner for that skill. Other members see no usage numbers, not even their own. In the web app, Settings › Agent › Skills has a Skill usage section listing the skills you manage with Sessions (30d), Members (30d), Last used, By tool, Installed and Failed installs. Sort by Most used or Least used. Owners and admins can show only the skills they manage themselves. No observed use (30d) shows the skills with no observed use in the last 30 days, including skills with no data yet. A dash means no data, not zero. On a skill’s SKILL.md document, the Usage section of the skill rail shows a skill manager the same figures for that skill over the last 30 days. Usage is shown per skill, never per member or per computer. No member’s numbers go through the activity feed, workspace events, webhooks or MCP analytics reads. Own controls accept verified ordinary web or a narrow human OAuth channel; agent accounts, agent/API tokens and synthetic agent JWTs have no control authority. Only ordinary web owners change the workspace switch.

What leaves the machine

The complete count-row field list is skill_id, tool, day, version_hash, local_edit, sessions, model, user and subagent. Counts are session-days; each trigger flag is the number of session-days with that flag. A version hash is the managed content identity, not source code.

Per tool: coverage state, fixed-enum reason, watched_from, scanned_until, collector_version and tool_version. Per installed managed skill: quiet_since. These are day-only dates, with nulls when a watched interval is unknown. Version strings are bounded, not arbitrary labels.

The common machine-report envelope carries usage_generation, usage_days, usage, usage_coverage and usage_quiet, alongside the report’s existing authenticated workspace/member/machine identity, sequence and parts. usage_days lists the UTC days whose complete row sets are replaced: an absent row on a listed day is deleted. Omitted usage keys keep the previous usage; omission is not an empty snapshot. Latest coverage and quiet arrays replace that machine’s latest state. All arrays together are limited to 500 items per part, each count to 1,000 per row, and days to today minus 31 through today plus one. Duplicate keys reject the usage section. Installation observations can still commit when usage is omitted or refused. Incomplete multipart usage is gated before staging and again at commit.

No session ids, prompts, code, files, paths, file names, repository or folder names, models, fine-grained load times, or names of non-managed skills are uploaded by this purpose. Hashes and managed/member/machine identities are still personal data, not anonymous statistics. Exact cutoff and attempt timestamps are control metadata, not uploaded session-load timestamps. No raw request/result JSON or arbitrary error text belongs in recovery receipts.

Coverage and absence

Measured means every required load path has passed its full fixture pipeline. Partly measured means at least one path is missing; Not measured means there is no verified reader; Paused means a member’s counting is switched off. A dash is not zero. A parser, permission, resource or reader-gap failure breaks watched continuity. An unknown tool version alone does not manufacture coverage.

This table is generated from the tested support list. Each proven load path has captured records from that exact tool build; each named gap keeps the tool Partly measured until it has them. Other builds, other platforms and other fronts are not proven: their recognized records can still count, but the tool is reported Partly measured (unknown_version) until a capture proves them, and a newly proven build is checked again without changing your session history. No blanket Measured claim follows from installation, a known tool version or a source-level test.

“No observed use since <day>” requires every loading tool on every machine that has the skill installed to be Measured, at least 14 full days continuously watched after the latest install and coverage start, and scanning through today or yesterday. Partly measured is insufficient. The latest qualifying quiet date across machines wins. Any observed load defeats absence. A stale machine says “No recent data”, not zero. No computable absence list is distinct from a valid empty list. After reset, show a new counting-start day and dashes until new reports arrive; do not restore old totals.

What counting cannot see

• An agent following a skill’s description without loading its body.
• A skill still active after compaction or in a resumed session without another load that day.
• Natively uploaded skills in Claude.ai, Cowork or ChatGPT. Only their MCP reads are visible.
• Codex cloud, Claude Code on the web, Copilot or Cursor cloud agents, and AB-hosted OMP containers except through MCP; machines without the app and members who paused counting.
• Sessions with persistence off, including Claude Agent SDK, Codex ephemeral threads, and records deleted before the next scan. The usual scan interval is 30 minutes, not a delivery guarantee; Claude Code’s default transcript cleanup is 30 days, and records may be removed before collection.
• Unrecognized reads fail closed: for example a pipeline or JavaScript file API reading SKILL.md, Hermes typed/preloaded skills, and OpenClaw counters. A successful skill use outside a recognized record path can be missed.

Retention and erasure

Usage day and MCP deduplication rows expire when older than 31 days. Coverage and quiet dates are latest state, not history; they follow the common machine lifetime and are pruned after 90 days silent. Incomplete staged sidecars expire within 24 hours. No long-term usage aggregate is retained. The local salted-key ledger lasts 32 days, with content-free pending evidence limited to 7 days; it contains no session content.

Member off, workspace off, suspension, removal, account deletion, workspace deletion and skill deletion erase the corresponding current data and staged identities transactionally. Demo reset clears usage and starts a new generation and counting start without restarting the allocator. Old generations can never re-upload deleted data. Retained preferences, budgets and compact request recovery evidence are erased at account/workspace lifetime end, including detached memberships; these do not expire merely because counting is paused. A standalone attribution-erasure pass deletes user-bound controls rather than rekeying preferences or receipts to a pseudonym.

Storage and privacy are bounded separately. Every recovery tuple is limited to 512 bytes; a measured target including indexes is 1 KiB per receipt, not a database-bloat guarantee. Operator thresholds are 75% of 512 MiB/workspace-year rolling admission growth, greater than 1 KiB measured bytes/receipt, or greater than 2.5 GiB retained allocation for the specified 50-person/five-year envelope. Operator reporting uses identity-free aggregates. Alert/scheduler wiring and actual common-machine cleanup must pass their later release gates.