feat(tasks): report priced sandbox compute credits

[adboio]

Problem

Sandbox compute needs a priced usage counter without allowing a client-selected task origin to determine whether work is charged.

Changes

This PR is stacked on #74491. It calculates integer compute credits from the snapshotted sandbox ledger and applies the existing origin rules. User-created work is billable only when SandboxSession.compute_source is the server-verified posthog_desktop value. Signal-report work remains excluded, and loop billing uses the provision-time internal classification.

Resource quantities use the configured burstable request floors, durations round up to whole seconds, and pricing remains isolated behind provisional named constants.

How did you test this code?

• Ruff lint and formatting for the changed aggregation and tests
• Regression coverage for verified Desktop source, default-denied sources and origins, signal reports, direct app origins, loop classification, TTL and reporting-window boundaries, and burstable pricing

Database-backed tests rely on CI because the configured Postgres hostname is unavailable locally.

Automatic notifications

• Publish to changelog?
• Alert Sales and Marketing teams?

Docs update

No user-facing documentation change.

🤖 Agent context

Autonomy: Human-driven (agent-assisted)

Codex implemented the counter with direct human design review. Repository testing and Django migration guidance shaped the validation. The key decision is to bill from immutable ledger provenance rather than the mutable task or a client assertion.

---

Created with PostHog Code

[trunk-io]

Merging to master in this repository is managed by Trunk.

• To merge this pull request, check the box to the left or comment /trunk merge below.

After your PR is submitted to the merge queue, this comment will be automatically updated with its status. If the PR fails, failure details will also be posted here

[github-actions]

Hey @adboio! 👋

It looks like your git author email on this PR isn't your @posthog.com address (adambowker98@gmail.com). Since you're on the PostHog team, it's worth pointing your local git author email at your @posthog.com address. Why it matters:

• Consistent work identity in git history — internal tooling that attributes commits to team members keys off your @posthog.com address.
• Keeps team contributions easy to tell apart from external community ones when scanning history.

You can fix it for this repo with:

git config user.email "you@posthog.com"

Or set it globally with git config --global user.email "you@posthog.com". No need to redo this PR — just a nudge for next time. 🙂

[posthog]

🦔 ReviewHog reviewed this pull request

Found 0 must fix, 1 should fix, 0 consider.

Published 1 finding (view the review).

[posthog]

ReviewHog Alpha 🦔 If you find any issues helpful - please reply "valid", "invalid", etc., for evaluation purposes 🙏

[posthog]

ReviewHog Report

Changes

Issues: 1 issue

Files (4)

• posthog/tasks/usage_report.py
• posthog/temporal/usage_report/queries.py
• products/tasks/backend/logic/services/sandbox_usage.py
• products/tasks/backend/models.py

[greptile-apps]

Prompt To Fix All With AI

Fix the following 2 code review issues. Work through them one at a time, proposing concise fixes.

---

### Issue 1 of 2
products/tasks/backend/logic/services/sandbox_usage.py:156
**Historical Loop Usage Becomes Unbillable**

When a non-internal loop is later marked internal or deleted, this annotation reads `True` or `NULL` instead of the loop state when the sandbox ran. Rebuilding an earlier report then drops credits for compute that was billable at execution time, so historical billing changes after the session is complete.

### Issue 2 of 2
products/tasks/backend/logic/services/sandbox_usage.py:156
**Internal Loop Usage Becomes Billable**

When an internal loop is later marked non-internal, this annotation reads the new `False` value and the billing gate charges its earlier sandbox sessions. Historical reports can therefore add credits for compute that was internal when it ran; the billing classification needs to be recorded with the session rather than resolved from mutable current state.

_{Reviews (1): Last reviewed commit: "fix(tasks): expand billable sandbox orig..." | Re-trigger Greptile}

[greptile-apps]

Historical Loop Usage Becomes Unbillable

When a non-internal loop is later marked internal or deleted, this annotation reads True or NULL instead of the loop state when the sandbox ran. Rebuilding an earlier report then drops credits for compute that was billable at execution time, so historical billing changes after the session is complete.

Prompt To Fix With AI

This is a comment left during a code review.
Path: products/tasks/backend/logic/services/sandbox_usage.py
Line: 156

Comment:
**Historical Loop Usage Becomes Unbillable**

When a non-internal loop is later marked internal or deleted, this annotation reads `True` or `NULL` instead of the loop state when the sandbox ran. Rebuilding an earlier report then drops credits for compute that was billable at execution time, so historical billing changes after the session is complete.

How can I resolve this? If you propose a fix, please make it concise.

[adboio]

Fixed by snapshotting loop_internal onto SandboxSession at provision time and billing from that immutable value. The regression test flips both loop directions after provisioning.

[veria-ai]

Medium: Burst usage is priced at reservation floors

A user can run CPU- or memory-intensive code in a default burstable sandbox while this calculation charges only the 0.5-core/1-GiB reservation floor. The sandbox can consume up to its configured limits and the provider bills the greater of reserved and actual usage, so credits can substantially underreport attacker-driven compute consumption. Use provider-reported actual usage, or conservatively price the configured limits when actual usage is unavailable.

[veria-ai]

PR overview

This pull request adds reporting of priced compute-credit usage for task sandboxes, including CPU and memory consumption calculations.

One issue has been addressed, but burstable sandbox usage can still be priced at reservation floors rather than actual consumption or configured limits. A user can deliberately drive CPU or memory usage above those floors, causing compute-credit reporting to substantially undercharge their activity while provider costs continue to accrue.

Open issues (1)

• Medium: Burst usage is priced at reservation floors — products/tasks/backend/logic/services/sandbox_usage.py:186

Fixed/addressed: 1 · PR risk: 6/10

[github-actions]

🤖 CI report

✅ Playwright — all passed

All tests passed.

View test results →

✅ Django migration risk — migration analysis complete

We've analyzed your migrations for potential risks.

Summary: 1 Safe | 0 Needs Review | 0 Blocked

✅ Safe

Brief or no lock, backwards compatible

tasks.0076_add_compute_source
  └─ #1 ✅ AddField
     Adding nullable field requires brief lock
     model: taskrun, field: compute_source
  └─ #2 ✅ AddField
     Adding nullable field requires brief lock
     model: sandboxsession, field: compute_source
  └─ #3 ✅ AddField
     Adding nullable field requires brief lock
     model: sandboxsession, field: loop_internal

📚 How to Deploy These Changes Safely

AddField:

This operation acquires a brief lock but doesn't rewrite the table.

Deployment uses lock timeouts with automatic retries, so lock contention will cause retries rather than connection pile-up.

Last updated: 2026-07-29 16:37 UTC (387599a)

[github-actions]

🦔 Hogbox preview · ❌ build failed

The preview didn't come up for commit 9aa1279. See the build log for the failing step. It'll retry on the next push.

_{Previews are optional and never block merging. A failure here is often a hogland or tailnet hiccup rather than anything in your PR, so the check stays green and this comment is the status.}