Measuring Real Signal Spend with the Clay CLI

A signal created without --activate is Paused and neither runs nor spends. Resuming it does not wait for the next scheduled occurrence: it can trigger a check within seconds. Pairing clay signals resume/pause with clay credits balance before and after is how to observe whether a given signal configuration actually consumes credits, rather than assuming it from the schedule alone.

What you will build

A signal moved from Paused to Active and back, with a credit balance check on either side of the activation window.

clay credits balance                       (before)
    ↓
clay signals resume <triggerDefinitionId>  (runStatus: Active, lastRunAt stamped almost immediately)
    ↓
clay credits balance                       (after)
    ↓
clay signals pause <triggerDefinitionId>   (stop further scheduled spend)

AI Prompt

Using the Clay CLI, measure whether resuming a signal produces an observable credit spend.

Requirements:
- A signal created without --activate has runStatus "Paused" and neither runs nor spends.
- `clay signals resume <triggerDefinitionId>` sets runStatus to "Active" using the signal's
  existing schedule and filter. This alone can produce a lastRunAt timestamp within a few
  seconds, even though the schedule's own period (daily, weekly, and so on) suggests the
  next check is far off.
- Read `clay credits balance` before resuming and again after lastRunAt is stamped, to see
  whether that check consumed a visible amount of credits.
- Pause the signal again with `clay signals pause <triggerDefinitionId>` once done, so it
  does not keep running on its schedule.
- Run the verification step below before finishing.

Prerequisites

• The clay CLI on PATH, authenticated via clay login (an OAuth session, not a Public API key)
• An existing Paused signal (any type)

Note: JSON samples below are trimmed to the fields relevant to each step. Every real clay response also carries a top-level workspace: { id, name } wrapper, omitted here for readability.

1. Read the balance before resuming

clay credits balance

Real output:

{ "balance": 394273 }

2. Resume the signal

clay signals resume td_example

Real output:

{
  "id": "td_example",
  "runStatus": "Active",
  "schedule": { "periodAmount": 1, "periodUnit": "daily" },
  "updatedAt": "2026-09-28T23:11:00.724Z"
}

3. Re-check the signal a few seconds later

clay signals get td_example

Real output:

{ "runStatus": "Active", "lastRunAt": "2026-09-28T23:11:01.130Z", "error": null }

lastRunAt is stamped about four hundred milliseconds after resume returned, well before this signal's own daily schedule would suggest.

4. Read the balance after, then pause

clay credits balance

Real output:

{ "balance": 394273 }

clay signals pause td_example

Real output:

{ "runStatus": "Paused" }

In this run, against a small test audience, the balance showed no visible change across the check. That is itself a real result worth recording rather than assuming a specific per-check cost: whether a given signal's check registers on credits balance depends on how many records it actually evaluated and what it found, and a check against a tiny or unmatched population can complete without a visible balance movement.

Verify the result

clay credits balance

Expected: comparing the value read immediately before resume against the value read after lastRunAt is stamped shows whether that specific signal's check drew down the balance, rather than assuming a fixed cost from the signal type alone.

How it works

resume does not requeue the signal for its next scheduled slot; on first activation it can trigger an evaluation almost immediately, independent of the configured cadence. credits balance reads the same workspace-level counter every routine and signal draws from, so bracketing a resume/pause cycle with two balance reads is a way to notice a check's spend, provided nothing else in the workspace is running at the same time. The CLI's own credits balance --help is explicit that a balance is available capacity, not an estimate or evidence of what a particular run charged, so a delta observed this way is suggestive of that run's cost, not a precise attribution to it.

Common issues

A schedule's period is not a guarantee of when the next check happens

Resuming a signal can produce a check well before its periodUnit would suggest. Do not rely on the schedule alone to predict when a paused-then-resumed signal will next spend.

Resuming an already-run signal does not necessarily trigger another check

The near-immediate check described above is a first-activation behavior. Pausing and resuming a signal that has already produced a lastRunAt within its current schedule period can leave lastRunAt unchanged for an extended stretch, rather than stamping a new one. Confirm lastRunAt has actually advanced past its previous value before reading a balance delta as evidence about that specific resume.

A zero-looking balance delta does not mean the signal is free

It can mean the population checked was small or matched nothing this run, or that the resume did not trigger a new check at all (see above). Confirm lastRunAt advanced, and repeat the measurement against a fresh signal or a larger, more representative audience, before concluding a signal type has no real cost.

Next steps

• Controlling Signal Spend Through Filters
• The creditLimit Field on an Audience Signal

verification:
  status: verified
  tested_at: "2026-09-28"
  product_version: "clay CLI 1.4.0"
  command: "clay signals resume <triggerDefinitionId> && clay signals get <triggerDefinitionId>"
  expected_result: "runStatus becomes Active and lastRunAt is stamped within seconds, well ahead of the signal's own schedule period."

Related Articles

• Watching an Audience for Job Changes with the Clay CLI
• Bulk-Pausing Every Signal of a Given Type with the Clay CLI
• Running a Signal's Full Lifecycle with the Clay CLI