A question about the AI relay station on Zhihu brought the topic of "cheap Tokens," which was originally a niche topic mainly for developers, to a broader audience.

PANews previously initiated a discussion on Zhihu titled, "What is an AI Relay Station and what hidden logic is behind cheap Tokens?" This question was included in a roundtable on "Token Economics," and the topic sparked enthusiastic discussions on the forum.

The discussions in the answer section did not stop at the binary judgment of whether "the relay station is a gray industry." More users were asking several more practical questions: Where do cheap Tokens actually come from? Are the models the users are switched to real? Can users see their prompts, codes, and keys at the relay station? If someone only occasionally uses AI, is it worth taking this risk?

This shifted the topic of the AI relay station from "tool selection" to a broader issue of cost and trust. As AI starts to enter writing, programming, Agent, and enterprise automation processes, Tokens are no longer just billing units in model documentation, but direct costs that users can perceive.

Beyond cheapness, users' primary concern is "Are the models real?"

In the Zhihu discussion, the most focused viewpoint was not about the price itself but about the authenticity of the models.

In a highly-upvoted answer, a contributor understood the AI relay station as an "AI version of ticket scalpers." Although this statement carries emotion, it captures the users' most intuitive worry: the technical barrier of the relay station isn't high; open-source projects can already accomplish model routing, key management, balance systems, and compatibility with OpenAI protocols. The real difficulty is not setting up a forwarding service but obtaining cheap and stable upstream credits.

If the upstream sources are opaque, the model names that users see may not equate to the models being actually called. The answer section often mentions risks such as "model swapping," "downgrading," and "shadow APIs." Some users believe that in ordinary Q&A contexts, the differences between high-end models and low-cost models are not always visually distinguishable, which leaves room for fraud. Users may think they are accessing flagship models, but they could be routed to lower-cost models, or even have their responses disguised as the style of a certain model by the system's prompts.

This is also where cheap Tokens are hardest to verify. Buying fake graphics cards can run tests, and purchasing fake bandwidth can test speeds, but the output of large models is inherently random. The same question may receive a better answer today and a worse one tomorrow, which does not directly prove that the model was switched. As long as the relay station provides the real model during the testing phase and mixes in low-cost models during long-term use, ordinary users find it hard to notice the difference.

This discussion advanced the question from "Is cheap worthwhile?" to "Do users know what they have purchased?" If the source of the models cannot be verified, then cheap Tokens are not merely a price discount but a transaction characterized by information asymmetry.

The relay station isn’t necessarily cheap; it depends on what it's compared to

Another type of discussion focused on cost benchmarks. Many users pointed out that the relay station seems cheap because it often compares itself to the official API's per-unit pricing, rather than to official subscriptions, domestic models, free quotas, or cloud vendor channels.

Some answers mentioned that heavy users may achieve lower unit costs than some relay stations by fully utilizing official subscription quotas. Others believe that some domestic model prices are already low enough; routine development, summarization, translation, and simple coding tasks may not necessarily need to route through overseas relay stations.

This perspective does not deny the demand for relay stations. On the contrary, it reminds users to first confirm their usage patterns. For occasional Q&A, translation, and summarizing public materials, the free quotas of official applications and legitimate tools are often sufficient; for architecture design, code review, and complex reasoning, stronger models can be used in critical areas while low-cost models handle specific implementations. Only when users have persistent, frequent, and multi-model calling needs might relay stations enter the consideration range.

The feeling of low prices at the relay station largely comes from the choice of comparison targets. Compared to the official API's per-unit price, it might appear very cheap; compared to subscription plans, domestic models, or free quotas, it may not always be the lowest cost. This viewpoint in the answer section effectively brings the issue back to the users themselves: assess the needs first, then evaluate the channels, rather than picking up discounts indiscriminately.

When cheap prices are examined, the cost of trust emerges

In response to where cheap Tokens come from, Zhihu users provided multiple explanations. One milder pathway is bulk purchasing, corporate discounts, cloud vendor channels, caching, batch processing, and cross-model routing. Theoretically, these methods can allow relay services to still make a profit while being priced lower than official pricing.

However, what was brought up more often in discussions were gray supply paths: splitting subscription accounts, sharing account pools, bulk registrations to utilize free quotas, regional price differences, refund arbitrage, cashing out cloud vendor bonuses, and more aggressive tactics like black cards, theft, or misuse of API Keys. Different answers may not fully agree on the criteria for judgment, but they all point to one issue: low prices do not have a single source but come from a patchwork of multiple supply channels.

This also explains why users find it hard to assess the risks. A request might go through official channels today, switch to a subscriber pool tomorrow, and be redirected to another model the day after due to upstream account closures. Users see the same interface, the same model name, and the same balance page, but in the backend, there may be constant switches.

There were also more restrained voices in the answer section. Some users believe that a price cut does not necessarily equate to a black card; the price drop could also stem from legitimate but opaque bulk discounts, caching, and routing optimizations. This reminder is crucial. Labeling all relay stations as illegal or fraudulent does not explain why the market has long existed; however, if platforms do not clarify sources, limits, fault handling, and data policies, users will find it difficult to regard them as trustworthy infrastructure.

In other words, low prices themselves are not conclusions but entry points to the issues. What truly needs to be assessed is not just the Token price but also model authenticity, service stability, balance risks, and data flows.

As discussions escalate to data security, risks are no longer just about "dumbed-down responses"

In Zhihu answers, data security emerged as another frequent theme. Many users are no longer just worried about whether the models "dumb down" but are concerned about whose servers their prompts, code, business documents, and keys have passed through.

In ordinary chat scenarios, the relay station could at most affect answer quality and billing experience. But in AI programming, Agents, and enterprise internal tool scenarios, request content may include project structures, error logs, database fields, client lists, contract terms, business plans, and internal meeting minutes. If the relay station records, retrieves, or sells this content, the risk extends beyond just an API billing issue.

Responses from legal and corporate governance perspectives put this issue in more concrete terms. Relevant answers note that businesses and professional service institutions using AI tools for handling contracts, case materials, client data, and source code need to consider trade secrets, personal information, data exports, client confidentiality obligations, and tool reliability. If the invoking chain passes through an unidentified relay station, it becomes challenging for businesses to answer questions regarding data retention, third-party transmission, foreign processing, log retention duration, and who has access to the backend.

Agent scenarios could amplify these risks. Normal chat returns text, but Agents may continue to call tools, read files, execute commands, or access links based on the model outputs. If the relay station influences the returned content, risks may escalate from "incorrect answers" to "execution errors." This is also why the answer section repeatedly emphasizes not integrating unknown relay stations into production environments, CI processes, internal knowledge bases, and automation tools.

This part of the discussion shifts the perspective of relay stations from consumer-grade tool issues to enterprise-grade governance issues. For individual users, the risks are balance, privacy, and experience; for businesses, the risks also encompass procurement compliance, supplier review, employee circumvention, and the boundaries of responsibilities after incidents.

The minimum consensus formed in Zhihu discussions: usable, but don't use by default

The discussions did not yield a simple answer; no one can prove that all relay stations are untrustworthy, nor can they prove that cheap Tokens are necessarily safe. A closer consensus is that relay stations may serve as tools for low-sensitive, substitutable, and interruptible tasks, but they should not become the default entry for all AI tasks.

Summarizing public materials, simple translations, toy projects, and low-risk tests can be tried with a small amount. However, for sensitive data involving proprietary company code, production logs, client data, contracts, financial materials, and medical legalities, they should not be entrusted to unidentified relay stations. When it comes to Agents and automation execution, extra caution is warranted regarding tool calls, file access, and key exposure.

Many users in the answer section also provided similar usage advice: do not top up large amounts; do not tie all workflows to one relay station; maintain official APIs, domestic models, or legitimate aggregators as backup lines; regularly check model quality with fixed test questions; anonymize when possible, summarize when possible; do not integrate relay stations into the company's production chain.

These suggestions seem uncomplicated but are more valuable than simply "recommending a particular platform." The allure of cheap Tokens lies in their lower entry barriers, but the true costs of AI usage are not merely reflected in the price list. Model authenticity, data flow, service stability, balance risks, and compliance responsibilities all exist beyond the price.

In the Token Economics roundtable, the relay station is just one facet

This is also the significance of the "Token Economics" roundtable including this issue.

In the context of cryptocurrencies, Tokens are often discussed as assets, incentives, and governance tools; in the context of AI, Tokens appear more like measurable production consumption. They determine how frequently users can utilize models, whether developers can incorporate AI into workflows, and whether enterprises are willing to incorporate model calls into their long-term budgets.

The AI relay station has sparked heated discussions not because of its novelty, but because it puts this sense of cost in front of the users. When model capabilities are priced per Token, it is challenging to satisfy cheapness, stability, safety, and accountability simultaneously. What users are genuinely worried about is not just the hidden logic behind cheap Tokens, but how much trust they relinquished to save on calling fees.

The relay station may still exist for the long term. It addresses real pain points of access, payment, pricing, and multi-model integration. However, this Zhihu discussion has issued a clear reminder: the easier AI capabilities are to obtain, the more users need to know where requests pass through, where models come from, and what data is left behind.

免责声明：本文章仅代表作者个人观点，不代表本平台的立场和观点。本文章仅供信息分享，不构成对任何人的任何投资建议。用户与作者之间的任何争议，与本平台无关。如网页中刊载的文章或图片涉及侵权，请提供相关的权利证明和身份证明发送邮件到support@aicoin.com，本平台相关工作人员将会进行核查。