Choosing a model involves three separate questions: can your key access it, does it support your task, and is its cost acceptable for your workload? Answering them in that order avoids building an integration around a catalog entry that cannot serve your requests.
Start with the model list for your key
curl --fail-with-body https://api.gatepx.ai/v1/models \
-H "Authorization: Bearer $GATEPX_API_KEY"Use the ID returned in data[].id exactly as written. Model availability depends on configured channels, account groups, and key restrictions. An empty model list is a reason to check configuration or contact support; it is not a reason to guess a different spelling.
The public pricing page helps you explore the reference catalog. Your authenticated dashboard pricing view provides the account context. When the two differ, clarify the applicable rate before estimating a large workload.
Match the model to the request
Confirm that the selected model supports the operation you need. A text chat example does not establish support for image input, tool calls, structured output, or a separate endpoint. Context size, accepted parameters, and response fields can also differ.
Build a small evaluation set from real tasks your application performs. Compare answer quality, error behavior, and response handling. Include edge cases that matter to your product rather than selecting a model only from its name or a general ranking.
Estimate a workload using its actual shape
A useful estimate starts with observed request sizes. Track how much context your application sends, how much output it asks for, and how many requests a typical workflow makes. A short user prompt can still result in a large request when it includes conversation history or retrieved material.
Use the current applicable input and output rates rather than copying a price from an old article. Some models have additional billing categories or conditions; review the model details for the request type you plan to send. A simple token estimate is not a universal formula for every supported operation.
Recheck after changing a model
- Update the exact model ID and verify that it is still available to the application key.
- Repeat feature tests and evaluate the generated output against your existing cases.
- Inspect usage for representative requests and compare it with your estimate.
- Review how the application behaves if that model becomes unavailable or rejects a parameter.
Keep model selection and pricing checks in the release process for your application. A successful integration test today does not make a static article an availability promise. The model documentation and live pricing views are the sources to revisit when your workload changes.