Understand what the service manages
Managed inference puts model serving behind an API so your application can request an answer without running the GPU server itself. WeightsAPI uses an OpenAI-compatible request format for open-weight models; check service status for availability.
You still own the application: its prompts, data selection, permissions, retry behavior and output checks. Begin with a specific task and decide what a useful answer would look like. The use-case guide offers starting points without promising that every model supports every feature.
Choose a model for the actual task
Use the model catalogue to compare capabilities, licenses, context and input/output rates. Read the model page, then use its exact API model ID in your request. Distinguish the publisher’s native context from the confirmed deployment limit: input and intended output must fit the latter.
A catalogue listing does not prove a deployment is available. Model discovery lists connected deployments when a backend is available. Compare the relevant rates on pricing rather than assuming all models cost the same.
Prepare a small, inspectable request
Start with a short prompt, the exact model ID and a bounded output. The quickstart explains the chat-completions format. Add only the conversation history needed for the task, and keep API credentials on your server.
Streaming is optional: it delivers the answer in events rather than as one complete response. Read the streaming guide before enabling it, including how to handle interrupted responses and the final usage record.
Separate access and spending
Sign in to the console. Create separate keys for applications or environments, set a positive spending cap and restrict allowed models when useful. Save the secret when it is first shown.
A key cap applies to lifetime recorded usage and outstanding reservations, not a monthly allowance. Replace exposed keys and revoke old ones. The FAQ explains how keys, credit and pending requests relate.
AI access requires sign-in, one confirmed top-up of at least USD 100, an authorized API key and enough available credit for the request. Each later top-up also has a USD 100 minimum; smaller remaining balances stay usable when they cover the request. Credit requires transaction verification. Check service status for model availability before sending traffic.
Distinguish available credit from final cost
For an admitted paid request, available credit covers the input and maximum output before generation starts. Final cost uses actual input/output usage; the initial reservation is not the final charge. Requests awaiting settlement can therefore reduce available credit.
If a response stops before final usage is confirmed, the reservation can remain until reconciliation. A funding order provides payment instructions; credit requires transaction verification. Review billing for quote deadlines, confirmations and available credit.
Review the result before expanding
For document questions, have your application select relevant passages, request an answer with citations and check those citations against the sources. Keep document permissions and final review in your application.
Evaluate answer quality, context use and expected spend with representative examples. Expand only after testing the required capabilities. For errors, interrupted streams or pending credit, follow the support guide and retain a sanitized report.