The Day a Billing Change Got Reversed at the Last Minute — Designing a Reversible Pipeline So You Don't Rewrite in a Panic

Make the headless invocation mode-agnostic

Next, the stage that actually calls claude -p. The point is to keep it unaware of the mode; the caller only asks "may I run under this policy?"

// src/ops/run-headless.ts
import { spawn } from "node:child_process";
import { resolveBillingPolicy } from "./billing-mode";
 
interface HeadlessResult {
  ran: boolean;
  reason?: string;
  stdout?: string;
}
 
// A lightweight counter for today's run count (persist via KV or a file).
async function consumeDailyBudget(limit: number): Promise<boolean> {
  const used = await readTodayCount(); // implementation depends on your environment
  if (used >= limit) return false;
  await incrementTodayCount();
  return true;
}
 
export async function runHeadless(
  prompt: string,
  opts: { stage: string }
): Promise<HeadlessResult> {
  const policy = resolveBillingPolicy();
 
  if (!policy.headlessAllowed) {
    return { ran: false, reason: "headless disabled by policy" };
  }
 
  // Regardless of mode, run within the daily budget.
  // Under subscription the budget is large, so it passes through;
  // under metered_credits it naturally paces itself.
  const ok = await consumeDailyBudget(policy.dailyHeadlessBudget);
  if (!ok) {
    return { ran: false, reason: `daily budget exhausted (${policy.mode})` };
  }
 
  const stdout = await new Promise<string>((resolve, reject) => {
    const child = spawn("claude", ["-p", prompt], { encoding: "utf8" } as never);
    let out = "";
    child.stdout?.on("data", (d) => (out += d));
    child.on("close", (code) =>
      code === 0 ? resolve(out) : reject(new Error(`exit ${code}`))
    );
  });
 
  return { ran: true, stdout };
}

The caller just writes runHeadless(prompt, { stage: "generate" }), and nothing changes under either billing premise. Ship or reverse, every stage that calls this function needs zero edits. The reason I touched no code that day was this one layer of indirection.

One thing I learned in practice: consume consumeDailyBudget before the run, not after. I initially counted after execution, but when claude -p failed midway the count didn't advance, and a retry ran it twice. Advancing the counter first — and treating a failure as already consumed — is safer with a non-rollover credit pool. It looks like a small loss, but it beats melting the whole pool in a runaway loop.

Decide "rearchitect or hold" by rule

Judging emotionally on every reversal or delay is exhausting. I use the table below to decide mechanically whether to act now.

The crux of this table is the line it draws: at the "notice only" stage, you don't touch core code. Until certainty reaches "certain," action stays limited to measuring and note-taking. This reversal fell on the "reversed/held" row, and what I did was revert the env var — which, since it had been subscription all along, literally meant doing nothing.

Three principles for operations that survive reversals

After living through several announcements like this, three principles have settled in my mind.

First, separate certainty from action. The more certain the announcement, the more committed an action you may take. Responding to a mere notice with a core rewrite leaves too large a gap between certainty and action.

Second, externalize the axis along which change can happen into one place. Here the axis was "billing premise." Confine that axis to a single resolver and both the change and its reversal come down to an env-var diff. Conversely, if the billing judgment were scattered across ten files, every reversal would mean editing ten files.

Third, put a price on preemptive complexity. Code written ahead of time becomes debt when the change is reversed. I always ask: "if this gets reversed, can I throw this change away?" If it can be discarded — i.e., it's a harmless layer of indirection even if held — go ahead. If it can only be discarded (a ship-assuming branch embedded in core), wait until it's confirmed.

These three apply well beyond billing — to API spec changes and model retirement notices too. In fact, an old-generation model retirement landed the same week, but because the model name was externalized into a single constant, that swap was also a one-spot change.

Your next step

If you run an automated pipeline, start by writing down just one "premise that can change from the outside" — billing, model name, rate ceiling, endpoint, anything. Then grep for how many places in your code currently make that judgment. If it's scattered across two or more spots, begin by pulling them into a single resolver. The next time an announcement lands, you'll be able to absorb it with a one-line env-var change instead of a scramble.

I'm still feeling my way through reversibility-minded design, but this reversal left me with a quiet sense that "not having to touch it" was worth the effort. If it helps anyone else being tossed around by announcements, I'm glad. Thank you for reading.