News · 2026-09-16

CrofAI investigation alleges requested models were silently routed through OpenRouter

An investigation into CrofAI reports that model names requested by customers repeatedly resolved through OpenRouter to different underlying models. The story matters because the AI supply chain has a trust gap: an API can return plausible text while the customer has no cryptographic or contractual proof that the named model, provider and policy actually executed.

Key facts

• Investigator KTibow reports that CrofAI accepted OpenRouter’s openrouter:advisor server tool and that results identified different model families.
• The report says kimi-k3 labels resolved to GLM 5.3 Flash, while many other labels resolved to DeepSeek V4 Flash.
• The CrofAI owner reportedly acknowledged on September 13 that a “not insignificant amount of traffic” was reaching OpenRouter.
• The primary source is KTibow’s investigation; OpenRouter’s advisor documentation describes the tool mechanism.

The decisive technique was not a vibe-based benchmark. OpenRouter documents openrouter:advisor as a server-side tool that returns advice and identifies the advisor model in a tool result. The investigation used it against CrofAI’s advertised endpoints, then compared response identifiers, prompt-token counts, image-download fingerprints and results across deployments. It also published three GitHub attestations before and after CrofAI deployments. That combination is why the result deserves attention: several independent signals pointed toward an intermediary and different executed models.

The findings are specific, not universal. The report says labels in the kimi-k3 family resolved to GLM 5.3 Flash; greg labels primarily resolved to Kimi K2.7 Code, with greg-1-mini resolving to Qwen3.5 9B; and many advertised labels resolved to DeepSeek V4 Flash. It also says early tests exposed gen- response IDs and some image downloads carried OpenRouter-style infrastructure fingerprints. Those observations support the claim of routing divergence in tested cases. They do not prove that every request, at every time, used the same fallback or that a particular price markup was 20 times; that popular number was not supported and should be discarded.

CrofAI’s recorded response is also part of the story. The report reproduces owner messages saying OpenRouter was an “all hell breaks loose” fallback, then acknowledging substantial traffic reached OpenRouter because of GPU-router and fallback configuration problems. The owner later said one Qwen model was deliberately routed through OpenRouter and named another incorrectly configured fallback. These are reproduced statements, not independently archived telemetry, and later investigator tests reportedly continued to find OpenRouter signals. The ambiguity is not a defense of silent substitution; it is a reason to distinguish a demonstrated routing pattern from a full forensic account.

OpenRouter is not the alleged deception target here; it is the documented intermediary whose tool made the routing visible. Its terms prohibit resale, competing-service development and fraudulent activity, and reserve suspension rights. But the dossier found no public OpenRouter statement saying it suspended CrofAI, and CrofAI appears to be an API customer rather than a model listed in OpenRouter’s catalog. Claims that OpenRouter “delisted” the service would therefore be imprecise.

The security connection is model provenance. In conventional software, a binary’s hash and a signed release provide an identity claim. In hosted AI, customers often receive only a human-readable model label and a bill. A fallback may be legitimate when explicit, but silently replacing a named proprietary model with another model changes capability, privacy expectations, licensing, retention, safety behavior and price. It is like ordering a specific medicine and receiving a different bottle whose active ingredient is not independently inspectable.

The strongest counterargument is that the investigation was conducted by an interested individual who disclosed prior CrofAI help, free tokens and competitor relationships. That is a real reason to scrutinize it. It does not erase the rerunnable attestations, documented advisor behavior and owner acknowledgements. The right standard is neither blind trust in labels nor automatic acceptance of accusations: providers should publish fallback policy, emit a verifiable executed-model identifier, and make audit logs available to customers.

The immediate take-away for builders is contractual and architectural. Treat model identity as a control, not a marketing string. Log provider and model identifiers, disable or require explicit consent for fallbacks in high-risk flows, independently sample outputs where feasible, and insist on data-handling terms that still hold if routing changes. The CrofAI case is not proof that all wrappers misrepresent their backends. It is proof that the present stack makes that kind of misrepresentation difficult for a customer to detect until an external investigator performs a bespoke audit.

Primary source, verified: read the paper →

Ground Truth. (2026, September 16). CrofAI investigation alleges requested models were silently routed through OpenRouter. Ground Truth. https://groundtruth.day/news/crofai-model-routing-investigation.html

@misc{groundtruth:crofai-model-routing-investigation,
  title  = {CrofAI investigation alleges requested models were silently routed through OpenRouter},
  author = {{Ground Truth}},
  year   = {2026},
  month  = {sep},
  url    = {https://groundtruth.day/news/crofai-model-routing-investigation.html}
}

Topics: cybersecurity · ai-security · model-provenance · supply-chain · transparency