auditing-llm-gateway-parity

Inspect the actual implementation code of both gateways covering routes, auth, billing, rate limits, providers, and event attribution, then classify each contract as supported, blocking, or verify. Record source SHAs from both repositories and update the parity document with the evidence.

Update it whenever either gateway changes auth, attribution, billing, endpoints, providers, models, routing, or metadata, or when reviewing a Python gateway change. In-flight changes should be audited from the working tree or PR branch, not just from master.

No. Matching route names do not prove parity for headers, streaming, errors, timeouts, retries, billing, or emitted events. Both request and response behavior must be checked in the implementation code.

No. An internal workload can migrate with a PostHog-owned team credential when debiting that wallet is the intended attribution method. It is blocked only when it must preserve customer-specific billing policy or debit no wallet.

No. The audit only updates the parity record and identifies caller classes newly eligible to migrate. Caller migration is a separate task handled by the migrating-llm-gateway-callers skill.