[3P] Metering → payout-ready (payouts built behind a flag, launch deferred)

Part of #58 (the open-to-third-party epic). Monetization decision = free/beta first — build the plumbing, don't launch payouts.

Finish per-agent / per-execution metering (ties to in-flight admin [Admin][API] Meter platform-paid AI into the ledger (embeddings/summaries/translation) #44) — needed NOW for cost governance even without payouts.
Build Stripe Connect usage-share payout plumbing (creators paid pro-rata from the sub pool minus 10% platform fee, PAS-style) behind a disabled flag.
Creator earnings dashboard (read-only preview) — no real payouts until the flag flips.
Tax/legal prerequisites captured as a checklist for the eventual flip.

docs: program plan for opening PAGS to third-party agent creators (#58)

Labelled deferred: no demand — not cancelled, and not started.

Per #250 ("the board contradicts the focus bet — make deferred-by-strategy legible"), and #58's own wording, which gates this work on demand rather than on readiness.

The measurement that decides it, taken 2026-08-06 over 30 days (GET /v1/admin/usage/external):

external users:  0
operator calls:  2,782
spend:           $40.92 — entirely the operator's own

This issue serves third-party creators. There are none, and nothing on the board measures progress toward getting one. Leaving it as live work makes the roadmap read as if it were in flight, which is precisely what #250 objects to.

The un-gate condition is #68's: external users on a first-party runtime agent. When that number is non-zero, this comes back — the endpoint above makes it checkable rather than a matter of opinion.

Nothing here is judged wrong or wasted. The platform work that already landed (capability registry, connector framework, declarative pipelines, per-tool consent) is what makes first-party agents cheap to build, and it stays. What is deferred is the marketplace layer on top: sandboxing untrusted creator code, curated publish review, payout metering, creator onboarding.

fix(api): the external-usage report carries value and charge separate…

Old-issue sweep, 2026-08-18. The gate is re-verified — GET /v1/admin/usage/external?days=30 still returns externalUsers: 0, calls: 0 — so the deferred: no demand label stands and none of the payout scope should move.

One correction to this ticket's scope, because its first checkbox is not deferred and is largely delivered: "Finish per-agent / per-execution metering (ties to in-flight admin #44) — needed NOW for cost governance even without payouts."

Since this was written the ai_usage ledger has grown per-agent and per-instance attribution (#662 populated EngineMeter.instanceId, so platform-paid rows are instance-scoped), a payer dimension (byok-api / platform / unknown), engine self-reported cost (#267), explicit unmetered labelling for pane-driven CLIs (#348), a per-account four-tier ceiling resolver with a live API and console surface (#474–#477), and GET /v1/usage + GET /v1/admin/usage/external. Measured live today: chargedMicros: 53553393 over 30 days, split by payer and by agent.

So the metering half is real and in production; what is deferred is Stripe Connect, the earnings dashboard and the tax checklist. Recommend striking checkbox 1 so this ticket does not read as though the platform still cannot answer "what did this agent cost" — it can, and several open tickets depend on that being known.

docs(drift): fix two stale citations in docs/ (#666)

Owner decision on 2026-10-14: retire/defer marketplace work for now. Do not start third-party marketplace expansion, creator-code sandbox, public creator submission/review, payout/metering, or related 3P launch work from this ticket set. Current focus is making first-party runtime agents and core PAGS flows work coherently for real users. Reopen/reactivate marketplace work only with a new explicit owner decision.

❓ The coder stopped on a question: The CLI is refusing to implement issue #57 because a 2026-10-14 owner comment on the issue says "Do not start payout/metering, or related 3P launch work from this ticket set" and that reactivation needs "a new explicit owner decision." The CLI treats that as a standing directive that overrides the run objective. Do you want to proceed?

Options: Yes — proceed; my run objective IS the reactivation decision · No — leave #57 deferred; close this run as done (nothing to build) · No — close this run as failed (objective cannot be met)

Why it asks: The CLI will only build the Stripe Connect payout plumbing, creator earnings dashboard, and tax checklist if the owner explicitly reactivates the work. Without that, it will not implement #57.

Answer it on the run's card or with answer_instance_input. The run is parked until it is answered — answer any time; it continues from where it stopped.

Owner decision (Serge, 24 Oct 2026): skip all marketplace and payout work. The parked run for this issue was closed without changes; nothing was implemented. Issue stays deferred.

Auto-pickup flagged this issue for review (#1407). A run reported it done, but no delivered commit could be found for the run that finished it — labelled needs-human so it is not retried automatically; remove the label once it is confirmed resolved (or reopen the work) and it becomes eligible again.

Navigation Menu

Repository navigation

[3P] Metering → payout-ready (payouts built behind a flag, launch deferred) #57

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

[3P] Metering → payout-ready (payouts built behind a flag, launch deferred) #57

Description

Activity

serge-ivo commented on Aug 6, 2026

serge-ivo commented on Aug 18, 2026

serge-ivo commented on Oct 14, 2026

proagentstore commented on Oct 23, 2026

proagentstore commented on Oct 23, 2026

proagentstore commented on Oct 30, 2026

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions