01 / ENGINEERING CASE STUDY · AI systems
Autonomous Billing Proxy
A FastAPI gateway that separates response delivery from outcome verification and records successful executions in an atomic wallet ledger.
01 / CONTEXT
The problem
An HTTP request can return an empty response, a bot challenge, or irrelevant content and still count as billable traffic. This prototype explores charging an AI agent only after the response is judged useful, while keeping verification off the agent’s response path.
02 / SYSTEM DESIGN
Architecture
Return the response; evaluate the charge separately
- Gemini structured judgment + heuristic fallback
- Failed verification: no charge
- Next.js dashboard: tokens, balance, history
03 / TRADEOFFS
Engineering decisions
Keep verification off the response path
The gateway schedules verification asynchronously so the agent does not wait for model scoring and billing. The current client is fire-and-forget: an unreachable verifier can mean dropped telemetry. That makes a durable queue an important next step before relying on it for revenue.
Asynchronous verification clientMake a charge explainable
Gemini produces structured judgments, with local heuristics available when the model is unavailable. Status, body coherence, and failure signals inform the decision. Scores and proof metadata accompany ledger entries, so a charge can be inspected rather than reduced to an opaque pass/fail.
Structured verification judgeCommit the debit and ledger entry together
A PL/pgSQL function updates the wallet and inserts the transaction in one database transaction, rolling back if the balance is insufficient. The request-hash precheck helps identify repeated executions, but it does not by itself prove safety against concurrent duplicate requests. Stronger idempotency and concurrency tests belong in the next iteration.
Atomic billing functionTreat the gateway as an enforcement boundary
Bearer tokens are stored as SHA-256 hashes. Session checks, request fingerprints, per-developer rate limits, and bounded telemetry constrain what reaches the downstream services. Distributed rate limiting remains a production-hardening task.
Gateway implementation04 / VALIDATION
Evidence & measurement
The source supports the asynchronous gateway, verifier, and atomic billing design. Evaluator tests cover decision logic; they do not establish end-to-end financial correctness or load capacity.
Asynchronous verification
The verification client creates background tasks and logs unreachable-service failures. It does not currently provide durable delivery.
View supporting referenceAtomic wallet + ledger writes
The database function combines wallet debit and ledger insertion in a transaction. Concurrent duplicate handling still needs stronger guarantees.
View supporting referenceEvaluator coverage
The repository includes pytest cases for the verification decision pipeline. The README identifies calibration against real labeled traffic as an open requirement.
View supporting referencePerformance claims: available context
These figures appear in my résumé. Published benchmark conditions are still missing; they should not be read as reproducible results.
| Reported figure | Evidence status | What’s needed |
|---|---|---|
| <50 ms proxy overhead | Résumé-reported; no published run | No direct-versus-proxied baseline, payload sizes, concurrency, deployment hardware, or latency percentiles are published. |
| 100K+ micro-transactions | Résumé-reported; no published load report | No run duration, transaction rate, environment, failure counts, or wallet/ledger reconciliation results are published. |
05 / NEXT ITERATION
What I’d improve next
Implementation references are pinned to repository revision 9943ff1. Performance claims originate in the September 2026 résumé; no new load-test results are claimed here.