Archiving Claude API Responses to Cloudflare R2: An Implementation Memo for Audit, Replay, and Incident Analysis

Writing to R2 from Cloudflare Workers Without Slowing the Hot Path

To avoid lengthening the user-facing latency, every R2 write runs through ctx.waitUntil. That keeps the Worker alive past the moment the HTTP response is returned so the side-effect can finish in the background.

Here's the bare version of a Worker that returns Claude's response and does nothing else:

// No archive — the starting point
export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const body = await request.json<ChatRequest>();
    const anthropic = new Anthropic({ apiKey: env.ANTHROPIC_API_KEY });
 
    const response = await anthropic.messages.create({
      model: "claude-sonnet-4-6",
      max_tokens: 4096,
      messages: body.messages,
    });
 
    return Response.json(response);
  },
} satisfies ExportedHandler<Env>;

Adding archive support is a few lines. Send the response back first; do the writing in the background:

import Anthropic from "@anthropic-ai/sdk";
 
interface Env {
  ANTHROPIC_API_KEY: string;
  ARCHIVE_BUCKET: R2Bucket;
  ARCHIVE_META: D1Database;
  BUILD_VERSION?: string;
}
 
export default {
  async fetch(request: Request, env: Env, ctx: ExecutionContext) {
    const body = await request.json<ChatRequest>();
    const anthropic = new Anthropic({ apiKey: env.ANTHROPIC_API_KEY });
 
    const response = await anthropic.messages.create({
      model: "claude-sonnet-4-6",
      max_tokens: 4096,
      messages: body.messages,
      metadata: { user_id: body.user_id },
    });
 
    // Return to the caller immediately
    const httpResponse = Response.json(response);
 
    // Persist in the background
    ctx.waitUntil(
      archiveResponse({
        env,
        request: body,
        response,
        userId: body.user_id,
      }),
    );
 
    return httpResponse;
  },
} satisfies ExportedHandler<Env>;
 
async function archiveResponse(args: {
  env: Env;
  request: ChatRequest;
  response: Anthropic.Message;
  userId: string;
}) {
  const { env, request, response, userId } = args;
  const requestId = response.id;
  const now = new Date();
  const yyyy = now.getUTCFullYear();
  const mm = String(now.getUTCMonth() + 1).padStart(2, "0");
  const dd = String(now.getUTCDate()).padStart(2, "0");
  const hh = String(now.getUTCHours()).padStart(2, "0");
  const key = `claude-archive/${yyyy}/${mm}/${dd}/${hh}/${requestId}.json`;
 
  const record = {
    schema_version: "v1",
    request_id: requestId,
    ts: now.toISOString(),
    model: response.model,
    request: maskPII(request),
    response,
    client: { site: "claudelab", version: env.BUILD_VERSION ?? "dev" },
  };
 
  await env.ARCHIVE_BUCKET.put(key, JSON.stringify(record), {
    httpMetadata: { contentType: "application/json" },
    customMetadata: {
      userId,
      model: response.model,
      stopReason: response.stop_reason ?? "unknown",
    },
  });
 
  await env.ARCHIVE_META.prepare(
    `INSERT INTO archive_index
       (request_id, user_id, ts, model, stop_reason, input_tokens, output_tokens, r2_key)
     VALUES (?, ?, ?, ?, ?, ?, ?, ?)`,
  )
    .bind(
      requestId,
      userId,
      now.toISOString(),
      response.model,
      response.stop_reason,
      response.usage.input_tokens,
      response.usage.output_tokens,
      key,
    )
    .run();
}

A subtlety worth understanding: when a Promise inside waitUntil rejects, you'll see the exception in the Workers Logs, but the user-facing response has already gone out. So a partial archive is possible (R2 wrote successfully, D1 failed). I fix the order at "R2 first, then D1" and route D1 failures to a dead-letter Queue keyed by request_id. Having a batch-fixup path is a low-effort insurance policy that pays off after the first quarter of running this in production.

For streaming (anthropic.messages.stream(...)) the archive call moves to after finalMessage() resolves. If the SSE connection drops mid-stream, write what you have with a stream-truncated flag so you can isolate that failure mode in later analyses.

PII Masking: Don't Persist What You Shouldn't Persist

If you intend to keep this archive as an audit log, you have to be deliberate about PII. Consumer-facing apps in particular tend to receive user input with raw email addresses, phone numbers, or even physical addresses inside the prompt. In my wallpaper app, the review-reply assistant sometimes received review text with home addresses embedded; I had to think hard about whether to persist that at all.

Before writing to R2 I run maskPII() over the request:

function maskPII(request: ChatRequest): MaskedRequest {
  return {
    ...request,
    messages: request.messages.map((m) => ({
      ...m,
      content: typeof m.content === "string"
        ? maskText(m.content)
        : m.content,
    })),
  };
}
 
function maskText(text: string): string {
  return text
    // Emails
    .replace(/[\w.+-]+@[\w.-]+\.[A-Za-z]{2,}/g, "<email>")
    // Phone numbers (JP-style and international)
    .replace(/\+?\d[\d\-\s]{8,}/g, "<phone>")
    // 13–16 digit card-like sequences
    .replace(/\b(?:\d[ -]?){13,16}\b/g, "<card>")
    // Stripe session tokens
    .replace(/cs_(?:live|test)_[a-zA-Z0-9_]+/g, "<stripe_session>");
}

The critical mindset here is don't try to be perfect. Perfect PII detection is effectively impossible, and chasing it tends to start eating into the content you actually want to keep. My rule is:

• Mechanically mask things that have structure (emails, phones, card numbers, tokens)
• For unstructured PII (free-form addresses, names inside prose) shorten the retention window instead of masking
• For request flows that involve regulated data (age verification, health-related), set an archive_policy: "skip" flag and never archive at all

That last flag is something I keep on the Worker side, separate from Anthropic's metadata.user_id. If archive_policy === "skip", the Worker doesn't even call archiveResponse.

Replaying an Incident: From a request-id Back to a Reproduction

A concrete walkthrough of how this paid off. One morning I was chasing a wave of intermittent 529s tied to a Cloudflare Queues integration. The dashboard only told me "error rate spiked at this minute." Pulling out what was actually being requested at that minute was where R2 came in.

# 1. Pull request IDs from D1 by time window + stop_reason
wrangler d1 execute claudelab-archive \
  --command "SELECT request_id, r2_key
             FROM archive_index
             WHERE ts BETWEEN '2026-05-24T02:00:00Z'
                          AND '2026-05-24T02:30:00Z'
               AND stop_reason = 'unknown'" \
  --remote --json | jq -r ".result[0].results[] | .r2_key" > keys.txt
 
# 2. Fetch each archived object
while read key; do
  wrangler r2 object get "claudelab-archive/${key}" \
    --file "./pulled/$(basename $key)"
done < keys.txt
 
# 3. Feed them through a replay script
node tools/replay.mjs ./pulled

The replay script reads each JSON, re-sends the request portion, and compares behaviour:

import { readdir, readFile } from "node:fs/promises";
import Anthropic from "@anthropic-ai/sdk";
 
const dir = process.argv[2];
const anthropic = new Anthropic();
 
for (const file of await readdir(dir)) {
  const archived = JSON.parse(
    await readFile(`${dir}/${file}`, "utf-8"),
  );
  const { request, response: original } = archived;
 
  try {
    const replayed = await anthropic.messages.create({
      model: original.model,
      max_tokens: original.usage.output_tokens + 100,
      messages: request.messages,
    });
    console.log(file, "ok", replayed.stop_reason);
  } catch (err) {
    console.log(file, "still-fails", err.status, err.message);
  }
}

What the replay actually told me was that 529s did not reproduce — they were transient backend overload, not a function of the request content. By contrast, stop_reason: "max_tokens" cases reliably reproduced as cutoffs, which led me to raise the limit or add a "respond in N characters" constraint in the system prompt. Being able to separate "reproducible incidents" from "transient ones" was the real win. That separation is impossible without an archive.

A D1 Metadata Index for Fast Lookups

Relying on R2 alone forces every search through LIST, which is a Class A operation and pricey at scale. I keep a small D1 table as the search layer:

CREATE TABLE archive_index (
  request_id   TEXT PRIMARY KEY,
  user_id      TEXT NOT NULL,
  ts           TEXT NOT NULL,
  model        TEXT NOT NULL,
  stop_reason  TEXT,
  input_tokens INTEGER,
  output_tokens INTEGER,
  r2_key       TEXT NOT NULL
);
 
CREATE INDEX idx_archive_user_ts ON archive_index (user_id, ts);
CREATE INDEX idx_archive_ts_stop ON archive_index (ts, stop_reason);
CREATE INDEX idx_archive_model_ts ON archive_index (model, ts);

D1 is inexpensive but not free. I age out rows older than 90 days into a archive_index_history table keyed on r2_key only, so the hot index stays small. D1 becomes the recent and fast index; R2 stays the long-term truth.

Three search patterns cover almost everything you'll do:

1. A user sends a request-id to support — WHERE request_id = ?
2. All recent requests for a user — WHERE user_id = ? AND ts > ?
3. Distribution analytics like "max_tokens cutoff rate by model" — WHERE model = ? AND stop_reason = 'max_tokens' over a window

For analytics queries you'll outgrow D1 eventually and want a periodic export into Workers Analytics Engine or Snowflake. Most indie projects and small SaaS apps never reach that point — D1 is enough.

R2 Cost Math: Class A Operations and Storage

"Archive everything, it's cheap" is half true. R2 has three billing axes and Class A operations (PUT / LIST / DELETE) start to dominate at scale.

Working with R2's general-region pricing as of May 2026 and assuming a million Claude API requests per month:

• Storage: an 8 KB average response × 1M = 8 GB/month, at roughly 0.015 USD/GB → about 0.12 USD/month. Effectively free
• Class A (writes): 1M PUTs at 4.5 USD per 1000 → 4.5 USD/month. This is the dominant cost
• Class B (reads): occasional incident-analysis fetches in the low thousands → noise; even 10K GET/month is roughly 3.6 USD

That's about 10 USD/month for the whole picture. Cheap relative to AdMob revenue but easy to blow past if you LIST aggressively. The classic mistake is "scan the past week of responses for analytics" run daily — that's 168 hour-buckets × multiple LIST calls per bucket per day, and Class A balloons. I avoid it by funnelling all analytics through the D1 index. R2 is the retrieve known keys store, D1 is the discover keys store.

The other lever is lifecycle rules: move objects older than 30 days to Infrequent Access, delete past 90 days, configured via wrangler r2 bucket lifecycle add .... Infrequent Access storage is roughly 60% of standard pricing, and the offsetting higher Class B cost barely matters for objects you rarely read.

Lessons From Actually Running This for Six Months

A few rough edges that only revealed themselves once the design met traffic:

First, R2 is not strongly consistent for LIST. A PUT that succeeded a moment ago may not appear in a LIST call right away. If you write inside waitUntil and then re-check in the same Worker run, you can accidentally double-PUT. I accept the duplicate (same JSON, idempotent overwrite) and monitor the rate instead. Strict consistency would be wonderful, but it isn't necessary for archive use cases.

Second, streaming and client disconnects. If a user closes the tab during messages.stream(), the Worker may exit before finalMessage() resolves. The fix is to consume the stream with for await (const event of stream) and trigger waitUntil(archive(...)) explicitly on event.type === "message_stop". That way the archive write fires even if the HTTP client is long gone.

Third, the prompt cache contents are not part of the archive. The API returns cache_read_input_tokens so you can see how much was reused, but not what was reused. I record the ratio usage.cache_read_input_tokens / usage.input_tokens in D1 as a trend signal and let go of the dream of bit-perfect replays. Anything else leads to over-engineering.

If you're starting from a stock Worker, the smallest meaningful step is to wire archiveResponse(...) into ctx.waitUntil and confirm a day's worth of objects shows up in your R2 bucket. The D1 metadata index can be added later — every record still has a key, so you can backfill from R2 if needed.

For the first six months I ran R2 only, pulling support tickets one object at a time with wrangler r2 object get. Adding the D1 index cut support response times by something like 5×. An archive is more useful as a grow it as you need it habit than as a perfect design up front. If you're running Claude API on Cloudflare and don't have an archive layer yet, I'd start with R2 today, even if the design isn't final. Thanks for reading.