Which LLM Providers Support Vision or Image Input in FreeLLMAPI?

Google Gemini models (e.g., gemini-2.5-flash, gemini-2.5-pro) are currently the only vision-capable providers in FreeLLMAPI, while all other platforms reject image inputs with a 422 error.

FreeLLMAPI routes multimodal requests through a SQLite-backed model catalog that flags vision capabilities per provider. Only Google's Gemini family has the supports_vision bit enabled in the database schema, making it the sole option for processing image URLs or base64-encoded pictures through the unified API.

How FreeLLMAPI Detects Vision Capabilities

The system distinguishes vision models using a boolean supports_vision column in the SQLite models table. During the legacy baseline migration located at server/src/db/migrations/20260101_000000_legacy_baseline.ts, the flag is explicitly set for Google:

UPDATE models SET supports_vision = 1 WHERE platform = 'google'

All other providers—including OpenAI-compatible endpoints, Cohere, Cloudflare, and AI Horde—retain the default supports_vision = 0 value, effectively blocking image processing at the routing layer.

Supported Vision Providers

Google Gemini Models

The GoogleProvider class in server/src/providers/google.ts handles the actual transmission of image payloads to the Gemini API. When a request contains an image block, the provider forwards the data and extracts any returned tool calls or text content. Supported models include:

• gemini-2.5-flash
• gemini-2.5-pro
• gemini-3.5-flash

Text-Only Providers

The following platforms are configured without vision support and will reject image inputs:

• OpenAI-compatible endpoints
• Cohere
• Cloudflare Workers AI
• AI Horde

Router Enforcement and Error Handling

The core routing logic in server/src/routes/proxy.ts validates vision requests before forwarding them to providers. The router calls hasEnabledVisionModel() to verify that at least one Gemini model is active in the fallback chain. If a user submits an image payload without an enabled vision model, the API returns an HTTP 422 error with the code no_vision_model and a message listing available vision options such as "Gemini 2.5 Flash, Llama 4 Scout".

Working with Vision Inputs

Sending an Image Request to Gemini

To process an image, construct a message with an OpenAI-style image_url block and target a Gemini model:

import { fetchChat } from './client/src/lib/api';

const messages = [
  {
    role: 'user',
    content: [
      { type: 'text', text: 'What do you see in this picture?' },
      {
        type: 'image_url',
        image_url: { url: 'https://example.com/cat.jpg' }
      }
    ]
  }
];

await fetchChat({
  model: 'gemini-2.5-flash',
  messages,
  max_tokens: 1024
});

Handling the "No Vision Model" Error

Wrap your API calls to catch the specific error when vision models are disabled:

try {
  await fetchChat({ model: 'gemini-2.5-flash', messages });
} catch (e: any) {
  if (e?.code === 'no_vision_model') {
    console.error('Vision models are not enabled. Enable a Gemini model in the Fallback Chain.');
  } else {
    throw e;
  }
}

Enabling Vision Support via SQL

If managing the database directly, enable a specific Gemini model for vision processing:

UPDATE models 
SET enabled = 1 
WHERE platform = 'google' 
  AND model_id = 'gemini-2.5-flash';

The Playground UI surfaces this capability through the Fallback page, where models display a "Vision" badge defined in client/src/pages/ModelDetailPage.tsx based on the supports_vision field from shared/types.ts.

Key Source Files

• server/src/routes/proxy.ts — Core routing logic that checks hasEnabledVisionModel() and returns the no_vision_model error.
• server/src/db/migrations/20260101_000000_legacy_baseline.ts — Database migration that sets supports_vision = 1 for Google platforms.
• server/src/providers/google.ts — Provider implementation that forwards images to Gemini and handles tool-call extraction.
• shared/types.ts — TypeScript definitions for ModelMeta, including supports_vision and supports_tools fields.
• client/src/pages/ModelDetailPage.tsx — UI component that renders the "Vision" capability badge.

Summary

• Google Gemini is the sole vision-enabled provider in FreeLLMAPI, identified by supports_vision = 1 in the SQLite catalog.
• Other providers (OpenAI-compatible, Cohere, Cloudflare, AI Horde) explicitly disable vision support and reject image inputs.
• The router enforces vision requirements by checking hasEnabledVisionModel() in proxy.ts, returning a 422 error if no suitable model is enabled.
• Image payloads use standard OpenAI-style image_url blocks and are processed by the GoogleProvider class.
• The database migration at 20260101_000000_legacy_baseline.ts initializes vision flags, while the UI reflects these capabilities via ModelDetailPage.tsx.

Frequently Asked Questions

Does FreeLLMAPI support image inputs for OpenAI models?

No. According to the source code in server/src/db/migrations/20260101_000000_legacy_baseline.ts, only the Google platform receives supports_vision = 1. OpenAI-compatible endpoints retain the default 0 value and will trigger a no_vision_model error if images are submitted.

How do I enable vision capabilities in FreeLLMAPI?

Vision capabilities require enabling a Google Gemini model in your fallback chain. You can toggle the model switch in the Playground UI's Fallback page (which displays a "Vision" badge), or execute an SQL update: UPDATE models SET enabled = 1 WHERE platform = 'google' AND model_id = 'gemini-2.5-flash'.

What error does FreeLLMAPI return if I send an image without a vision model?

The router in server/src/routes/proxy.ts returns an HTTP 422 response with the error code no_vision_model. The error message lists available vision-capable models such as "Gemini 2.5 Flash" to guide configuration.

Can I use base64-encoded images with FreeLLMAPI?

Yes. The GoogleProvider implementation accepts standard OpenAI-style content blocks, including base64-encoded image_url objects with data URIs (e.g., data:image/jpeg;base64,...), provided you target a Gemini model with vision support enabled.

{
  "mcpServers": {
    "instagit": {
      "command": "npx",
      "args": ["-y", "instagit@latest"]
    }
  }
}