ProofRoute AI
Adaptive AI routing,x402 payment,ZK accountability
About
The problem it solves Most AI products force a bad tradeoff: - If you send full prompts to cloud models, you risk exposing sensitive data. - If you avoid cloud models, you lose access to high-quality AI help. - If you use subscription-based plans, you often overpay when usage is low. - If you choose models manually, you can waste budget or get weaker results. **AI Router** solves this by combining privacy, pay-as-you-go billing, adaptive model selection, and cryptographic accountability. **What people can use it for** - **Sensitive AI workflows** (legal, finance, healthcare, internal ops) where raw text should not leave the device. - **Developer/copilot workflows** where API keys, passwords, or wallet addresses can appear in prompts. - **Cost-controlled AI usage** with **x402 USDC micropayments** (no mandatory subscription; pay per request). - **Smarter model usage** via adaptive orchestration (tier + speed/quality preference + domain + capability constraints). - **Auditable AI operations** with Groth16 proofs and on-chain verification on Base Sepolia. Use of AI tools and agents The system uses multiple AI components that cooperate in a pipeline: **Edge privacy/analysis layer (local)** Regex + Presidio detect sensitive entities. Text is masked into placeholders before cloud calls. A reversible mask map is retained for safe post-response restoration. **Adaptive orchestration layer** The app sends routing metadata (tier, speed/quality weight, domain, thinking/web-search needs, context length) to the gateway. The gateway selects the most cost-effective provider/model for that request. **Cloud model execution layer** Selected providers (Anthropic/OpenAI/DeepSeek/Gemini) process only masked content. Responses are returned and placeholders are restored locally for natural UX.
How it's made
Challenges we ran into 1) **x402 settlement timing vs. usage logging** A key hurdle was that x402 settlement data (tx hash) is available after the request handler returns. I solved this by recording usage first, then patching the latest record inside onAfterSettle, so each usage item can be bound to a real payment tx before proof generation. 2) **Startup reliability with payment middleware** x402 route configuration can fail asynchronously (facilitator/network issues), which can crash or destabilize startup. I handled deferred errors explicitly and configured middleware to avoid blocking startup when the facilitator is temporarily unavailable, with clear dev-mode fallback behavior. 3) **PII false positives vs. usability** Contextual PII detection can over-mask useful context. I tuned Presidio thresholds and added guardrails (for example, only mask LOCATION when it looks like a specific street address), then merged detections with regex results by severity to keep protection strong without destroying prompt utility. 4) **Keeping routing resilient** If server-side routing is unavailable, the app still needs to function. I added local fallback routing so users can continue working even when POST /route is unreachable.