Notes from a first Responses API request

The first useful question about the Responses API is not whether it replaces Chat Completions. It is where each interface fits when you are building a real application.

Both APIs send a request to a language model and return generated text. The difference is mainly in the shape of the request and response, and in how much of the conversation workflow the API can represent.

§ Start with the familiar interface

Chat Completions uses a list of messages. Each message has a role, such as system, user, or assistant, and some content. A small request might ask a model to summarize a paragraph, then read the answer from the first choice in the response.

This format is still a practical choice for simple chat, classification, extraction, and applications that already use an OpenAI-compatible SDK. It is easy to understand, widely supported, and often requires little code to add to an existing project.

With Vana API, you can point an OpenAI SDK at the Vana API endpoint and keep this general programming model while choosing an available model such as GPT-6.1 Sol. Vana API charges for real token usage without a monthly fee, so the same approach works for a small experiment or a request-driven service.

§ A different shape for the same job

The Responses API uses an input field rather than requiring your application to build a chat-shaped message history for every request. Its response is also more structured. Instead of assuming that the result is only one assistant message, it can contain a sequence of output items.

For a basic text request, an SDK may provide a convenient text value such as output_text. Underneath that convenience, the response can describe different kinds of output, including text and tool-related items. This makes the interface a better fit when one model turn may involve several steps.

That structure matters as an application grows. A request might ask for an answer, call a function to look up an order, and then continue with the function result. With Chat Completions, developers commonly represent this flow through messages and tool calls. With Responses, the workflow is represented more directly as a response with typed output items.

§ Keeping conversation state

With Chat Completions, your application normally sends the relevant conversation history again on each request. You decide what to keep, summarize, remove, or store.

The Responses API can also support a continuation model in which a later request refers to an earlier response. This can reduce the amount of conversation bookkeeping in your application. It does not remove the need to think about context size, privacy, retention, or cost. You still need a deliberate policy for long conversations and sensitive data.

For a first project, sending explicit input is often easier to inspect and test. Add response chaining when the application benefits from it rather than adding it simply because it is available.

§ Choosing an interface

• Use Chat Completions when you have an existing integration, need a straightforward message list, or want the smallest change to a current application.
• Use Responses when you want structured output items, multi-step tool use, or a response-oriented workflow that may expand over time.
• Keep the model layer separate from the rest of your code so you can change the endpoint style or model without rewriting your application logic.

Vana API also speaks the Anthropic Messages and Gemini native protocols through its compatible infrastructure. That gives teams a way to test different client styles while using one service for models from several providers. It works with Claude Code, Codex, Gemini CLI, and OpenAI SDKs, with usage billed per real token.

If you are starting from scratch, create a Vana API account, set the API base URL in your client, choose one supported model, and make one plain text request before adding tools or persistent state. Compare the request and response objects in your logs. The important distinction becomes much clearer once you can see exactly where the input, output, and conversation state live.