A discussion about AI relay stations on Zhihu has brought the once niche developer topic of 'cheap Tokens' to a much broader user base.
Previously, PANews initiated a discussion on Zhihu titled 'What is an AI relay station? What mysteries lie behind cheap Tokens?'. The question was included in the 'Token Economics' roundtable, sparking lively debate on the forum.
The discussion in the answer section did not stop at binary judgments like 'Are relay stations part of the gray market?'. More users were asking several practical questions: Where do the cheap Tokens actually come from? Are the models users access real? Can the relay station see my prompts, code, and API keys? If I only use AI occasionally, is it worth taking this risk?
This shifted the topic of AI relay stations from a 'tool choice' to a broader issue of cost and trust. As AI begins to enter writing, programming, Agent development, and enterprise automation workflows, Tokens are no longer just a billing unit in model documentation; they have become a tangible usage cost felt directly by users.
Beyond Price, Users' First Concern is 'Is the Model Really What It Claims to Be?'
In the Zhihu discussion, one category of opinions that garnered the most attention was not about price itself, but about the authenticity of the models.
In a highly upvoted answer, one respondent compared AI relay stations to 'AI scalpers'. While this analogy carries emotion, it captures users' most intuitive concern: the technical barrier for setting up a relay station is not high, as open-source projects can already handle model routing, key management, balance systems, and OpenAI protocol compatibility. The real challenge isn't building a forwarding service, but obtaining cheap and stable upstream quotas.
Once the upstream source becomes opaque, the model name a user sees may not equal the model actually invoked. The answer section repeatedly mentioned risks like 'model swapping,' 'downgrading,' and 'shadow APIs.' Some users pointed out that in everyday Q&A, the difference between premium and low-cost models isn't always immediately obvious, which ironically creates space for fraud. A user might think they're invoking a flagship model, but in reality, their request could be routed to a lower-cost model, or even have the system prompts mimic the response style of a certain model.
This is also the hardest aspect of cheap Tokens to verify. You can run tests on a fake graphics card, or test the speed of fake bandwidth. However, large language model outputs are inherently random. A model giving a better answer today and a worse one tomorrow doesn't directly prove it was swapped. A relay station could serve the real model during the testing phase and mix in cheaper models during long-term use, making it very difficult for ordinary users to detect.
This type of discussion moves the question from 'Is the cheap price worth it?' to 'Does the user know what they're actually buying?' If the model source cannot be verified, cheap Tokens are not simply a price discount, but a transaction based on information asymmetry.
Relay Stations Aren't Necessarily Cheap; It Depends on the Comparison
Another category of discussion focused on the reference point for cost. Many users noted that relay stations may seem cheap because they often compare themselves to the official API's pay-per-use pricing, rather than to official subscriptions, domestic Chinese models, free tiers, or cloud provider channels.
One response mentioned that for heavy users who fully utilize their official subscription quotas, the unit cost might be lower than some relay stations. Others argued that the pricing of some domestic models is already low enough that for daily development, summarization, translation, and simple coding tasks, routing through overseas model relay stations isn't always necessary.
This perspective doesn't deny the demand for relay stations. Instead, it reminds users to first clarify their own usage patterns. For occasional Q&A, translation, or summarizing public materials, the free tiers of official apps and legitimate tools are often sufficient. For architectural design, code review, or complex reasoning, more powerful models can be used for critical parts, with specific implementations handled by lower-cost models. Relay stations only become a viable option when users truly have sustained, high-frequency, multi-model calling needs.
The perceived low cost of relay stations largely stems from the chosen comparison. Compared to official pay-per-use API prices, they might seem cheap. Compared to subscription plans, domestic models, or free tiers, they might not always be the lowest cost. This viewpoint in the answer section essentially reframes the issue around the user themselves: first assess the need, then evaluate the channel, rather than placing an order just because of a discount.
When the Source of Low Prices is Unpacked, the Cost of Trust Emerges
Regarding where cheap Tokens come from, Zhihu user answers provided various explanations. The milder paths include bulk purchasing, corporate discounts, cloud provider channels, caching, batch processing, and cross-model routing. Theoretically, these methods can allow relay services to maintain profits while offering prices lower than official rates.
However, the discussion more frequently mentioned gray market supply paths: splitting subscription accounts, shared account pools, batch registration to exploit free tiers, regional price arbitrage, refund exploitation, monetizing cloud provider credits, and more aggressive methods like using stolen credit cards or API keys. While different answers didn't fully agree on the severity, they all pointed to one issue: low prices don't come from a single source but are pieced together from a supply pool of multiple channels.
This also explains why it's difficult for users to assess risk. A request today might go through an official channel, tomorrow through a pool of subscription accounts, and the next day, due to upstream account bans, switch to another model. The user sees the same interface, the same model name, and the same balance page, but the backend might be constantly switching.
More measured voices also appeared in the answer section. Some users believed that a 90% discount doesn't necessarily equal a stolen credit card; price reductions could also come from legitimate but opaque bulk discounts, caching, and routing optimizations. This reminder is important. Labeling all relay stations as illegal or fraudulent doesn't explain why the market persists long-term. However, if a platform doesn't clarify its source, limits, failure handling, and data policies, users also struggle to treat it as trustworthy infrastructure.
In other words, low price itself isn't the conclusion, but merely the entry point to the problem. What truly needs calculation isn't just the Token price, but also model authenticity, service stability, balance risk, and data flow.
As the Discussion Escalates to Data Security, Risk Is No Longer Just About 'Dumber Answers'
Data security was another high-frequency topic in the Zhihu answers. Many users are no longer just worried about models becoming 'less intelligent,' but are concerned about whose servers their prompts, code, business documents, and keys pass through.
In ordinary chat scenarios, a relay station at most affects answer quality and billing experience. However, in AI programming, Agent development, and enterprise internal tool scenarios, request content may contain project structures, error logs, database fields, client lists, contract clauses, business plans, and internal meeting minutes. If a relay station logs, retrieves, or resells this content, the risk is no longer just an API bill issue.
Answers from legal and corporate governance perspectives made this issue more concrete. Relevant responses mentioned that when enterprises and professional service organizations use AI tools to handle contracts, case materials, client data, and source code, they need to consider trade secrets, personal information, data cross-border transfer, client confidentiality obligations, and tool reliability. If the calling chain passes through an unidentified relay station, the enterprise would find it difficult to answer questions about whether data is retained, if it's transmitted to third parties, if overseas processing occurs, how long logs are kept, and who can access the backend.
Agent scenarios amplify this risk. Ordinary chat returns text, but an Agent might, based on the model's output, go on to call tools, read files, execute commands, or access links. If a relay station influences the model's returned content, the risk could escalate from 'wrong answer' to 'wrong action.' This is also why the answer section repeatedly emphasized not connecting unknown relay stations to production environments, CI/CD pipelines, internal knowledge bases, and automation tools.
This part of the discussion pushed the issue of relay stations from a consumer-grade tool problem to an enterprise-grade governance problem. For individual users, the risks involve balance, privacy, and experience. For enterprises, risks additionally include procurement compliance, vendor vetting, employees bypassing rules, and liability boundaries after incidents.
The Minimum Consensus Formed in the Zhihu Discussion: It's Usable, But Don't Use It by Default
The discussion didn't yield a simple answer. No one could prove all relay stations are untrustworthy, nor could anyone prove cheap Tokens are definitely safe. The judgment closer to consensus is: relay stations can be used as tools for low-sensitivity, replaceable, interruptible tasks, but they shouldn't become the default entry point for all AI tasks.
For summarizing public materials, simple translation, toy projects, and low-risk testing, small-scale trial use is acceptable. For tasks involving company-private code, production logs, client data, contracts, finance, investment materials, or data from sensitive industries like healthcare and law, they should not be handed over to unknown relay stations. When involving Agents and automated execution, extra caution is needed regarding tool calls, file reading, and key exposure.
Many users in the answer section also gave similar usage advice: don't top up large amounts; don't lock your entire workflow to a single relay station; keep official APIs, domestic models, or legitimate aggregators as backup routes; use fixed test questions to periodically sample model quality; anonymize or summarize data where possible; and do not integrate relay stations into the company's production chain.
This advice may sound uncomplicated, but it is more valuable than 'recommending a specific platform.' The temptation of cheap Tokens lies in lowering the entry barrier, but the real cost of AI use isn't just written on the price list. Model authenticity, data flow, service stability, balance risk, and compliance responsibilities all exist beyond the price.
Under the 'Token Economics' Roundtable, Relay Stations Are Just One Aspect
This is also the significance of including this question in the 'Token Economics' roundtable.
In the context of cryptocurrency, Tokens are often discussed as assets, incentives, and governance tools. In the AI context, Tokens are more like a measurable production cost. They determine how frequently users can use models, whether developers can integrate AI into workflows, and whether enterprises are willing to include model calls in long-term budgets.
The reason AI relay stations sparked heated debate is not because they are particularly novel, but because they brought this sense of cost directly to users. When model capabilities are priced per Token, it's difficult to simultaneously satisfy cheapness, stability, safety, and accountability. What users are truly worried about is not just whether there's a mystery behind cheap Tokens, but how much trust they are surrendering to save on a few calling fees.
Relay stations will likely continue to exist long-term. They solve real pain points regarding access, payment, pricing, and multi-model integration. However, this Zhihu discussion has already provided a clear reminder: the easier AI capabilities are to obtain, the more users need to know where their requests pass through, where the models come from, and what data is left behind.
