How to verify your requests
Compare model responses, test features, and calculate charges from published rates.
A client is the software that sends API requests. A request identifier labels one API request.
Do these checks:
1. Examine the model identifier
Copy a model identifier from the catalog. Send a request with your usual client. Examine the model field in the response. If you find a problem, keep the request identifier.
Set FERRIX_BASE_URL to the /v1 API URL. Set FERRIX_MODEL to a model identifier from the catalog.
Matching model fields show consistent labels. They do not prove which model weights produced the response.
import os
from openai import OpenAI
client = OpenAI(
base_url=os.environ["FERRIX_BASE_URL"],
api_key=os.environ["FERRIX_API_KEY"],
)
model = os.environ["FERRIX_MODEL"]
response = client.chat.completions.create(
model=model,
messages=[{"role": "user", "content": "Reply with the word ready."}],
)
print("Requested:", model)
print("Returned:", response.model)
print("Usage:", response.usage)2. Compare outputs from representative tasks
Send a fixed set of tasks to Unbar. Send the same tasks to a reference service that you trust. Use the same model, prompts, and generation configuration. Compare task accuracy across multiple requests. Compare the output format. Compare tool behavior.
One good response does not establish model quality. Normal variation between generated responses does not prove that a different model produced them.
3. Do feature tests
Streaming sends a response in parts. A tool call requests an action from your software.
Do streaming tests on your selected model. Do tool-call tests on your selected model. Do tests with the input lengths that your application uses. Before you move production traffic, examine completed responses. Before you move production traffic, examine error handling.
Support for a feature on one model does not establish support on every model.
4. Calculate charges from published rates
A token is a unit of model input or output. A cache contains data for reuse. A cache-write tier specifies a cache duration. Each tier has its own published rate.
The catalog compares our rates with OpenRouter list rates. The headline discount uses the smaller input or output discount. Input, output, cached input, and cache writes have separate published rates where applicable.
Record the rates that applied to the request. For each billed token type, multiply the token count by the USD rate per million tokens. Divide each result by one million. Add the results. Compare the total with your usage records.
Calculate uncached input, cached input, output, and each applicable cache-write tier separately. Do not count cached tokens twice. Do not apply the headline discount to every token type.
Rates in the catalog can change after your request.
What these checks cannot prove
Model weights are numbers that determine model behavior. Quantization reduces the numerical precision of these weights. These changes can affect output quality.
A model cannot reliably prove its identity through its own text. Model labels, response headers, and text comparisons do not provide cryptographic proof of model identity or weight precision. Weight precision is the numerical detail of model weights. These checks can show differences and help you assess suitability for your application. They are not hardware attestation or certification. Hardware attestation is evidence from the hardware that operates a model.
Report a problem
Email support@unbar.sh with the model, request identifier, and a description of the problem. Do not send API keys. Do not send private prompts.