ZevRouter trial guide
A product guide for deciding whether ZevRouter is a valid small API trial: OpenAI-compatible usage, readable receipts, direct-provider cost basis, and ZEV City's three positive loops for clean-energy participation in one path.
ZevRouter is ZEV City's hosted OpenAI-compatible API router at router.zev.city. It is meant to be tested first with a supported model and a small non-critical workload, not as an immediate full replacement for a broad model marketplace.
The useful question is whether one small trial gives enough API behavior, cost visibility, receipts, and clean-energy record visibility to justify continuing with supported workloads.
A good first test is a bounded developer check, not a migration decision. Keep your current provider or OpenRouter route active while you inspect the ZevRouter path.
Start with a model currently shown on the ZevRouter model catalog or trial entry. Broad unsupported routes should stay on OpenRouter or direct providers.
This guide states the bounded trial scope. A first test should use one model that is currently available to the tester in the ZevRouter product UI.
A small trial should judge one supported request's answer quality, latency, cost, receipt, and record trail before any larger workload.
AI API usage is becoming a new energy demand. ZevRouter is ZEV City's experiment in turning ordinary AI service margin into user-visible clean-energy participation, starting with small, checkable receipts before asking anyone to trust a larger claim.
This is not framed as a one-time carbon-offset label. The product direction is an ongoing relationship between usage and participation: users can inspect receipt math, cost basis, credits, selected participation path, clean-energy destination, reviewer hashes, and settlement records as those layers mature.
ZevRouter should therefore be evaluated as the AI-usage entry point into ZEV City's three positive loops: an energy loop, a participation/reward loop, and a community-impact loop.
The core question is not only whether ZevRouter can route one API call. It is whether AI usage can become a repeatable participation path where usage records, clean-energy records, and community project choices reinforce each other over time.
A small AI top-up can create inspectable receipt, provider-cost, service-uplift, allocation, destination, reviewer, and settlement records. Current evidence is strongest for receipts, Base registry anchoring, Reading solar context, and PUNL school-solar context.
The API-credit path currently records $2 clean-energy participation per $100 provider-credit basis. The energy-participation path records $4 total, including $3 user-facing energy participation and $1 ZEV reserve. These are participation records, not cash redemption promises.
The long-term model lets users and communities help steer clean-energy destinations. Current governance, voting, and project-choice mechanisms should be treated as future reviewed layers that need eligibility rules, anti-abuse review, and operator approval before being described as production governance.
The fair evaluation standard is practical: judge the current router on API behavior, cost visibility, receipt clarity, and whether these three loops are becoming verifiable instead of only being stated as a mission.
OpenRouter is treated as backend fallback only when used and should be recorded separately.
The current operator-controlled beta receipt journey turns this into a user-inspectable path.
The API-credit path directs $2 toward clean-energy participation records. The energy-participation path directs $4 total toward clean-energy participation records, split into $3 user-facing energy participation and a $1 ZEV reserve record.
The relevant questions are: does usage create a clear energy record, does the user see a participation path, and can project choice become reviewable instead of opaque?
ZevRouter's clean-energy participation records point to real ZEV City surfaces, not only abstract JSON. Current public context includes a Reading-area residential solar + battery generation surface and Power Up North London school-solar participation context.
Daily and realtime feeds make the generation context inspectable. A reviewed allocation record is the next stronger proof layer.
The public surface references Power Up North London school-solar participation, including Camden schools such as Parliament Hill School and Regent High School.
The registry records hashed payment, provider-cost, destination, allocation, reviewer, user-choice, and settlement fields for AI top-up allocation commitments.
Inspect the field reference at request-receipt-sample.json, then compare it with the receipt generated by the user's own trial request.
For now, treat latency and success as trial observations. Longer uptime, p95 latency, and incident history remain confidence milestones.
The practical question is whether the first request is inspectable enough to justify the next supported workload.