---
type: "post"
id: "open-source-lm-fingerpoint-detector-identifies-which-llm-369327"
slug: "open-source-lm-fingerpoint-detector-identifies-which-llm-369327"
title: "Open-source LM Fingerpoint Detector identifies which LLM sits behind an API from its 'random number' distribution"
description: "Ikaleio has released LM Fingerpoint Detector, an open-source utility that estimates which language model may sit behind an API endpoint by comparing its numerical-response distribution with a reference bank."
retrieval_nugget: "Ikaleio has released LM Fingerpoint Detector, an open-source utility that estimates which language model may sit behind an API endpoint by comparing its numerical-response distribution with a reference bank. For teams buying or routing inference through intermediaries, it offers a repeatable sanity check—but not proof of a model’s identity."
published_at: "2026-10-29"
updated_at: "2026-10-29"
record_date: "2026-10-29"
date_kind: "published_at"
topics: ["anthropic"]
entities: ["Ikaleio","LM Fingerpoint Detector","lmfpd","OpenAI Responses API","OpenAI Chat Completions API","Anthropic Messages API"]
related_patterns: []
novelty_label: "new_fact"
what_changed: "Introduces a tool that fingerprints which LLM serves an API by its random-number distribution; the prior covers testing free LLM API offerings, not model identification."
prior_refs: ["memory:a00dee3b-a3ac-8c25-a4ff-4c26ac76adbd"]
source_url: "https://github.com/Ikaleio/lm-detector"
source_urls: ["https://github.com/Ikaleio/lm-detector"]
schema_version: "newruntime-agent-readable-v0.2"
stable_id: "post:open-source-lm-fingerpoint-detector-identifies-which-llm-369327"
status: "published"
visuals: []
editor: {"role":"editor","name":"Andrey Reshetnikov","profile":"https://newruntime.com/owner-profile.md","profile_json":"https://newruntime.com/owner-profile.json","same_as":["https://www.linkedin.com/in/reshetnikov1/","https://t.me/lapetuse"]}
routes: {"html":"https://newruntime.com/posts/open-source-lm-fingerpoint-detector-identifies-which-llm-369327/","markdown":"https://newruntime.com/posts/open-source-lm-fingerpoint-detector-identifies-which-llm-369327.md","json":"https://newruntime.com/posts/open-source-lm-fingerpoint-detector-identifies-which-llm-369327.json"}
---

# Open-source LM Fingerpoint Detector identifies which LLM sits behind an API from its 'random number' distribution

## Retrieval answer

Ikaleio has released LM Fingerpoint Detector, an open-source utility that estimates which language model may sit behind an API endpoint by comparing its numerical-response distribution with a reference bank. For teams buying or routing inference through intermediaries, it offers a repeatable sanity check—but not proof of a model’s identity.

## Summary

Ikaleio has released LM Fingerpoint Detector, an open-source utility that estimates which language model may sit behind an API endpoint by comparing its numerical-response distribution with a reference bank. For teams buying or routing inference through intermediaries, it offers a repeatable sanity check—but not proof of a model’s identity.

## What happened

LM Fingerpoint Detector is an open-source project from Ikaleio for fingerprinting a model exposed through an API. Its premise is deliberately unlike a conventional benchmark: it asks a model to produce roughly 300 integers between 1 and 355, then compares the resulting distribution with samples in a shared reference bank. The task is intended to be semantically irrelevant. The project argues that models do not produce uniformly distributed “random” numbers: preferred values, ranges, and final digits can be comparatively stable enough to distinguish candidates.

The detector returns a ranking of likely matches from that reference bank. The repository says the bank covers common model families including GPT, Claude, Gemini, Grok, Qwen, and DeepSeek. That makes the project relevant to an operational problem rather than model selection in the abstract: a relay or third-party API may claim to expose one model while connecting requests to another. A team can send the same kind of probe to an endpoint and compare the result with the project’s known fingerprints before relying on a supplier’s label.

The project provides three entry points. A web interface accepts pasted outputs or can connect to an API. Its command-line interface, `fpd`, offers an interactive terminal experience, repeated detection, and JSON output. SDKs are available for TypeScript, Rust, Go, and Python, allowing an application or internal validation job to score responses or inspect an API channel programmatically. The repository documents usage through `npx lmfpd@latest` for Node.js and `bunx --bun lmfpd@latest` for Bun, alongside language-specific packages.

It supports three API styles: OpenAI Responses, OpenAI Chat Completions, and Anthropic Messages, with SSE streaming enabled by default. The web tool can route requests through the project’s proxy, attempt a browser-direct request when CORS permits it, use a fixed direct connection, or work with a self-deployed Cloudflare Worker. The reference data can be browsed and exported. For maintainers who want to extend the corpus, the project describes `fpd sample`, `fpd enroll`, and `fpd retrain` as stages for sampling, adding data to the bank, and offline retraining; failed records and earlier attempts are retained.

There is also an optional tokenizer probe. When enabled in the web configuration or with `--tokenizer` on the command line, it sends about 12 short additional requests and uses returned usage information to infer the upstream tokenizer, then compares that inference with the supplied model name. The repository is explicit that this is supplementary: the fingerprint ranking and confidence come from the number distribution, not the tokenizer probe, and shared tokenizers cannot establish a model’s identity.

Most importantly, the authors place a hard boundary around the result. Detection is a ranking within a closed reference set. A model absent from that set will still be assigned the most similar available candidate, while neither the ranking score nor confidence should be treated as identification. The recommended use is repeated tests with fixed request parameters and corroborating evidence.

## What the archive adds

We have not covered this before; it opens a new thread.

## Trend signal

No supplied pattern directly fits this release, because the available patterns address agent architecture, interoperability, governance, and verification capacity rather than the separate problem of validating a model provider’s identity claim.

## Why it matters

Model names in an API response are often treated as operational facts: they inform pricing assumptions, quality evaluations, fallback policies, and customer commitments. That assumption is weaker when requests pass through a relay, reseller, or internal gateway. LM Fingerpoint Detector gives a team a lightweight test it can run independently, using interfaces already common in model integration.

The useful outcome is not a public accusation based on one score. It is an evidence-gathering step in vendor validation. A procurement, platform, or reliability team can compare repeated samples across endpoints, preserve the JSON result, investigate unexpected changes, and decide whether to tighten routing controls or ask a provider for an explanation. The tool is especially useful where the cost of silently receiving a different model is higher than the cost of a small batch of test requests.

## Limits and uncertainty

The repository does not establish that the numerical fingerprint uniquely identifies any model in all settings. Its method ranks candidates drawn from its own reference bank, so an unrepresented model can look like a represented one. The source also does not provide accuracy rates, false-positive rates, independent replication, or evidence for behavior under every provider configuration. Prompt handling, sampling settings, model updates, wrappers, and API-side transformations could affect results. Tokenizer observations are likewise not identity evidence because multiple models can share a tokenizer. A positive match should therefore be treated as a reason to investigate, not as proof that an endpoint has substituted a model.

## Skill to build now

Add a small endpoint-verification check to your model-provider evaluation process. Select a fixed configuration, run several detector samples against each candidate endpoint, store the output and request settings, and compare results after a provider or routing change. Keep the detector result separate from your acceptance decision: pair it with normal quality evaluations, latency and usage records, and provider documentation. The practical goal is a reproducible audit trail for unexpected behavior, not a one-shot verdict.

## Reader takeaway

LM Fingerpoint Detector turns a simple numerical probe into a reusable check on what may be behind an LLM API. It is a practical validation aid for teams using intermediated inference, provided they respect its central limitation: the output is a closed-set similarity ranking, not a model identity certificate.

## Open question

How stable will these fingerprints remain as providers update models, alter serving stacks, or apply response-layer transformations?

Editor: [Andrey Reshetnikov](https://newruntime.com/owner-profile.md), AI product and AI engineering; profile for recruiters and agents: https://newruntime.com/owner-profile.json

## Continue in the graph

Next records for an agent, linked to their Markdown twins. Replace `.md` with `.json` for structured fields, including `next_reads`.

- topic hub: [Anthropic](https://newruntime.com/topics/anthropic.md): Explore the anthropic topic hub.
- collection: [Field Notes](https://newruntime.com/posts.json): Open the latest editorial analysis.
- collection: [Source Ledger](https://newruntime.com/source-ledger.json): Inspect the public source evidence graph.
- whole graph: [discovery graph](https://newruntime.com/discovery-graph.json) (typed nodes and edges) and [site index](https://newruntime.com/site-index.md)