Podcode
Sign in
DocsProviders

RunPod cost and lifecycle

A GPU you forgot about is the only way this integration can cost you real money by surprise. Everything on this page exists for that.

Who pays whom

All GPU spend flows from you to RunPod directly. Your RunPod payment method pays for every second of GPU time; inference goes from your machine straight to the endpoint. Podcode is not in the billing path and takes no cut of inference.

That's the good news and the reason for the safeguards: there is no metered gateway that would stop a runaway, because there is no gateway at all.

The daily spend cap

On by default, at $20/day, per account.

  • Set it in Settings → Providers.
  • 0 means spend nothing, and is honoured literally.
  • Clearing it switches the cap off — a deliberate choice, not a default.

It is enforced in three places, deliberately redundant because they cover different states of the app being alive:

  1. The readiness poller, which will tear down a pod that boots but never serves, within one tick.
  2. The provider itself, which refuses to issue a request that would exceed the cap.
  3. The offline watchdog (below), which works with the app closed.

The cap sums only that account's non-terminated deployments — another user on the same machine doesn't count against you, and a deployment you already terminated doesn't count forever.

Idle auto-stop

Serverless doesn't need it: RunPod scales workers to zero on its own.

Pods do. Podcode can stop an idle pod automatically — and because the app might not be running when the pod goes idle, the enforcement lives outside the app as a macOS LaunchAgent, installed and removed from Settings. It's opt-in, and it's the only thing that protects you over a weekend with the app closed.

Pause and resume

Pause stops a ready pod and records when. Billing for GPU time stops; the weights volume persists.

Resume brings it back. If RunPod no longer has that GPU available, a fresh pod is provisioned against the same weights volume — which is what makes resume fast the second time, since the multi-gigabyte download doesn't repeat.

Resume is safe to click twice: only the first request wins, so two concurrent resumes can't leave you with two pods and one of them billing invisibly.

Terminate

Terminate stops the deployment, releases its network volume, and removes it from your list. Upstream teardown is best-effort and logged either way, so a RunPod-side failure can't leave you with a row you can't delete.

Disconnecting the account terminates pods first, then deletes volumes, then drops the credential — in that order, because after the credential is gone there would be nothing left to authenticate a cleanup with.

When a deployment is stuck

  • Stuck provisioning. Pods legitimately take a long time on first deploy; weights download before anything can serve. Give it the time the template needs before assuming it failed.
  • Never became ready. The poller times out per kind and marks the row failed. Terminate it and redeploy; a pod that boots but never serves is also torn down by the cap check.
  • Stranded mid-provisioning after a restart. Boot recovery reconciles rows that were provisioning when the server stopped.
  • Something is billing that Podcode doesn't show. Orphan sweeps cover pods and volumes, but the RunPod console is authoritative — check it.

Next

  • Integrations — the other things Podcode can be connected to.