model-forensics open source: Verify a model’s true identity with a single command

The GPT-4o You Called — Is It Really GPT-4o?

This question has circulated among developers for quite some time, but a reliable verification method has been lacking. Recently, developer sup194 open-sourced model-forensics on GitHub — a command-line tool specifically designed to check whether model API providers are being deceptive. After debuting in the LINUX DO community, the project quickly sparked discussions, striking a nerve among many developers who depend on third-party relay services.

Project link: https://github.com/sup194/model-forensics

In simple terms, this tool does one thing: helps you verify whether the model you’re paying to use is actually the one it claims to be.

Industry Context: The Gray Zone of Relay Services

First, let’s talk about why such a tool is needed.

When domestic developers call overseas large-model APIs, they usually go through relay services or aggregator platforms instead of connecting directly to the official endpoint. This middle layer does have value — it solves network accessibility issues, unifies interface formats, and reduces integration cost.
But it also naturally has the ability to tamper with things.

Common tricks include:

• Mislabelling products: You think you’re calling GPT-4o, but the backend is actually running GPT-4o-mini or a cheaper model; the reseller pockets the price difference.
• Model mixing: A single API endpoint may not be consistently tied to one model, instead dynamically switching based on load and cost.
• Silent downgrades: Initially uses the official model, but after user volume grows, secretly replaces it with a low-cost alternative.

These operations are almost imperceptible to the end user. You call an API, get back a JSON with the same format, the model field says gpt-4o, but the actual inference quality could be one level worse. For ordinary prompts, the differences are subtle and hard to notice.

It’s like ordering a bottle of 1982 Lafite at a restaurant, but being served a domestic dry red from last year with a swapped label — most people wouldn’t taste the difference, but you certainly paid more.

Previously, verifying model authenticity relied on crude methods — sending tricky prompts to observe style or running benchmarks to compare scores. These were either too subjective or too heavy for everyday use.
model-forensics aims to make this process engineering-based and automated.

Detection Logic of model-forensics

The tool’s core detection logic has two layers, both quite clear.

Layer 1: Anomaly Screening

It sends requests to the target model using a set of carefully designed test cases and observes anomalies in the returned results. These cases aren’t random prompts; they’re “probes” tailored to known behavioral traits of different models.

For example, different models behave differently under certain edge conditions:
some refuse certain types of prompts;
some exhibit unique token counting patterns;
some have distinctive system prompt handling.
These differences act like fingerprints to distinguish models.

This layer requires no local reference data and works out-of-the-box — great for quick, preliminary screening.

Layer 2: Fingerprint Matching

For more conclusive evidence, you can use the official API to build a local reference fingerprint database, then compare results from the relay service against it — like collecting the “authentic” DNA sample and doing a paternity test with the “suspect” sample.

Fingerprints are stored locally in an SQLite database, allowing multiple samples and historical comparison. You can even run periodic checks to see if a provider’s model behavior is drifting over time — a sudden change usually means the backend was swapped.

Getting Started

model-forensics is a standard CLI tool, designed with simplicity. It has just three subcommands: inspect, profile, and compare.

Quick Screening (No Local Fingerprint)

The simplest usage: run a detection on the target API directly:

mforensics inspect examples/targets.yaml

targets.yaml defines your targets — API endpoint, model name, API key, etc. The tool automatically runs all test cases and outputs an anomaly report.

Perfect for “I just want to quickly check if this relay feels trustworthy.”

Build Official Fingerprint + Precise Comparison

If you have access to the official API, first build a baseline fingerprint:

mforensics profile examples/reference.yaml \
  --save-as gpt-4o-official \
  --db data/model-forensics.sqlite

This runs the full test suite via the official API, stores the results in a local SQLite database, labeled as gpt-4o-official.

Then test the same-named model from the relay:

mforensics inspect examples/targets.yaml \
  --db data/model-forensics.sqlite \
  --out reports/run-001

The tool automatically compares detection results with local fingerprints and outputs a similarity report. If the deviation exceeds the threshold, you can safely conclude that the backend isn’t what it claims to be.

Historical Comparison: Catch “Stealth Swaps”

This is perhaps the most practical feature. You can diff results from the same provider across time:

mforensics compare <run-id-a> <run-id-b> \
  --db data/model-forensics.sqlite

Say you ran a check last month and again this month — comparing them reveals if the model’s behavior changed significantly.
If a provider claims to always offer Claude 3.5 Sonnet but the fingerprints differ greatly, then either the upstream model was updated or the provider tampered with the backend.

Combined with scheduled tasks (cron jobs), you can build a continuous monitoring system to periodically audit key providers.

Technical Highlights

Although the project is still early-stage, its design shows several smart choices:

1. Decoupled test cases and detection logic — Test cases are defined via YAML, detection logic is separate. The community can contribute new cases to cover more models or edge scenarios without touching the core code. As models evolve, detection methods must iterate too — making this modular and pluggable is a wise choice.
2. Local storage via SQLite — Lightweight, zero dependency, single file; ideal for a CLI tool. You don’t need to install a database — results are stored locally, ready for query, comparison, or export.
3. Customizable report output paths — The --out flag lets you store results in chosen directories for version control. Combined with Git, managing historical changes in reports becomes a neat workflow.

Limitations and Caveats

Now for the downsides.

First, the accuracy of fingerprint detection heavily depends on the quality and coverage of test cases. Currently, the built-in test set is limited — distinguishing similar models (e.g., different sizes of the same family) might be difficult. For instance, GPT-4o vs. GPT-4o-mini show subtle differences in many normal scenarios, requiring carefully crafted probes to reliably tell them apart.

Second, models evolve. OpenAI, Anthropic, and Google periodically update model weights, meaning an official “fingerprint” isn’t static. A reference made last month might already be outdated today, requiring regular updates and maintenance effort.

Third, detection consumes API quota. Each inspect or profile sends multiple requests — if test cases or targets are numerous, token costs add up. For individual developers, that’s extra expense.

Lastly, the tool can tell you “the model doesn’t match,” but not exactly which model it is using. It’s more of an alarm — flags “something’s wrong,” but further analysis is needed to identify what.

Why This Matters

At a broader level, model-forensics touches the fundamental issue of trust in the AI API supply chain.

As more applications are built atop large-model APIs, API quality and consistency become infrastructure-level concerns. Your RAG system, your agent workflows, your code-generation pipeline — all depend on underlying model capability. If that layer is swapped, the upper layers behave oddly, often in hidden and hard-to-diagnose ways.

It’s analogous to software supply chain security. When you npm install a package, you trust its contents match its claims — but incidents like left-pad and ua-parser-js poisoning proved such trust shouldn’t be blind.
The AI API supply chain likewise needs verification mechanisms.

model-forensics is still an individual project with limited functionality and maturity, but the direction is right — we need tools to verify API supply chain integrity, not just supplier promises.

For developers using relay services, here’s my advice:

1. Run detection regularly on model APIs your core business relies on — even a simple inspect helps.
2. If possible, maintain a local fingerprint library of official models as reference.
3. Pay attention to longitudinal changes — trends over time matter more than one-off checks.

Of course, choosing reliable API providers is the best way to reduce risk from the root. Platforms like OpenAI Hub (openai-hub.com), which aggregate official sources directly, offer better consistency. Combined with model-forensics for cross-verification, you can establish a trustworthy call chain.

If You Want to Implement Similar Logic via API

Beyond model-forensics itself, its detection approach can be integrated into your own monitoring system.
The core idea: for the same prompt, call both the official API and the target API, then compare result characteristics.

Here’s a simplified example using OpenAI Hub’s compatible interface to compare official and target models:

import openai
import json

# Use OpenAI Hub to call the official model as reference
official_client = openai.OpenAI(
    api_key="your-openai-hub-key",
    base_url="https://api.openai-hub.com/v1"
)

# The relay service to be tested
target_client = openai.OpenAI(
    api_key="your-target-key",
    base_url="https://api.some-reseller.com/v1"
)

# Design a set of probe prompts
probes = [
    {"role": "user", "content": "Repeat exactly: 'FINGERPRINT_CHECK_001'"},
    {"role": "user", "content": "What is 17 * 23? Reply with only the number."},
    {"role": "user", "content": "List the first 5 prime numbers, comma-separated, no spaces."},
]

def collect_fingerprint(client, model_name, probes):
    results = []
    for probe in probes:
        resp = client.chat.completions.create(
            model=model_name,
            messages=[probe],
            temperature=0,
            max_tokens=50
        )
        results.append({
            "probe": probe["content"],
            "response": resp.choices[0].message.content,
            "usage": {
                "prompt_tokens": resp.usage.prompt_tokens,
                "completion_tokens": resp.usage.completion_tokens
            },
            "model_reported": resp.model
        })
    return results

# Collect fingerprints
official_fp = collect_fingerprint(official_client, "gpt-4o", probes)
target_fp = collect_fingerprint(target_client, "gpt-4o", probes)

# Simple comparison
for i, (o, t) in enumerate(zip(official_fp, target_fp)):
    match = o["response"].strip() == t["response"].strip()
    token_diff = abs(o["usage"]["completion_tokens"] - t["usage"]["completion_tokens"])
    print(f"Probe {i+1}: content_match={match}, token_diff={token_diff}")
    if not match:
        print(f"  Official: {o['response'][:80]}")
        print(f"  Target:   {t['response'][:80]}")

This is just the simplest comparison logic. In production, you’d need to consider multiple samples for statistical distributions (since even temperature=0 can produce minor variations), extract more dimensions (response latency, token probability distribution, etc.), and define anomaly thresholds.
model-forensics already systemizes much of this engineering — worth referring to.

Final Thoughts

Model counterfeiting won’t disappear anytime soon. As long as information asymmetry and profit margins exist, someone will game the system. model-forensics can’t solve this entirely, but it gives developers a handy verification tool.

The power of open source lies in one person defining the problem clearly, building the basic framework, and allowing the community to extend test cases, detection strategies, and model coverage collaboratively.
Hopefully, the project continues to evolve — and pushes relay providers toward greater transparency.

After all, trust shouldn’t be built on “You wouldn’t catch me anyway.”

---

References:

• model-forensics GitHub Repository — Source and documentation
• LINUX DO Community Post: “See Which Relays Are Faking! A Fully Open-Source Model Detection Project!” — Project launch and community discussion