In the path of every prompt
Promptster captures candidate workflow through two complementary surfaces: an Anthropic-API proxy that sees every prompt and response, and Claude Code hooks that capture the operational layer. Here's how it fits together — and why.
For a stretch this winter, we described what Promptster does as "MCP-based process telemetry." It was close enough to be useful and wrong enough to be worth correcting in public.
The capture mechanism isn't MCP. It's a proxy plus hooks. The combination is what makes process telemetry work, and it's worth being precise about which surface does what — because the difference is also why incumbents can't retrofit this with a feature ship.
Two surfaces, one timeline
When a candidate runs our installer, the CLI does two things at once.
It points Claude Code's ANTHROPIC_BASE_URL at a Promptster proxy and ANTHROPIC_API_KEY at a per-session token. From that moment, every prompt the candidate sends and every response the model returns flows through us. We forward to Anthropic with the resolved upstream key, pipe the streaming response back, and log both turns of the conversation. The proxy sees the system prompt, the tool definitions, the model and sampling params, and the full assistant message. There is nothing about the conversation surface that's hidden from us.
It also installs Claude Code hooks for PreToolUse, PostToolUse, UserPromptSubmit, Stop, and Notification. Each fires on the candidate's machine, buffers events, signs them locally, and streams them up. The hooks fill in the operational surface the proxy can't see: tool calls, file diffs, commands, lifecycle markers, paste and pause cadence.
Together they produce one timeline, source-tagged. source: 'proxy' for the conversation. source: 'hook' for the workflow. One event schema, one ordering, one replay.
Why the proxy is the right primary surface
A capture mechanism that lives inside an agent only sees what the agent shows it. A capture mechanism that lives in the network path sees the conversation as the model sees it. The proxy gives us four things hooks alone cannot:
Full request fidelity. The system prompt, the tool schemas, the temperature, the model. These don't surface through hooks because hooks are not the protocol the model speaks. They surface through the API. If you want to score "did the candidate scope this problem before solving it," you need to see the system prompt and the tool list the model was given. The proxy is where that lives.
Streaming responses. Claude Code uses SSE. You can't reliably reconstruct an SSE stream from after-the-fact hook events; the model's chain of thought, partial tool calls, and intermediate text don't get replayed, only the final state. The proxy pipes the stream and records it as it happens.
Billing on a meter we control. Tokens, cost, model, billing source — written at the proxy, not derived. maxBudgetUsd is enforced as a gate on the request path. A candidate who blows past the cap gets a 429 with a friendly message at the moment of overage, not after the fact when a webhook reconciles. For an HR team running 100 take-homes a quarter, predictability beats a refund.
BYOK without architecture changes. Engineering orgs that hire at scale don't want their candidate cost on our invoice. We support per-org Anthropic keys with three modes per assessment — platform key, org default, per-assessment BYOK — and the candidate's experience doesn't change. The proxy resolves the upstream key per request. The org's quota, pricing, and rate limits apply natively. Hooks have no equivalent — there's no "use your own key" for a hook.
What signing buys you
Every event the CLI uploads, hook or proxy-derived, is signed with a per-session Ed25519 key generated on the candidate's machine. The private key never leaves the laptop. Each signature includes a hash of the previous event's signature, so any edit — adding an event, changing a timestamp, removing a moment that didn't go well — breaks the chain at the point of edit.
promptster verify walks the chain offline. Output is chain verified or the index of the broken link. No network call, no trust in our infrastructure, no trust in the customer's pipeline. The candidate's laptop is the root of trust the same way Sigstore signs at build time and not at distribution.
For the procurement officer asking "how do you prove this transcript wasn't doctored," that answer has to exist before the conversation starts. With cloud-only capture, it doesn't.
What we don't capture
Worth being explicit. The proxy fires on the candidate's coding session. The hook fires on Claude Code's tool surface. Neither reads the rest of the laptop. Neither watches the browser. Neither captures keystrokes outside the agent. The consent screen, which a candidate sees before the session begins, lists every event type we capture and every one we explicitly don't. Redaction tooling is built in.
Process telemetry has to be honestly bounded or it tilts into surveillance. The proxy and the hooks together let us draw a clean line: this is what happened inside Claude Code, signed and replayable. Nothing else.
Why incumbents can't retrofit this
Browser-based assessment platforms shipped AI features by bolting a chat pane onto a sandboxed IDE. The architecture they built years ago — candidate codes inside our environment, we record what happens — is the ceiling of what they can observe. They don't sit in front of the model. They don't capture native tool calls in the candidate's real shell. They don't sign at the source.
Adding a proxy to a sandboxed IDE is not a feature. It's an architecture change that admits the sandbox was the problem. That's a hard move to make for a company whose entire moat is the sandbox.
Sitting in the path of every prompt isn't a vibe choice. It's the choice that lets us actually see the workflow, prove what we saw, and meter what we use. We expect the incumbents to make noise about real-environment capture before they ship it. We don't expect them to ship it soon.
That's the bet we're making. So far the architecture has earned it.