Control rate and concurrency
Request limits apply to your organization across its API keys and workers. Creating another key does not create another request allowance. Chat completions and Multilook have separate rate-limit buckets; the default limits are 300 requests/minute for chat completions and 150 requests/minute for Multilook. Your organization’s limits may differ. Each model round in a tool loop is a new chat-completion request. A Multilook call counts as one request in its own bucket, although its prompts and completions still contribute token usage. Models list and retrieval share a bucket. Files upload, content download, listing, metadata retrieval, and deletion have separate counters. Use a bounded work queue and a small pool of concurrent requests. For example, start with four requests in flight, measure completion time and errors, then adjust. This is an application setting, not an API concurrency limit. A concurrency cap alone does not enforce requests per minute: also pace request starts, including retries, across all workers sharing the organization. On a rate-limit response, honor theRetry-After delay when present and use bounded backoff with jitter. Reduce the submission rate instead of immediately replacing every failed request. An insufficient-quota error needs its underlying balance or storage issue resolved; repeated retries will not fix it. See error messages for retry decisions. Contact support if the workload needs higher limits.
Keep media requests small
Chat-completion and Multilook JSON bodies have a 20 MiB size limit. Inline base64 media counts toward that body size and is larger than the original binary data. Upload reusable media through the Files API, then send file references in model requests. Files uploads have their own per-file limit and organization storage quota, separate from the inference JSON-body limit. Reusing a file avoids retransmitting its bytes and reduces request size. It does not reduce the tokens needed for the model to process that media, or remove its position from asset ordering. Media-count limits and the model’s context window still apply. If you reduce image resolution or shorten a video, check that the task’s necessary text, objects, and events remain visible. Keep excerpt offsets and crop coordinates with the media so you can map annotations back to the source. Use the tokenization guide to understand token usage and preprocessing tradeoffs.Share context for independent questions
Multilook can answer several independent questions about the same media with one shared context. Put reused media incontext, and put each independent question in prompts. Start with n: 1; increasing n requests more completions and increases output work.
Keep dependent questions and tool loops in ordinary chat completions. Multilook does not support streaming, function declarations or tool history, JSON Schema/regex constrained responses, or stop. Check each prompt’s result separately and retry only failed prompts when appropriate.
Shared-context reuse is scoped to one Multilook call. Read aggregate usage to measure it: prompt_tokens_details.cached_tokens is a subset of prompt_tokens, not an extra token count. Reusing a file in a later request does not promise a cache hit. See the model pricing table.
Bound time and output
Setmax_completion_tokens for the expected answer, leaving room for reasoning, annotations, or function arguments. Check finish_reason: length means the output budget was exhausted. If a task repeatedly truncates, narrow the requested work or increase the budget within the model’s limits.
Chat-completion requests have a 120-second request time budget; Multilook has a 300-second budget. Requests can fail earlier, and setting a longer client timeout does not extend these limits. Streaming provides incremental output but does not bypass the request time limit. For a Multilook timeout, reduce the number of prompts, n, or the completion budget before retrying.
Choose a client timeout that fits the application’s deadline. Include queue waits and retry delays in that deadline. Configure retry attempts in one place so client-library retries and application retries do not multiply unexpectedly.
For agents, also bound the total model rounds, tool calls, concurrent tool executions, accumulated tokens, and end-to-end time. Every request resends its supplied history, so input usage can grow across rounds. Building a tool agent explains how to apply one deadline across model calls and tools. Do not replay a tool action solely because a model request timed out; the action may already have completed.