Skip to content

Billing: meter or cap runner egress, attributed per job and workspace #194

Opensyntaqx opened this feature

Part of the post-launch billing hardening (follows #139).

The runner's direct outbound traffic isn't metered, so what g1t recovers for compute is incomplete.

  1. Measure each job's egress (the container's network bytes) and attribute it to the workspace.
  2. Before choosing a model, put a number on today's exposure from real job data.
  3. Then choose one, and say why:
    • meter egress at cost plus the margin, or
    • bound it with an included allowance and a hard cap.
  4. Update the pricing docs and the margin reconciliation to match.

Billing safety rules (non-negotiable)

Billing has been live on Stripe since 2026-10-15 and takes real money from real customers.

  • Never run fixtures, seeds or the sandbox harness against the production Stripe account. Test only with the separate Stripe sandbox key and a local billing Worker (target/billing-audit). Its .dev.vars loads automatically, and --env-file does not bind secrets. The harness is scripts/ops/billing-sandbox.mjs (phases: protocol, seed, run, cleanup, lifecycle, enterprise, complimentary). Ask the owner for the sandbox key's location.
  • Never print or commit secrets. Writing Worker secrets is the owner's job: hand them the exact command, in Git Bash syntax with single quotes and forward slashes.
  • Any live charge, refund or change to a Stripe object needs the owner's explicit OK for that specific action.
  • Pushing to main deploys production, migrations first and then the Workers. Every migration must be safe against the code already running.
  • Billing's own API requests stay pinned to Stripe API 2025-02-24.acacia. The live webhook's events are listed in services/billing/src/webhooks.rs EVENTS.
  • The owner's billing audit notes (docs/audits/2026-10-14-billing.md, local and ignored by Git) hold the "LIVE" section and the remaining launch gates. Ask for them if you don't have them.

Validation for every change

cargo test -p g1t-billing --lib (and -p g1t-repos for storage); cargo check of the workspace and of the changed services for wasm32-unknown-unknown; node --test --test-isolation=none conformance/*.test.mjs; the TypeScript checks and tests for anything touching apps/ or packages/; npm run test:deploy; build the actual billing Worker before running sandbox phases; git diff --check; and inspect what is staged for secrets and artifacts. Get an independent review of money-path changes before they are pushed. Report what was verified live and what was verified only in the sandbox.


How to work on this repository

  • Claim this item before you start (g1t work claim <number>), and add G1t-Session: $G1T_SESSION to every commit.
  • Other sessions share the main checkout: work in a worktree of your own and stage only your own files.
  • Pushing to main deploys production, and pushes to main and release tags are the owner's. Land the work through a pull request on this item, or commit locally and hand the owner the exact git -C <path> push ….
  • Shipped means on main and deployed. Check it live with real data and look at the rendered pages: a status code doesn't show it works.
  • Docs ship in the same change as the feature (guides, reference, llms.txt), to a high standard.
  • User-facing text never names other products or compares g1t to them. Internal notes and code comments may.

Repositories

Suggested

Repositories it may also need, and why.

  • hello8 work items with the same labels landed there.
  • automation-lab2 work items with the same labels landed there.
  • deployIt names deploy.

Nobody has worked on this yet

Point your own agent at flagon-io#194.

Discussion

syntaqxmoved this from Triage to Next·

Sign in to comment.