Behavioral Similarity Profiling for Black-Box LLM APIs
A constrained numerical-generation approach to comparing API behavior with reference models
Technical note | Oken Evaluation Lab
Abstract
Commercial LLM APIs expose model names, but API clients generally cannot independently verify which underlying model, checkpoint, or serving configuration processed a request. This creates a practical transparency problem for developers comparing providers, monitoring API behavior, or investigating possible routing changes.
This note describes an experimental method for comparing the observable behavior of a black-box API endpoint with a bank of reference endpoints. The method uses constrained numerical-generation tasks: the target is asked to produce bounded integer sequences, and the resulting sequences are summarized with statistical features such as value frequencies, position-dependent distributions, transitions, and repetition patterns. A ranking pipeline then compares the observed feature representation with reference samples.
The method is intended to measure behavioral similarity under a specified protocol. It does not cryptographically attest to model identity, reveal provider-side routing, or prove that an endpoint is running a particular model. The current implementation uses a closed reference set, so its normalized scores must be interpreted as relative comparisons among available candidates. This note describes the methodology and its limitations; it does not report validated identification accuracy.
Disclosure
The authors are affiliated with Oken. The implementation described here is part of the Oken Evaluation Lab. This is a methodology description from the platform team, not an independent third-party audit or validation of any provider.
Evaluation interface: https://www.oken.ai/zh/evaluation-lab/full?from=provider_drawer
- Problem statement and scope A model name in an API response or product listing is a provider-supplied label. In many commercial settings, the client cannot inspect the provider's internal routing logs, deployment metadata, model weights, or serving infrastructure. As a result, a client may have limited ability to verify whether the observed endpoint behavior remains consistent with a previously measured reference. Potential scenarios include routing some requests to a smaller model, serving an older checkpoint, changing the underlying model without notice, mixing multiple models behind one endpoint, or changing inference settings in ways that materially affect output behavior. The question addressed here is deliberately narrower than model verification: Can a black-box evaluator detect whether an endpoint's observed output behavior is statistically more similar to one candidate in a known reference set than to the other candidates, under a fixed generation protocol? The method does not measure general intelligence, answer quality, factuality, instruction-following quality, or internal model identity. It produces a behavioral comparison against a specified reference bank.
Terminology and interpretation
We use the term behavioral similarity profiling to describe the method. The phrase behavioral fingerprinting can be used informally, but it should not be read as a claim that every model has a unique, permanent, or cryptographically verifiable fingerprint.
Term
Meaning in this note
What it does not establish
Black-box endpoint
An API endpoint for which the evaluator observes request inputs and returned outputs, but not internal serving state.
It does not mean that no provider-side information exists.
Behavioral similarity
Statistical resemblance between observed output features and reference samples under a specified protocol.
It is not proof of model identity.
Model attribution
Ranking candidate reference models by similarity to the observed behavior.
It is not equivalent to identity verification.
Reference bank
A versioned collection of samples gathered from endpoints with assigned labels.
It does not guarantee that upstream labels are correct.
Relative similarity weight
A normalized score among the candidates currently in the reference set.
It is not the empirical probability that a candidate is the true model.
Open-set detection
A mechanism for recognizing when an observation may not belong to any known candidate class.
It is not provided merely by applying Softmax to a closed candidate set.Method overview
Let M denote the target endpoint and let R1, ..., Rk denote reference endpoints with assigned labels. For a fixed protocol P, the evaluator collects responses from M, extracts a feature representation f(P, M), and compares that representation with the corresponding reference representations.
The current task is a closed-set ranking problem:
ŷ = argmaxᵢ S(f(P, M), Rᵢ)
Here, S is a similarity score defined by the current scoring implementation. The output identifies the most similar candidate within the available reference set. It does not recover the provider's internal routing state.
The appropriate interpretation is:
Under protocol P, detector version D, and reference-bank version R, the endpoint's observed behavior was most similar to candidate Rᵢ.
The result should not be described as:
The endpoint has been proven to run model Rᵢ.Threat model and assumptions
The primary use case is to identify behavioral changes that may be consistent with model substitution or unexpected routing. Examples include:A less expensive model being served behind a more expensive model label.
Some traffic being routed to an older checkpoint.
An endpoint changing its underlying model over time.
Multiple models being mixed behind one API endpoint.
An undocumented inference configuration changing the endpoint's output distribution.
The method assumes that the endpoint returns model-generated output and that no intermediary is deliberately transforming the output to imitate a reference distribution. A provider or middleware layer that knows the protocol could potentially detect the task and generate outputs designed to match a target distribution. The method is therefore a behavioral consistency test, not an adversarially secure attestation mechanism.
The observed behavior may reflect several components together: model weights, tokenizer, decoding parameters, prompt wrappers, safety layers, serving stack, and provider-side routing. Unless these factors are controlled or separately measured, a difference in output behavior cannot automatically be attributed to a change in model identity.Why use constrained numerical-generation tasks?
The protocol asks the endpoint to generate a sequence of bounded integers while avoiding obvious deterministic patterns. A simplified task asks for approximately 300 integers between 1 and 355, with instructions not to count upward or downward, use arithmetic progressions, cycles, repeated blocks, code, tools, or an external random-number generator.
These are low-semantic-content generation tasks, not tasks with literally no semantics: the model still has to interpret the instruction, respect the numerical range, and produce the requested format. The aim is to reduce dependence on domain knowledge, factual recall, writing style, retrieval, and subjective answer grading.
The working hypothesis is that an LLM asked to generate a random-looking sequence does not behave as an ideal uniform random-number generator. Its output can remain conditioned by learned token distributions, tokenization, alignment, decoding policy, context, and deployment configuration. These influences may produce measurable differences in value frequencies, position-dependent distributions, repetition patterns, and local transitions.
A single integer has little discriminatory value. The method therefore analyzes the joint statistical structure of many positions and compares repeated responses. This is a hypothesis to be tested empirically; the existence of measurable differences does not by itself establish reliable model identification.Sampling protocol
The current evaluation protocol uses three separately initiated generation runs. Each run is started in a separate conversation with an independently varied but semantically equivalent prompt. Each prompt requests approximately 300 bounded integers and prohibits tools, code, and external randomness. Only the first response is retained, and the parser does not repair or extend the output.
Separate conversations isolate the conversational context across runs. This should not be interpreted as proof that the resulting sequences are statistically independent: all runs may still share model weights, serving infrastructure, decoding settings, system-level instructions, and other common factors.
The three responses are analyzed separately rather than concatenated. Concatenation would introduce artificial transitions at sequence boundaries and could distort position-dependent or transition features.
Before scoring, each response passes a quality-control stage that records:Expected and observed sequence length.
Number of valid integers.
Out-of-range values.
Unparseable material.
Whether the minimum sample threshold was met.
Whether each of the three responses is independently usable.
Passing quality control means only that a response contains enough parseable data for scoring. It does not mean that every prompt constraint was followed perfectly. The rationale for using three runs, and the sensitivity of results to larger sample counts, should be evaluated through repeatability experiments. The current description does not establish that three runs are optimal.Feature representation
The current detector organizes the observed behavior into five feature families. These features describe output statistics; they should not be interpreted as direct measurements of the model's internal mechanisms.
7.1 Marginal distribution characteristics
This family includes frequencies across the integer range, coarse numerical regions, and final digits. It measures whether an endpoint's generated sequences show recurring over- or under-representation of particular values, ranges, or final digits.
7.2 Position-dependent distribution characteristics
The sequence is analyzed by stage and by normalized position. This can capture differences between early and late positions, distributional shifts across the sequence, and position-dependent final-digit frequencies. Terms such as stabilization or compensation should be used only when a specific mechanism has been demonstrated; otherwise, the analysis should describe the observed distributional change.
7.3 Transition features
The detector measures changes at multiple lags, not only between adjacent values. Current feature descriptions include normalized lag correlations, mean absolute displacement, positive- and zero-step proportions, small-step frequencies, and large standardized jumps. For reproducibility, the implementation should specify the lag values, normalization method, and exact definition of each transition statistic.
7.4 Repetition features
Exact value repetition is only one component. The representation also measures repetition or clustering of nearby values, final digits, movement directions, step sizes, and local numerical buckets. These features are intended to capture local patterns that may not be visible in a simple frequency histogram.
7.5 Sequence-structure features
Coarse numerical ranges and final digits are represented using transition matrices. The detector compares observed transitions with a reference distribution or an independence-based expectation. The exact binning scheme, matrix order, smoothing procedure, and deviation metric should be documented to make this component reproducible.
In the current implementation, the positional branch is described as containing 751 features per response:
Feature block
Dimensions
Smoothed frequencies over integers 1–355
355
Segmented position and final-digit distributions
74
Continuous position-dependent kernels
102
Lag, repetition, jump, and transition features
220
Total
751
The 751 dimensions are not 751 independent pieces of identity evidence. Some features may be correlated, and the feature count alone says nothing about generalization performance. Because the feature dimension is larger than the number of positions in a single approximately 300-integer response, evaluation should explicitly examine feature correlation, regularization, feature selection, and the risk of overfitting. The current description does not provide those results.
Candidate ranking and score interpretation
The current scoring pipeline combines several statistical views. The frequency branch is described as including a discriminative projection based on the sequence prefix, distances to empirical reference samples, and a nuisance-adjusted centroid comparison. The positional branch uses the position and sequence features described above.
The high-level fusion is currently described as:
Sᵢ = 0.5 × Sᵢ(frequency) + 0.5 × Sᵢ(positional)
The frequency component is described as:
Sᵢ(frequency) = 0.5 × Sᵢ(LDA) + 0.25 × Sᵢ(KNN) + 0.25 × Sᵢ(robust)
These expressions summarize the current high-level weighting. A reproducible technical specification should additionally define each component's raw output, any distance-to-similarity conversion, normalization range, treatment of missing features, and the empirical basis for the weights. This is particularly important because some methods naturally produce distances, for which smaller values indicate greater similarity, while the fused score must have a consistent direction.
The current implementation converts candidate scores to a Softmax-normalized distribution:
pᵢ = exp(τSᵢ) / Σⱼ exp(τSⱼ)
where τ is a temperature parameter calibrated using reference data. Unless calibration has been validated on held-out data with appropriate metrics, pᵢ should be described as a relative similarity weight within the current candidate set, not as the empirical probability that the endpoint is truly running candidate i.
Output
Interpretation
Score
An internal similarity statistic produced by the scoring implementation.
Score margin
The separation between the leading candidate and one or more alternatives.
Softmax-normalized relative weight
A normalized comparison among candidates currently in the reference set.
Empirical identification accuracy
A separately measured evaluation metric; it cannot be inferred from the normalized weight.Reference bank and reproducibility
The current frozen reference bank is described as containing:
Reference-bank item
Current count
Candidate model identities
59
Collection batches
143
Reference responses
2,198
A result should be associated with at least the following metadata:
- Detector version and reference-bank version.
- Reference collection time.
- Prompt hashes and raw-response hashes.
- Inference parameters, where available.
- Candidate ranking and score components.
- Quality-control diagnostics. The detector, reference samples, ranking components, and evaluation scripts are intended to be bound through version manifests and file hashes. This helps prevent a result from being silently reinterpreted after the reference set or scoring implementation changes. It does not independently verify that the upstream provider's reference-model label is correct.
- Closed-set limitation and unknown models The current implementation ranks candidates from a predefined reference bank. If the true model is absent from that bank, the system may still assign a high relative weight to one of the available candidates because the Softmax operation distributes weight across the candidates it receives. The quantity is therefore closer to: P(Rᵢ | x, y ∈ R) than to: P(true model = Rᵢ | x) The condition that the true model belongs to the reference set is essential. A production open-set detector would require a separately validated rejection mechanism. Possible research directions include absolute-distance thresholds, density-based methods, conformal prediction, held-out unknown models, or an explicitly trained out-of-distribution component. These approaches have different assumptions and guarantees; they are not interchangeable. No universally valid UNKNOWN threshold is claimed here.
- Sources of uncertainty and confounding factors 11.1 Model-family overlap Adjacent versions and models sharing a base model may have similar output distributions. Family-level attribution may be more stable than exact checkpoint attribution, but this must be measured rather than assumed. 11.2 Inference parameters Temperature, top-p, reasoning effort, penalties, and provider-specific sampling logic can change output distributions. A difference in the observed fingerprint may therefore reflect a configuration change rather than a model change. 11.3 Prompt wrappers and system instructions System and developer messages, formatting wrappers, and safety layers can affect instruction following and local sequence structure. Where possible, these factors should be held constant or recorded. 11.4 Temporal drift Providers may update checkpoints, routing policies, safety layers, or serving infrastructure over time. A stale reference bank may lose discriminatory value. Reference samples should therefore be time-stamped and refreshed under a documented process. 11.5 Quantization and serving-stack differences Different inference stacks may produce measurable behavior differences even when deployments use nominally related weights. The method may detect serving differences without being able to attribute them uniquely to a model identity change. 11.6 Protocol awareness and adversarial adaptation A model or middleware layer that recognizes the task may generate algorithmic randomness or imitate a reference distribution. This limits the method's resistance to deliberate adaptation. 11.7 Reference contamination and data leakage Repeated tuning against the same reference samples can cause the detector to learn collection-specific artifacts rather than generalizable model behavior. Training, calibration, and evaluation data should be separated by collection batch, and ideally by time period and serving configuration where feasible. 11.8 Confounding between model identity and serving configuration The observed output is produced by a system that includes the model and its serving configuration. To support model-level claims, experiments should test the same model under multiple parameter settings and different models under matched settings. Without such controls, the safest conclusion concerns endpoint behavior under the tested conditions, not model identity in isolation.
- What evidence is needed to validate the method? A plausible mechanism is not evidence that a particular detector achieves useful identification performance. A credible evaluation should freeze the protocol, feature extraction, scoring pipeline, and reference bank before running a blinded test. The evaluation set should include known endpoints, repeated runs, adjacent model versions, and models deliberately excluded from the reference bank. At minimum, a report should include:
- Top-1 and Top-k accuracy.
- Family-level and version-level accuracy.
- Macro- and micro-averaged precision, recall, and F1 where applicable.
- Per-model confidence intervals and a complete confusion matrix.
- Calibration error, with the calibration procedure and held-out evaluation clearly described.
- Score-margin distributions and repeatability across independent runs.
- Sensitivity to temperature, top-p, reasoning effort, and other available inference parameters.
- Performance under temporal drift and across serving providers.
- False-accept and false-reject rates for out-of-reference models.
- Ablation results for each feature family and scoring component. The split should be made by collection batch rather than randomly splitting individual responses from the same batch. Otherwise, training and test sets may share temporal, provider, or configuration artifacts. Where practical, evaluation should also include held-out time periods and held-out serving configurations. High-value stress tests include:
- Adjacent versions from the same model family.
- The same model served with different inference configurations.
- Different models evaluated under matched inference configurations.
- Unknown models excluded from the reference bank.
- Mixed routing between two known models.
- Repeated evaluation after a provider silently changes an endpoint.
- The same nominal model accessed through different providers or serving stacks. Until such results are reported, the system should be described as an experimental behavioral similarity detector with a defined methodology, not as a generally validated model-identity verifier.
- Appropriate use and non-use Potentially useful applications include:
- Monitoring whether an endpoint's observable behavior changes materially over time.
- Comparing an API endpoint with a known native or provider reference under a controlled protocol.
- Flagging possible routing or downgrade anomalies for further investigation.
- Prioritizing providers or endpoints for additional technical review.
- Tracking behavioral drift across repeated evaluations. The method should not replace:
- Provider-side routing and request logs.
- Signed deployment metadata or trusted execution evidence.
- Contractual audits and provider disclosures.
- Cryptographic model attestation.
- Independent evaluation of task quality, latency, reliability, and factuality. A behavioral comparison is one piece of evidence. Strong claims about model substitution should be supported by repeated tests and independent operational evidence. A similarity result alone should not be used to accuse a provider of misrepresentation.
- Practical interpretation of an individual result For an individual endpoint evaluation, the recommended wording is: Under the specified prompt protocol, quality-control rules, detector version, and frozen reference bank, the endpoint's observed responses were most similar to candidate X. This result indicates behavioral similarity to X under the tested conditions; it does not prove the endpoint's internal model identity or establish that the provider has substituted a model. If the endpoint's behavior changes materially over time, the result should be treated as a signal for follow-up investigation. The next steps may include repeating the test, checking inference parameters, comparing independent reference endpoints, reviewing provider documentation, and requesting operational evidence from the provider. Conclusion Constrained numerical-generation tasks provide one possible way to observe statistical differences between black-box LLM API endpoints. By analyzing value frequencies, position-dependent distributions, transitions, repetition patterns, and other sequence features, an evaluator can compare an endpoint's observable behavior with a bank of reference samples. The central claim is deliberately limited: under a fixed protocol, numerical-generation behavior may provide useful signals for comparing endpoints and monitoring behavioral changes. Whether those signals are sufficiently stable and discriminative for reliable model-level attribution is an empirical question. It must be evaluated separately for each detector version, reference bank, inference configuration, provider environment, and evaluation period. The current method is best understood as an experimental behavioral similarity tool. It is not a cryptographic identity check, and its closed-set ranking should not be interpreted as proof that an endpoint runs a particular model. Publishing blinded evaluation results, repeatability analysis, open-set rejection performance, and sensitivity tests will be essential to establishing its practical value. We welcome technical feedback, particularly on feature validation, batch-independent evaluation, confounding between model identity and serving configuration, open-set rejection, adversarial robustness, and the distinction between model-family and exact-version attribution. Appendix A. Suggested minimum reporting template The following table is a reporting template. Values should be populated only after the corresponding experiments have been run; no performance values are inferred or fabricated in this document. Evaluation item What should be reported Dataset composition Models, providers, versions, collection dates, number of batches and responses. Protocol Prompt variants, requested sequence length, parsing rules, sampling parameters, number of runs. Data split Batch-level train/calibration/test split and any held-out time periods or providers. Classification Top-1, Top-k, family-level and version-level results. Error analysis Confusion matrix, per-class errors, false accepts and false rejects. Calibration Calibration method, calibration error, reliability analysis, and held-out results. Repeatability Rank consistency and score variation across repeated runs. Robustness Sensitivity to inference parameters, prompt variants, provider and serving changes. Ablation Performance with each feature family and scoring component removed. Open-set behavior Unknown-model rejection method, threshold selection, false-accept rate.
Appendix B. Implementation details to document for reproducibility
- Exact integer parsing and invalid-output handling rules.
- Numerical binning scheme and smoothing method.
- Position segmentation and kernel definitions.
- Lag values and transition-statistic formulas.
- Repetition-window definitions and bucket construction.
- Feature scaling, selection, regularization, and missing-value handling.
- LDA configuration and training procedure.
- KNN distance metric, neighbor count, and aggregation method.
- Definition of the robust comparison branch and nuisance factors.
- Score normalization and distance-to-similarity transformations.
- Weight-selection procedure and Softmax temperature calibration.
- Reference-bank labeling, refresh policy, and versioning procedure.
Top comments (0)