detect-proxy-shaped-relay-accounts

Detect accounts reselling frontier models through relays using ClickHouse traffic-shape queries.

7|12|Updated Mar 26, 2026
One-click install
npx skills add https://github.com/OpenRouterTeam/docs --skill detect-proxy-shaped-relay-accounts-openrouterteam
Or copy as Structured Prompt for Agent▼
Please help me install this Agent Skill.
Skill: detect-proxy-shaped-relay-accounts
Source: https://github.com/OpenRouterTeam/docs/tree/main/.agents/skills/detect-proxy-shaped-relay-accounts
Command: npx skills add https://github.com/OpenRouterTeam/docs --skill detect-proxy-shaped-relay-accounts-openrouterteam

SYSTEM DOCUMENTATION & REQUIREMENTS

What problem does it solve? Fraud and abuse teams need to find accounts that resell access to US frontier models through relay or proxy gateways, but per-request signals alone produce false positives against legitimate customers. This Skill runs an account-level dominance analysis over ClickHouse generation logs and files survivors as reversible restriction proposals instead of bans. ## Core Features & Use Cases - Account-level signal dominance detection: Flags accounts where relay user agents or Go-client-on-Chinese-cloud egress carry at least 80% of usage in the window, avoiding per-request false positives. - Short-lived vs long-lived cohort separation: Files configured-ring burners and ambiguous long-lived accounts as separate review cases with different confidence levels. - Compromised-key gate: Checks whether a harvested key replayed through a relay explains the traffic before filing, escalating for key revocation instead of restriction when it does. - Use Case: Run a 48-hour sweep over default.generations, subtract already-restricted accounts, and file the survivors as frontier_us_models proposals in Sentinel ban candidates. ## Quick Start Ask the agent to sweep the last 48 hours of traffic for proxy-shaped relay accounts and file the survivors as Sentinel ban candidates.

Frequently Asked Questions about detect-proxy-shaped-relay-accounts

High-intent search queries and answers about installing and using this skill.

FAQPage Schema
How do I detect accounts reselling frontier models through a proxy?▼

Run the proxy-shaped-shortlived.sql query against ClickHouse default.generations with a 48-hour lookback, requiring at least 80% of an account's usage to match relay user-agent or Go-on-Chinese-cloud egress signals. File surviving accounts as frontier_us_models proposals in Sentinel ban candidates.

What signals identify relay or proxy traffic in generation logs?▼

Two signals are used: self-declared relay user agents from known gateway stacks, and Go HTTP client user agents paired with Chinese cloud or telecom egress ASNs. Neither is proof alone, so selection requires account-level dominance rather than individual matching requests.

Why does the sweep separate short-lived from long-lived accounts?▼

Short-lived accounts with uniform lifetime, key count, and spend near round caps indicate a configured ring with higher confidence. Long-lived accounts with broad model use are ambiguous, since a legitimate Go backend on Chinese cloud egress looks identical, so they are filed for review rather than swept.

Does this skill ban detected accounts automatically?▼

No. It proposes a reversible frontier_us_models restriction, never a ban, and never approves or enacts on traffic shape alone. A compromised-key gate runs on every account first, and ambiguous cases stay pending_review for human judgement.

Why do recently restricted accounts reappear in query results?▼

The analytics.stg_restrictions table is a CDC replica that lags recent enactments, so the exclude_restricted filter misses restrictions from the last few minutes or hours. Confirm against the Sentinel ban-candidates list and targets before filing.

What are the limitations of traffic-shape relay detection?▼

User agents are self-reported and trivially spoofed, EU-region traffic is excluded from the sweep, and BYOK relay traffic under-reports spend since OpenRouter records only the BYOK fee. Empty user agents and missing ASNs also make every reported share a slight underestimate.