lpm pool

lpm pool shows the current monthly Pool earnings estimate for your LPM.dev Registry account.

lpm pool [OPTIONS]

The report includes your personal packages and packages from organizations where you are an owner or administrator. It has one mode: the current billing period. There are no package, organization, or historical-period filters.

LPM CLI supports npm and private registries, but this command uses the LPM.dev Registry Pool account API. See Registries.

Quickstart

Sign in with a browser session, then request the report:

lpm login
lpm pool

See lpm login for authentication. A standalone registry token from CI or .npmrc cannot access this account API. The command does not require a project, install packages, change distribution modes, or start payouts.

Examples

lpm pool                                         # current account estimate
lpm pool --json                                   # structured report
lpm pool --json | jq '.estimatedEarningsCents'     # estimated cents
lpm pool --json | jq '.packages[] | {name, weightedDownloads}'

For an unattended command, provide an existing session access token through the environment:

LPM_TOKEN="$POOL_SESSION_TOKEN" lpm pool --json

Environment tokens do not refresh automatically. A stored browser session can refresh during the request. See Authentication.

A task in lpm.json

lpm.json has no dedicated Pool configuration. A named task can request a fresh report:

{
  "tasks": {
    "pool-report": {
      "command": "lpm pool --json",
      "cache": false
    }
  }
}

lpm run pool-report

The task uses the same account credentials as a direct command. It does not enable Pool distribution. See lpm publish for publication and distribution modes.

Read the report

  Pool Revenue Stats

  billing period       2026-09
  weighted downloads   1,234.85
  estimated earnings   $18.42

  packages (2):
    @lpm.dev/acme.toolkit   (1,234.7 downloads)
    @lpm.dev/acme.icons     (0.15 downloads)

Weighted downloads can contain decimals. They represent eligible install observations after weighting, rather than raw download requests. The Registry orders packages by estimated earnings.

The current report is an estimate, not a payout balance. It uses active subscriptions and the standard Pool price. Final settlement uses actual payments, discounts, credits, and refunds. Unused subscriber contributions can also produce earnings for packages with no weighted downloads.

How weighting works

The LPM.dev Registry calculates Pool revenue. For subscribers with eligible installs, each subscriber's author share goes to those packages during the billing period.

After a successful install, LPM CLI reports the resolved dependency graph. This includes installed versions, overrides, optional dependencies, peer dependencies, and canonical alias targets. A failed download or extraction does not create Pool credit.

Each @lpm.dev/* dependency adds one level. npm packages do not add levels:

project → @lpm.dev/owner.a → @lpm.dev/owner.b → @lpm.dev/owner.c
          depth 0          depth 1          depth 2

project → npm-wrapper → @lpm.dev/owner.a → npm-helper → @lpm.dev/owner.b
                        depth 0                        depth 1

The LPM.dev Registry applies these rules:

• Each subscriber contributes at most one observation per package per month. Repeated installs and retries do not add observations.
• The shallowest observed path wins. At equal depth, a path without the same-owner penalty wins before a stable tie-break.
• A dependency with the same owner as its immediate @lpm.dev/* parent receives 30% of its base weight.
• A transitive dependency needs at least two unique installers before its weight counts.
• Publisher access does not create credit, including personal packages and packages owned by the subscriber's organizations.
• Optional packages omitted on the current platform and dependencies absent from the installed graph receive no credit.

For example, a from Alice depends on b from Bob, which depends on c from Bob. The base weights are 1, 0.7, and 0.49. The same-owner rule reduces c to 0.147, which rounds to 0.15 before accumulation.

Unmanaged clients do not report a completed dependency graph. Their authenticated Pool downloads count as direct observations for the fetched packages only.

Older LPM CLI versions that report only package roots can still complete installs successfully. The LPM.dev Registry credits eligible reported roots after it verifies their versions and authenticated download evidence. It does not infer transitive dependencies from these reports. Transitive packages can receive less credit until subscribers update LPM CLI. Access checks and payment rules still apply.

During a registry rollback, LPM CLI retries the report with package roots if the older registry explicitly rejects graph reports. Roots can follow npm bridges. Each request contains at most 200 roots. Installs complete after the registry accepts those reports. LPM CLI warns that dependency credit can be incomplete. Permission errors and other validation errors still stop the command.

Final payments and refunds

The author share is 80% of the paid Pool amount, excluding tax. Discounts reduce that amount. A $6 discounted payment contributes $4.80 to author revenue.

Refunds reduce the recorded contribution. Pending refund adjustments hold new payouts, retries, and payout setup recovery until revenue calculation handles those adjustments.

For a historical refund, calculation first deducts eligible unpaid carry for each affected package, then current earnings. Paid amounts and carry reserved for a payout stay unchanged. The platform absorbs any amount that these earnings cannot cover. Retries do not deduct the same carry twice.

Recover an unconfirmed install report

If LPM CLI reports pool_attribution_unconfirmed, retry the same lpm install command. LPM CLI can reuse cached packages and retry the report without duplicate credit.

Full graph reports have limits of 10,000 graph nodes, 50,000 edges, and 1,000 @lpm.dev/* package instances. LPM CLI includes only paths relevant to @lpm.dev/* packages. An oversized or incomplete graph returns an error instead of partial credit. Older clients can send up to 200 roots per report.

JSON output

The CLI retains the Registry field names, including their camelCase spelling:

lpm pool --json

{
  "success": true,
  "billingPeriod": "2026-05",
  "totalWeightedDownloads": 142830,
  "estimatedEarningsCents": 1842,
  "packages": [
    {
      "name": "@lpm.dev/acme.toolkit",
      "owner": "acme",
      "packageName": "toolkit",
      "installCount": 91500,
      "weightedDownloads": 84210,
      "sharePercentage": 58.96,
      "estimatedEarningsCents": 1086
    }
  ]
}

Missing optional values appear as null. The packages array defaults to [] when the Registry omits it. Each package requires name. success: true means that the request succeeded, including an empty report. Additional fields can appear in future releases.

Recovery

Flags

This command has no command-specific flags.

LPM_TOKEN and LPM_REGISTRY_URL provide the token and Registry defaults. Explicit flags override these environment values for one run. See Global flags.

See also

• LPM.dev package distribution — Private, Free, Pool, and Marketplace access and permanent mode choices
• lpm publish — how a package opts into Pool (the dashboard-driven flip)
• Publishing a package — walkthrough including the pool/marketplace flip