Frequently asked questions

Browse the model catalogue and documentation, sign in to the console, and create or revoke API keys. Crypto checkout supplies the amount, network, address and payment deadline; credit requires a verified transaction. Dedicated orders can be placed and paid from confirmed credit, with hardware activated after provisioning. Check status and the quickstart before sending model requests.

Sign in and confirm a top-up of at least USD 100 before AI use. Each later top-up has the same minimum; after qualification, a smaller remaining balance stays usable when it covers the request. Key permissions, spending caps and model availability still apply. Pending payments do not unlock access. Check service status before sending requests.

Sign in to the console and create a named key with a positive spending cap and, if useful, a list of allowed models. Copy the secret when it appears: the console reveals it only at creation. Keep it in a server-side environment variable or secret manager. Keys control access; available credit and an available model are also required. See authentication.

Use the base URL in the quickstart, send your API key as a Bearer token and choose an exact model ID returned by /v1/models. Set an output-token limit that fits your budget and the deployment’s context window. Check service status before submitting requests.

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.

For an OpenAI Chat Completions integration, the main changes are the base URL, API key and model ID. Provider-specific APIs and features need separate checks. An Anthropic integration also needs changes to the SDK, message format, system prompt placement and response parsing. Follow the migration guide, then test representative prompts, tools and structured outputs against a connected deployment before moving traffic. Compatibility with a familiar request format does not guarantee identical model behavior.

Start with the task: short interactive chat, coding, reasoning or longer document input. Compare the model pages for publisher specifications, service context and input/output rates. Check model availability and evaluate the smallest suitable candidate on your own tasks. Verify tool calling or schema support separately before committing an application to a model.

WeightsAPI accepts the Chat Completions, legacy Completions and model discovery request formats. Generation requires an available deployment that supports the selected operation. Responses, Assistants and provider-specific tools are not drop-in replacements. Consult the API reference for supported operations, then validate the features your application uses before switching traffic.

Set stream: true for an available chat deployment and consume complete server-sent events. A network chunk is not necessarily one message, and the final usage record can arrive after the answer text finishes. Keep the API key on your server when forwarding a stream to a browser. The streaming guide covers usage and interrupted connections; check service status for availability.

The gateway forwards tool definitions to the selected model. A model can return a requested tool name and arguments; your application decides whether to execute the action. Validate both against an allowlist and the current user’s permissions, then return the result in the conversation. WeightsAPI does not execute your application’s tools. Check deployment support and follow function calling before enabling actions.

Strict schema output requires constrained decoding and support for your schema in the selected deployment. Asking a model to “return JSON” alone does not guarantee a schema match. The gateway forwards response_format; confirm strict-mode support for the deployment before relying on it. Follow the structured-output guide, validate every result with the same schema, and handle truncation or rejection explicitly.

These operations need their own supported deployment. A listed capability or rate does not establish an active endpoint, and sending multiple chat requests from your application is different from a managed batch API. Check the API reference and service status before designing around an auxiliary service.

Choose the exact asset and network shown in checkout and use the receiving address saved with your order. A token on another network is not interchangeable. The order retains its asset, network and address even if the payment configuration changes. Credit appears only after the incoming transaction has been matched and verified. See billing.

Create a funding order for at least USD 100. The server obtains a recent market rate and fixes the amount to send for 10 minutes, including for USDT and USDC. Keep the order reference and pay network fees separately. Transaction matching and credit confirmation remain separate verified steps; creating an order or refreshing its status does not add credit. See the billing guide.

An order starts in an awaiting-confirmation state. Its transfer must be matched and verified before account credit is recorded. A payment declaration or status refresh cannot mark it paid. Keep the order reference and public transaction identifier, and do not send another payment merely because the first is pending. The support guide lists the details to retain; confirmation and resolution times are not guaranteed.

A recovery policy for wrong-network or wrong-asset transfers has not been established. Do not assume a transfer can be credited, recovered or refunded. Before transferring, verify the asset, network, address and amount against the current deposit instructions before sending. If a transfer problem occurs, provide the order reference and public transaction identifier through support; never share a wallet seed phrase or private key.

Checkout shows the rate source, rate timestamp and payment deadline. USDT and USDC use their actual market rates, not an assumed one-dollar parity. If no recent rate is available, retry the calculation before sending funds. An existing order without a quote can receive one without changing its reference or address.

After expiry, get a new quote only if you have not already sent funds. Keep the original order for a transfer already sent; confirmations may arrive later. An exact payment received within its quote window qualifies for the quoted USD credit after verification. Late transfers or different amounts require review; a pending payment does not unlock AI access. See billing.

Shared inference has separate input and output rates for each model. An admitted request reserves enough credit for the counted input and maximum requested output, then settles against authoritative usage at the rates saved with that reservation. Use the pricing table to estimate your workload. Models without published prices cannot accept paid requests. A request rejected before inference dispatch does not create a token charge. See billing.

Balance comes from the account ledger; available credit also subtracts outstanding inference reservations. A reservation holds the maximum admitted request cost so concurrent requests cannot spend the same credit. When authoritative usage arrives, the final charge replaces the hold. If a stream breaks or provider usage is missing, that reservation can remain pending reconciliation. A disconnected client does not prove generation stopped. Consult streaming and billing, and report an unresolved hold through support.

Each key has a lifetime USD spending cap that includes recorded usage and outstanding reservations. It does not reset monthly. A model allowlist limits the exact model IDs the key may use; an empty list permits all available catalogue models. Use separate keys to distinguish applications and environments in usage records. Key controls do not add account credit or change model availability. See authentication.

The console cannot show an existing secret again. Create a replacement key, store it securely, update the applications that use it, and revoke the old key. If the key was exposed, revoke it promptly and inspect the account’s usage records. Revocation prevents new requests from being admitted with that key; work already admitted can still settle. Never paste an API key into a support message, public repository or browser bundle. Follow the authentication guide.

Wallet withdrawals are currently unavailable. Use confirmed prepaid credit for eligible model requests or dedicated GPU orders. Cancelling a paid GPU order before activation returns that rental payment to your WeightsAPI account balance; it does not send cryptocurrency to a wallet. No automatic refund or wallet payout is promised. Review billing before adding credit.

The gateway does not persist prompts, completion text or tool arguments in its application database, and application logs omit request bodies. Authentication, usage and payment records are stored separately. Provider retention and infrastructure logging require independent verification; gateway behavior is not an end-to-end zero-retention guarantee. Read data handling and the trust page for the scope.

The account system keeps identifiers, API-key hashes and metadata, deposit and withdrawal records, token counts, charges and usage aggregates. Request reservations also record the model, applicable rates and settlement state so billing can be reconciled. These records support authentication, spending controls and accounting without storing conversation text. “No content logging” therefore does not mean anonymous usage or no retained records. Consult data handling; retention periods and production data-rights procedures still need published, verified terms.

Dedicated GPU orders retain the selected hardware and model, monthly price, payment and cancellation status, and service dates and endpoint details when provisioning is confirmed.

The gateway’s behavior does not establish another provider’s retention or training policy. Serving a request requires sharing its content with the inference provider. Provider logging, subprocessors and contractual terms require separate verification. If your workload has confidentiality or regulatory requirements, review the trust page and confirm the relevant arrangements before sending sensitive content.

Dallas, Ashburn and Portland are target GPU locations. Availability, routing and data residency require confirmation for the actual deployment; location names alone do not establish these conditions. Region choice and end-to-end residency commitments must be agreed for the deployment. Review data handling and the trust page before committing a workload with regional requirements.

Yes. Your account must receive one confirmed top-up of at least USD 100 before any AI interaction; there is no public free-trial allowance. Every later recharge also starts at USD 100. After the initial qualifying top-up, remaining credit below USD 100 can still pay for requests until insufficient. Use an active key with the required model permissions and budget. Checkout provides payment instructions and a time-limited crypto quote. Credit requires a matched, verified transaction; creating or refreshing an order does not confirm payment.

Performance depends on the model, hardware, prompt length, generated length, concurrency and serving configuration. On an available deployment, measure time to first token and generation speed separately using a representative workload. Published model characteristics and hardware specifications are not an SLA. Review dedicated capacity for workloads that need reserved resources and service status for availability.

No. The current design does not impose a default fixed requests-per-minute product limit on paid traffic, but admission still depends on available credit, key caps, allowed models, output limits, context size and backend capacity. Shared serving can queue, and the playground follows the same confirmed-top-up, available-credit and key-budget rules as API requests. A model’s native context window can also exceed the configured service ceiling. Review limits and handle errors with bounded retries; do not treat credit as a capacity guarantee.

Use the dedicated GPU page to choose a configuration and open checkout. If your balance is insufficient, recharge it in crypto and return once credit is confirmed to pay for the order. A top-up does not pay the rental automatically. The prepaid month starts on activation, with no automatic renewal. Before activation, cancellation returns any rental payment to your account balance. Hardware availability and delivery timing require operator confirmation; an order is not an active machine.

A 503 service_unavailable means the required deployment or auxiliary service cannot accept the request. Check the status page and error guide before using bounded retries. A connection setting alone is not proof of healthy service or measured uptime. Requests rejected before inference dispatch do not create a token charge.

Use the support page to prepare the affected operation, approximate time and timezone, model ID, error code and expected result. For billing or deposits, add the request or order reference and public transaction identifier where applicable. Remove API keys, wallet secrets and unnecessary prompt content. Copying a report does not submit it. Official support contacts, service hours and response targets are not published.