"Trust us" isn't enough
When a security review asks "what does this AI gateway actually do to our customers' data?", a Slack screenshot of a redaction rule doesn't cut it. Auditors want to see the request. Customers want to see the request. Honestly, you want to see the request — the one that just went through, with their data in it, transformed exactly how it was transformed.
The traffic log already shows the post-redaction body. That's the right default — it means nothing sensitive sits in your dashboard forever. But it also means you can't easily prove, after the fact, that the redaction worked. You see the redacted version. You don't see what it was redacted from, what got tokenized vs. permanently stripped, or what came back and was restored on the way out.
So we built debug mode.
What it captures
When a request includes the header X-Grepture-Debug: true (or the SDK's debug: true option), Grepture records the full pipeline for that single request:
- Input (raw) — exactly what the caller sent, before anything was changed.
- Redactions — every PII match, tokenization, or find-replace, with
original → replacementmapped one-to-one. - Upstream request — the post-redaction body that was actually sent to the LLM provider.
- Upstream response — the raw response from the provider, before detokenization.
- Final output — what the caller received, with any mask-and-restore tokens swapped back to their originals.
In the dashboard, the request shows up with a small purple bug icon. The detail sheet gets a Debug tab with a side-by-side diff: input vs. upstream on the request path (red = removed, green = added), and upstream vs. output on the response path (showing what got restored). A redactions table underneath maps each transformation. The raw bodies for every stage are scrollable on the same page.
It's the difference between "we redact PII" and "here's the exact email address we redacted from this request, here's the token we replaced it with, here's the response from OpenAI that mentioned the token, and here's the output where we put the address back."
Default off, per-request opt-in
Debug mode is off by default. There's no team-level "enable debug for everyone" toggle and we're not planning to add one. Every captured trace is opt-in, per request — either explicitly via header in a curl, or programmatically via debug: true in the SDK fetch options.
This is deliberate. The captured row contains the pre-redaction content that your PII rules are designed to strip. Keeping that material around in the same conditions as your regular logs would defeat the whole point of having the rules in the first place.
24-hour TTL, never offloaded to cold storage
Two retention properties that matter:
Debug traces auto-delete after 24 hours. Each row carries an expires_at timestamp set 24h from creation. A scheduled job runs every 15 minutes and unconditionally deletes anything past that mark. The retention is fixed — there's no tier upgrade that extends it, no admin override, no "keep this one for a week."
Debug traces are never offloaded to cold storage. Regular traffic logs live in Postgres for your tier's retention window (7/30/90 days) and large bodies are transparently moved to cold storage. Debug traces don't get that treatment — they live in a short-lived store, and when the purge runs, they're gone. No archive, no backup tier, no "we kept a copy just in case." After 24 hours they don't exist anywhere we can reach.
Hard-blocked in zero-data mode
If your team has zero-data mode enabled, debug capture is rejected outright. A request with the debug header gets back X-Grepture-Debug: rejected-zero-data in the response and proceeds normally without capture. The proxy never sees the row.
Zero-data exists so that nothing is retained. Debug exists to retain things. The two are mutually exclusive by construction, not by policy — there's no code path that writes a debug row when zero-data is on.
When to actually use it
Three cases we built it for:
- Demos — a sales call where the prospect wants to see redaction working on their own example data. Flip the flag on for one request, walk through the diff in the detail sheet, the row's gone by the next morning.
- Audits and compliance reviews — "show me exactly what this system does to PII." A debug trace is a more honest answer than a screenshot of a rule.
- Rule debugging — you just shipped a new find-replace pattern and you want to confirm it's matching what you intended without rebuilding your whole dev setup. Send one request with the flag, look at the redactions table, you're done.
For ongoing observability, regular traffic logs are still the right tool. They're already redacted-safe and live for your full retention window. Debug mode is the magnifying glass — sharp, narrow, short-lived.
Try it
Add the header to any proxied request:
curl https://proxy.grepture.com/proxy/v1/chat/completions \
-H "Authorization: Bearer gr_YOUR_KEY" \
-H "X-Grepture-Target: https://api.openai.com/v1/chat/completions" \
-H "X-Grepture-Debug: true" \
-H "Content-Type: application/json" \
-d '{ "model": "gpt-4o-mini", "messages": [...] }'
Or from the SDK, per request or per client:
const res = await grepture.fetch(url, { /* ... */ debug: true });
// Or set it on every call through a client:
const openai = new OpenAI(grepture.clientOptions({
baseURL: "https://api.openai.com/v1",
debug: true,
}));
Open the traffic log, look for the purple bug icon, click in.
- Debug mode reference — header, response codes, retention, zero-data interaction
- SDK debug option — per-request and per-client usage