Skip to content
FUMODocs

Responses API

Fusion Max and Fusion Code provide an OpenAI-compatible Responses API for multimodal and coding-agent workloads. The endpoint is stateless; supported fields and features are listed below.

Get an API key →

Use a FUMO Dashboard key for an account registered and funded online.

Base URLhttps://capi.fumolab.ai/api/fusion/v1
EndpointPOST /responses
AuthorizationBearer <API_KEY>
Content typeapplication/json

Request

Send an authorized model ID and a non-empty text string or input array. This example also requests an automatic reasoning summary:

{
  "model": "fusion-code-1.0",
  "instructions": "Act as a precise software engineering agent.",
  "input": "Inspect the proposed migration and identify the highest-risk change.",
  "reasoning": {
    "summary": "auto"
  },
  "text": {
    "verbosity": "medium"
  },
  "stream": true
}

Model IDs and core routing

ProductAuthorized model IDProduct focus
Fusion Max 2.0fusion-max-2.0High-performance coding, agents and document analysis, built for cost efficiency.
Fusion Max 1.0fusion-max-1.0Complex reasoning, research, and demanding agentic workloads
Fusion Code 1.0fusion-code-1.0Coding, debugging, terminal work, and software-agent workflows

Requests require a model ID authorized for your key. The service configuration determines the internal model topology for Fusion Max and Fusion Code. See Getting started for the full model list.

Input

For a single user turn, pass a string:

{
  "input": "Review this implementation plan."
}

For conversation history, send the complete input array on every request:

{
  "input": [
    {
      "type": "message",
      "role": "user",
      "content": [{ "type": "input_text", "text": "Propose a safe migration." }]
    },
    {
      "type": "message",
      "role": "assistant",
      "content": [
        { "type": "output_text", "text": "First, add compatibility tests." }
      ]
    },
    {
      "type": "message",
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "Turn that into an implementation sequence."
        }
      ]
    }
  ]
}

Message roles may be system, developer, user, or assistant. Content may be a string or an array of text, input_text, output_text, or input_image parts. Use input_image.image_url for an image URL:

{
  "input": [
    {
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "What changed between these diagrams?"
        },
        {
          "type": "input_image",
          "image_url": "https://example.com/architecture-v2.png",
          "detail": "auto"
        }
      ]
    }
  ]
}

Audio and file input parts are not supported.

Supported request fields

FieldBehavior
modelRequired model ID authorized for your key
inputRequired string or non-empty input array with text and image content
instructionsDeveloper-level instructions prepended to the request
streamReturns Responses server-sent events when true
temperatureNumber from 0 to 2
top_pNumber from 0 to 1
max_output_tokensPositive client-visible output limit
reasoning.effortOnly Fusion Max 2.0 supports low, medium, high, and max, defaulting to medium. Max 1.0 and Code 1.0 do not support adjustable effort.
reasoning.summaryauto, concise, or detailed
text.verbositylow, medium, or high
text.formattext, json_object, or json_schema
toolsClient-executed function and custom/freeform tools
input[0].additional_toolsResponses Lite tools on one leading developer item
tool_choicenone, auto, required, or a named function/custom tool
parallel_tool_callsControls whether the final response may contain multiple tool calls
service_tierFinal-generation hint where the selected route has a compatible field
storeOmit or set to false; provider-side response storage is not supported

Unknown top-level fields are accepted for compatibility, recorded as structured warnings, and removed before execution. Only Fusion Max 2.0 supports low, medium, high, and max, defaulting to medium. Max 1.0 and Code 1.0 do not support adjustable effort.

Client-executed tools

Fusion supports both schema-constrained function tools and custom tools with freeform input. These tools are executed by the client; Fusion does not execute them on the server.

Function tools

Responses tools place the function fields directly on each tool:

{
  "model": "fusion-code-1.0",
  "input": "Check the deployment status for service api.",
  "tools": [
    {
      "type": "function",
      "name": "get_deployment_status",
      "description": "Return the current deployment status for a service.",
      "parameters": {
        "type": "object",
        "properties": {
          "service": { "type": "string" }
        },
        "required": ["service"],
        "additionalProperties": false
      },
      "strict": true
    }
  ],
  "tool_choice": "auto"
}

A function call is returned as an output item with type: "function_call". Continue the loop by sending the call and its result in the next request:

{
  "input": [
    {
      "type": "function_call",
      "call_id": "call_123",
      "name": "get_deployment_status",
      "arguments": "{\"service\":\"api\"}"
    },
    {
      "type": "function_call_output",
      "call_id": "call_123",
      "output": "{\"status\":\"healthy\"}"
    }
  ]
}

Only the final Fusion response can issue an authoritative client-visible tool call. Intermediate collaborative work cannot execute client tools.

Custom/freeform tools

Use type: "custom" when the tool should receive freeform text instead of JSON arguments:

{
  "input": "Prepare and apply the smallest safe patch.",
  "tools": [
    {
      "type": "custom",
      "name": "apply_patch",
      "description": "Apply a patch expressed in unified diff format."
    }
  ],
  "tool_choice": "auto"
}

The response uses a custom_tool_call output item with freeform input. Continue the stateless loop by returning a matching custom_tool_call_output with the same call_id.

Responses Lite additional_tools

Responses Lite accepts additional_tools only on one leading developer item at input[0]. Those definitions are merged with top-level tools. Definitions with identical complete JSON are deduplicated; definitions with the same tool name but different complete JSON are rejected.

{
  "input": [
    {
      "type": "message",
      "role": "developer",
      "content": [
        { "type": "input_text", "text": "Use the available repository tools." }
      ],
      "additional_tools": [
        {
          "type": "custom",
          "name": "shell",
          "description": "Run a shell command and return its output."
        }
      ]
    },
    {
      "type": "message",
      "role": "user",
      "content": [
        {
          "type": "input_text",
          "text": "Inspect the repository and run the relevant checks."
        }
      ]
    }
  ]
}

additional_tools is a Fusion Responses Lite extension rather than a standard OpenAI Responses field. It is rejected on any other input item or on more than one developer prefix.

Structured output

Use text.format for JSON output:

{
  "text": {
    "format": {
      "type": "json_schema",
      "name": "review",
      "strict": true,
      "schema": {
        "type": "object",
        "properties": {
          "approved": { "type": "boolean" },
          "reason": { "type": "string" }
        },
        "required": ["approved", "reason"],
        "additionalProperties": false
      }
    }
  }
}

Fusion validates the complete final text against the requested format before returning it.

Streaming

With stream: true, Fusion returns standard Responses event names. A successful text stream includes events such as:

  1. response.created;
  2. optional reasoning-summary events;
  3. response.output_item.added;
  4. response.output_text.delta, function-call argument events, or custom-tool input events;
  5. response.output_item.done;
  6. response.completed.

The stream terminates with response.completed or response.failed. Responses streams do not use the Chat Completions data: [DONE] sentinel.

Response

A buffered text response uses the Responses object shape:

{
  "id": "resp_fusion_...",
  "object": "response",
  "status": "completed",
  "model": "fusion-code-1.0",
  "output": [
    {
      "type": "message",
      "status": "completed",
      "role": "assistant",
      "content": [
        {
          "type": "output_text",
          "text": "...",
          "annotations": []
        }
      ]
    }
  ],
  "usage": {
    "input_tokens": 120,
    "output_tokens": 48,
    "total_tokens": 168
  }
}

When max_output_tokens stops generation, the response and retained output items use status: "incomplete" with incomplete_details.reason: "max_output_tokens".

Stateless compatibility

Fusion does not store Responses objects. Send the complete conversation and tool history with each request.

The following OpenAI Responses features are not supported:

  • previous_response_id and conversation;
  • store: true, background execution, and provider-side response retrieval;
  • hosted tools such as web search, file search, computer use, or code interpreter;
  • audio and file input;
  • include, truncation, and metadata;

Syntactically valid unsupported fields are recorded as structured warnings and removed before execution. include: [] and include: ["reasoning.encrypted_content"] are accepted as compatibility hints, but Fusion returns only public reasoning summaries, not encrypted reasoning. Malformed field types and invalid tool definitions still cause validation errors.

Use function or custom/freeform tools for client-executed actions.

SDK example

import os
from openai import OpenAI

client = OpenAI(
    base_url="https://capi.fumolab.ai/api/fusion/v1",
    api_key=os.environ["FUMO_API_KEY"],
)

response = client.responses.create(
    model="fusion-code-1.0",
    input="Review the repository and propose the smallest safe change.",
)

print(response.output_text)

Errors

Validation errors identify the public Responses parameter, such as max_output_tokens or text.verbosity, and use code: "invalid_parameter". Malformed JSON or request field types use code: "invalid_json". Syntactically valid unsupported fields are ignored with structured warnings rather than rejected.

Configure Codex · Use Chat Completions

Model capabilities

All three models support text/image input, text/tool-call output, Chat Completions and Responses. Agents read files; native file upload is not supported.

Only Fusion Max 2.0 supports low, medium, high, and max, defaulting to medium. Max 1.0 and Code 1.0 do not support adjustable effort.