Skip to main content
Tool calling lets a model request data or an action from your application. Your application decides which functions may run, executes them, and sends the results back to the model. This guide uses Chat Completions and a small, fictional project’s formatting conventions. The example reads an in-memory dictionary; it does not run shell commands, evaluate generated code, or modify files.

Before you start

The example defaults to gpt-4o-mini, which advertises chat and tool support in the catalog checked on October 1, 2026. Set VOIDAI_MODEL to use a different eligible model. Model behavior and optional parameters can differ.

How the exchange works

  1. Send the conversation and a function definition in tools.
  2. Read the assistant’s tool_calls. Validate each function name and its JSON arguments in your application.
  3. Append the assistant message, then one role: "tool" message for every call, using that call’s id as tool_call_id.
  4. Send the updated conversation again. Stop when the model returns an answer or your loop limit is reached.
A tool definition describes a function; it does not execute it. The function’s return value becomes the tool message’s string content.

A complete Python example

Install the openai package if it is not already part of your application. The key is read from the environment and is never included in the tool definition.
The model may request both languages in one response, across separate rounds, or return text without calling a tool. The loop handles all calls in each response before asking the model to continue. It makes at most four SDK requests, with automatic SDK retries disabled. max_tokens=512 is an example output cap. If your chosen model requires max_completion_tokens, use the supported parameter instead. A round limit and output cap help bound the example; they do not establish a fixed credit cost.
The example’s control flow is checked with offline fixtures. It has not been run against the live VoidAI API.

Adapt the example to your application

Keep argument validation in your handler even when you supply a JSON schema. Treat model-selected arguments as untrusted input, and expose only the functions your application intends to offer. A production handler that writes files or changes an external service should apply its own authorization and confirmation rules before the action. Preserve the assistant message containing tool_calls, and return one result per call with the matching tool_call_id. Returning only the first result can leave the conversation incomplete. Keep tool results compact: they become input to a later model request and can consume context and credits. The example uses non-streaming responses so complete JSON arguments are available before execution. With streaming, assemble the tool-call argument fragments before parsing or invoking a function. Do not execute partial arguments. See the SDK streaming guide for the basic stream format.

Check usage and handle errors

Each model request in the loop can be billed. Keep the response IDs in request_ids and use request usage to inspect recorded charges. Use current catalog prices and the credits guide to interpret input, output, and cache costs. If a model rejects tools, check its advertised endpoint and tool support, account eligibility, and the provider’s error response. A capability flag is not a promise that every optional tool feature works on every provider. Follow the error guide for authentication, access, and rate-limit responses. For the same kind of workflow in Responses or Messages, use that API’s own tool-input and tool-result format. The role: "tool" exchange above is specifically the Chat Completions format.