The same key turned up in three groups: internal sharing, resale, or a demo

Signals considered

• The same credential appears across several unrelated groups or downstreams
• The price sits clearly below a calculable upstream cost floor
• The model mix under one key does not match the stated workload

In a few Telegram groups for AI API work you notice the same credential, the kind that starts with sk-. It first appears in a developer group where someone asks whether it still works. Two days later it is posted in another group as a giveaway. By the third group it has been written into a delivery checklist.

The easy explanation is that this client is doing serious volume. That explanation feels good because it converts a problem requiring action into a conclusion worth celebrating.

The short version: a repeated credential is not evidence in any direction on its own. To turn it into a usable judgement you first need that key’s usage detail, then you check it against three sets of traces - usage concentration, price against the cost floor, and concurrency and model mix. Without usage detail, any conclusion can only be labelled a hypothesis.

NOTICE: the credentials, groups, usage figures and prices in this piece are composite illustrations used to demonstrate discrimination logic. They do not represent real clients, transactions, contracts or closed deals.

A repeated credential is not a demand signal yet

Seeing a signal repeatedly feels like it makes it more credible. In most contexts that instinct holds. One message mentioned by several independent sources really does raise confidence that it is true.

Credentials do not work that way.

A message being forwarded repeatedly means many people thought it was worth forwarding. A credential being posted repeatedly means many people hold it. Those two point at entirely different things. One is distribution, the other is possession. And for a credential, widespread possession is precisely the shared appearance of three contradictory commercial facts.

Before you discriminate, check what you actually have

The table below only holds when data exists. So before discussing discrimination, confirm you can get three things:

• The key’s usage curve at hourly granularity, showing request counts and token counts
• The key’s model mix, meaning the share of calls per model
• The key’s peak concurrency and source distribution

Miss one of the three and the table collapses to a single usable row, with a correspondingly weaker conclusion.

There is an easily missed premise here: rate limits attach to the key or the project, not to the client. How many people and downstreams stand behind one key therefore decides how much usable capacity that client actually receives. That is why this judgement deserves care. Getting it wrong does not cost face, it costs capacity.

Three explanations and the traces each one leaves

Put concurrent sharing, secondary resale and channel demos on one table and their divergence concentrates in three sets of traces:

Trace	Internal sharing	Secondary resale	Channel demo
Usage concentration	Clustered in the client’s business hours	Around the clock, including late night	Pinned briefly, then zero
Model mix	Matches the client’s workload	Spans several price tiers	Concentrated on the priciest model
Price versus cost floor	Matches the contract	Clearly below a calculable cost floor	Pricing not involved

The table only lines up the differences. What matters is how each row gets evidenced.

Sharing: usage squeezed into the same hours and the same models

Internal sharing looks plain: usage follows the client’s working hours.

A cross-border commerce client should peak when its own support staff are on shift. A client running automation tasks will have fairly regular batch windows. Several teams sharing one key pile their peaks on top of each other, producing a curve with clear ups and downs but a stable shape, and near-zero volume late at night.

The model mix is narrow too. A team doing support automation will not simultaneously hammer the most expensive reasoning model and the cheapest lightweight one in volume; its usage concentrates in a few models and stays there.

The right response here is capacity planning, not risk control. Since the quota is shared, either split the key or tell the client that several of their teams are competing for one quota. The second option is often more effective than the first, because the client frequently does not know this is happening.

Resale: price, usage and concurrency stop agreeing

Resale is not detected by a single metric. It shows up as three sets of numbers contradicting each other.

Price cracks first. Given public pricing for mainstream general-purpose models, there is a hard floor below which reselling tokens cannot work as a business over time. When someone retails credentials at or below upstream cost, the cash flow behind that offer is not coming from this price list. It usually comes from promotional credits, trial accounts or accounts that have already been terminated.

The usage curve contradicts the stated workload. A client claiming small-team internal use whose late-night request volume matches daytime levels, with no weekend drop, does not match any normal business shape. It matches a key being resold to people in other time zones.

The model mix is abnormally wide. Resold credentials usually open up models across several price tiers. The seller cannot predict downstream needs, so it opens everything it can. A single key covering the entire product line from cheapest to most expensive, with meaningful share at every tier, does not look like one specific business using it.

Peak concurrency and source distribution. One key receiving requests from several geographic regions within seconds largely rules out single-team use. On its own this can mislead, since a client with multi-region edge deployments produces the same shape, so read it alongside the previous three.

Channel demos: pinned once, then gone

Demos are the category most often mistaken for resale, because their usage looks the most aggressive: short bursts at high concurrency that push the quota to its ceiling.

The difference is in the time dimension. Demo usage has a clean endpoint - it runs and never appears again. It does not show weeks of stable curve, nor business-hours rhythm. It looks more like someone accepting a deliverable: confirm it works, then stop.

That difference has practical value. Resale needs handling; a demo does not. Treat one demo as resale and you needlessly offend a channel partner that was about to scale.

Getting the direction wrong does not cost the same either way

The three cases above do not carry equal downside.

Mistake sharing for resale and you lose one ordinary partnership. Mistake resale for sharing and you lose capacity, margin, and a compliance gap that will surface eventually. Mistaking a demo for resale costs mostly in relationships; mistaking resale for a demo costs mostly in operations.

Asymmetry means the default posture should lean cautious, but cautious does not mean acting immediately. A more reasonable order: mark the finding as unverified first, then ask the client one specific question - for example, ask what business explains a particular late-night spike. The more specific the question, the harder it is to answer vaguely, and the clarity of the answer gives you another layer of information.

One counter-warning: do not go question the client’s own customers just because you spotted sharing. What you are verifying is your own capacity and compliance boundary, not auditing your client’s downstream relationships. Cross that line and risk control becomes overreach.

Two situations where this discrimination fails

First, you cannot get usage detail. Either the contract does not cover sharing that data, or the key sits on the client’s own upstream account and you see outcomes but not process. Every row of the table then lacks evidence, and the only honest output is unverified.

Second, the client genuinely carries both traits at once. A channel partner might share internally within its own team while also passing quota to downstreams for trials. Sharing and resale traces appear together, and judging which is the main line by proportion gets closer to the truth than choosing one.

One boundary worth stating clearly: this piece is about inferring usage shape from usage traces. It does not cover how to write the contract clause, nor the legal steps that follow a finding. Those sit outside signal judgement and require someone else to decide.

Further reading

• All those “cheap tokens, every model, stable routes” posts: which one is a real buyer?
• Someone in the group says “200 USD a day, 20 people, launching next Wednesday”. Do you take that deal?
• Stop promising clients “zero bans”: how an AI API reseller builds real trust during upstream throttling

RESEARCH & DEFINITIONS

How a Signal worth attention is found

See how Top Prospect finds and organizes Signals worth checking, keeps the original Telegram context, removes duplicates, and helps you decide what to review first. You decide whether to follow up and what to do next.

Open the methodology and core definitions →