Did a New Model Land? Verifying Availability from Code, Not the Docs Page

Why Verify Programmatically?

Documentation pages are updated manually and often lag behind actual API deployments. When a new model is announced, you might want to use it immediately. Rather than refreshing the docs, you can query the API directly to confirm availability. This approach is faster, more reliable, and can be automated.

Step 1: Query the Models Endpoint

Most OpenAI-compatible APIs expose a /v1/models endpoint that lists all available models. Use it to check if the new model ID appears.

import requests

API_KEY = "your_api_key"
BASE_URL = "https://api.your-aggregator.com/v1"  # replace with actual base URL

headers = {"Authorization": f"Bearer {API_KEY}"}
resp = requests.get(f"{BASE_URL}/models", headers=headers)
resp.raise_for_status()
models = resp.json()["data"]
model_ids = [m["id"] for m in models]

new_model_id = "claude-3-5-sonnet-20241022"  # example; replace with the new model ID
if new_model_id in model_ids:
    print(f"{new_model_id} is available!")
else:
    print(f"{new_model_id} not found. Available models: {model_ids}")

If the model is listed, it's likely available. However, listing doesn't guarantee it's fully operational—proceed to a test call.

Step 2: Send a Minimal Test Request

A lightweight chat completion request confirms the model can process inputs.

payload = {
    "model": new_model_id,
    "messages": [{"role": "user", "content": "Say 'OK'"}],
    "max_tokens": 5
}
resp = requests.post(f"{BASE_URL}/chat/completions", headers=headers, json=payload)

if resp.status_code == 200:
    print("Model responded successfully:", resp.json()["choices"][0]["message"]["content"])
else:
    print("Request failed:", resp.status_code, resp.text)

A successful response indicates the model is not only listed but also functional.

Step 3: Interpret Errors

Not all errors mean the model is missing. Common responses:

• 404 Not Found: The model ID is not recognized. Either it's not yet available, or you've mistyped the ID.
• 400 Bad Request: The model exists but your request was invalid (e.g., unsupported parameter).
• 429 Too Many Requests: The model is available but you've hit a rate limit.
• 503 Service Unavailable: The model may be temporarily down or overloaded.

If you get a 404, double-check the model ID against the provider's latest announcement. Model IDs are case-sensitive and often include version dates.

Best Practices

• Cache the model list: Avoid querying /v1/models on every request. Cache it for a few minutes.
• Handle fallbacks: If the new model isn't available, gracefully fall back to a known-good model.
• Monitor for changes: Periodically check for new models and log when they appear.
• Use environment variables: Store your API key and base URL securely.
• Read error messages: They often contain clues about why a model isn't working.

Automating the Check

You can run the verification as part of your deployment pipeline or a scheduled job. For example, a simple Python script that exits with a non-zero status if the model is unavailable can gate a release.

Conclusion

By querying the API directly, you get immediate, accurate information about model availability. This method is more reliable than waiting for docs updates and can be integrated into your workflow to ensure you're always using the latest models as soon as they're live.

Remember: your API key works across all models offered by the aggregator, and you pay official price × 1.3 in USDC on Base. If you contribute a key, you earn official price × 1.1 (premium × 1.2) in USDC.