ModelsOpenAIgpt-4o-mini
provideropenai /

gpt-4o-mini

52.5 DZD in 210 DZD out 26.25 DZD cached/ 1M tokens

GPT-4o mini is a fast, affordable small model for focused tasks — and its appeal is what it leaves out. There is no reasoning pass, no effort level, no deliberation budget to tune: it reads the prompt and answers, which makes its latency predictable and its behaviour easy to reason about. It accepts text and images against a 128,000-token context window, returns structured output against a JSON schema, calls functions, and supports predicted outputs for edit-style tasks. It is also built for fine-tuning: outputs from a larger model can be distilled into it to produce comparable results on a narrow task at lower cost and latency.

PublicJSONStreaming
gpt-4o-mini
Capabilities
ToolsVisionStructured output
ArchitectureProprietary
Context Window128K

Use gpt-4o-mini in VS Code, Cursor and Antigravity

DEVUP Code, the DEVUP AI extension, is free to install. Requests are paid from your DEVUP balance.

Explore DEVUP Code

GPT-4o mini

A fast, affordable small model for focused tasks. Text and images in, text out.


Its Advantage Is Simplicity

Every model added to this catalogue in the last year carries a reasoning control. Effort levels, thinking modes, deliberation budgets, persistence settings — each one a decision to make and a default that is wrong for some of your paths.

This model has none of them. It reads the prompt and answers.

That matters more than it sounds. A model with no reasoning pass has predictable latency: time to a response depends on input and output length, not on how hard the model decided the question was. For an endpoint sitting in front of a user, or a worker draining a queue, that predictability is frequently worth more than a better answer arriving in a variable amount of time.

There is also nothing to misconfigure. No effort level that silently escalates, no default that differs from the model beside it in the catalogue, no parameter that works on one model and errors on another.


What OpenAI Built It For

The prompt examples on the model's own documentation page are unusually specific, and worth reading as a statement of intent:

Intent classification · Extract search keywords · Translate text · Generate tags

Four narrow, high-volume transformations. Not analysis, not planning, not open-ended reasoning — mechanical work done many times where the definition of correct is clear.

That is the shape of task this model is for, and matching it is how you get good results rather than fighting the model into producing them.


Fine-Tuning

The capability that separates this model from most of what surrounds it in the catalogue.

OpenAI describes it as ideal for fine-tuning, and specifically for distillation: take outputs from a larger, more capable model on your task, use them as training data, and produce a small model that performs comparably on that narrow task.

Why that is worth considering. Prompting is how you adapt a model without training it, and it costs input tokens on every single call. A long system prompt with examples, repeated across a million requests, is a permanent tax. Fine-tuning moves that instruction into the weights — the behaviour comes free on every subsequent call, and the prompt shrinks to the actual input.

When it makes sense: a high-volume task with a stable definition, where you have or can generate a few hundred to a few thousand good examples. Classification into a fixed taxonomy. Extraction into a fixed schema. Responses in a specific house style.

When it does not: anything whose definition changes often, anything with too few examples, and anything where a better general model simply solves the problem.


Specifications

Model IDopenai/gpt-4o-mini
Snapshotgpt-4o-mini-2024-07-18
Context window128,000 tokens
Max output16,384 tokens
Knowledge cutoff1 October 2023
InputText, image
OutputText
AudioNot supported
VideoNot supported
SpeedFast

Specifications as published by OpenAI. The model's construction is not disclosed — no parameter count, no architecture, no weights.

Snapshots let you lock a specific version so behaviour stays consistent. Where reproducibility matters, pin the dated snapshot rather than the moving alias.


Capabilities

CapabilityValue
input_typestext, image
output_typestext
audio_inputNot supported
video_inputNot supported
context_window128000
max_output_tokens16384
reasoningNot applicable
streamingSupported
tool_callingSupported
structured_outputSupported — JSON schema
predicted_outputsSupported
fine_tuningSupported
requires_promptYes — text prompt required, image optional

Knowledge Stops in October 2023

Worth stating plainly rather than burying in a limitations list, because it causes a wrong answer rather than an error.

Anything after that date — library versions, API changes, events, standards, people in roles — is outside what this model knows. It will not say so. It will answer from what it learned, and the answer will be confident and dated.

Two ways to handle it.

Supply the facts. Retrieval, tool calls, or documents in the prompt move the model from recalling to reading — and reading is where a small model performs closest to a large one.

Instruct it to decline. A system prompt that permits "I don't know" and forbids answering from memory on time-sensitive questions does real work.

For anything where currency matters and grounding is not possible, use a model with a more recent cutoff.


Using It on DEVUP AI

Base URL: https://api.devupai.com/v1 · Model ID: openai/gpt-4o-mini

Intent classification — cURL

One of OpenAI's own named use cases.

BASH
curl https://api.devupai.com/v1/chat/completions \
  -H "Authorization: Bearer $DEVUP_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "openai/gpt-4o-mini",
    "messages": [
      {
        "role": "system",
        "content": "Classify the support ticket. Reply with exactly one word: billing, technical, shipping, or other."
      },
      { "role": "user", "content": "My order never arrived and the tracking page is blank." }
    ],
    "max_tokens": 8,
    "temperature": 0
  }'

temperature: 0 on a classification task. This model has no reasoning control, but it does have sampling — and for a task with one correct answer, variance is not a feature.

Structured extraction — Python

PYTHON
import os
import json
from openai import OpenAI

client = OpenAI(
    api_key=os.environ["DEVUP_API_KEY"],
    base_url="https://api.devupai.com/v1",
)

SCHEMA = {
    "type": "json_schema",
    "json_schema": {
        "name": "receipt",
        "strict": True,
        "schema": {
            "type": "object",
            "properties": {
                "merchant": {"type": ["string", "null"]},
                "total": {"type": ["number", "null"]},
                "currency": {"type": ["string", "null"]},
                "date": {"type": ["string", "null"]},
            },
            "required": ["merchant", "total", "currency", "date"],
            "additionalProperties": False,
        },
    },
}


def extract(text: str) -> dict:
    """Pull typed fields from a receipt, returning null for anything absent."""
    response = client.chat.completions.create(
        model="openai/gpt-4o-mini",
        messages=[
            {
                "role": "system",
                "content": "Extract only fields present in the source. Use null for anything absent — never infer.",
            },
            {"role": "user", "content": text},
        ],
        response_format=SCHEMA,
        max_tokens=512,
        temperature=0,
    )
    return json.loads(response.choices[0].message.content)

Every field nullable, and an instruction never to infer. A schema forbidding null on a small model is an invitation to produce a value where the source has none — and on an extraction pipeline running at volume, that error stays invisible until someone acts on it.

Predicted outputs — Python

A capability worth knowing about, and easy to miss.

When most of the output is already known — you are editing a document, refactoring a file, adjusting one field in a block of JSON — supplying the expected result as a prediction reduces the time to a response substantially. The model is confirming rather than composing.

PYTHON
original = open("config.json", encoding="utf-8").read()

response = client.chat.completions.create(
    model="openai/gpt-4o-mini",
    messages=[
        {"role": "system", "content": "Return the complete file with the requested change applied. Output only the file."},
        {"role": "user", "content": f"Change the timeout to 30 seconds.\n\n{original}"},
    ],
    max_tokens=4096,
    temperature=0,
    prediction={"type": "content", "content": original},
)

The prediction is the original file. Most of the output will match it, and the parts that do not are the edit. On large files with small changes this is the difference between a noticeable wait and an immediate response.

Reading an image — Python

PYTHON
import base64

with open("receipt.jpg", "rb") as handle:
    encoded = base64.b64encode(handle.read()).decode("utf-8")

response = client.chat.completions.create(
    model="openai/gpt-4o-mini",
    messages=[
        {
            "role": "user",
            "content": [
                {
                    "type": "image_url",
                    "image_url": {"url": f"data:image/jpeg;base64,{encoded}"},
                },
                {
                    "type": "text",
                    "text": "Read the total and the currency. Reply as JSON with keys total and currency, using null for anything you cannot read.",
                },
            ],
        }
    ],
    max_tokens=128,
    temperature=0,
)

Images consume input tokens on any model. Keeping the question narrow — two fields rather than a full description — is what keeps a visual extraction path affordable at volume.

As a subagent — Python

Where a small model saves the most inside a larger system.

PYTHON
def condense(raw: str) -> str:
    """Shrink a large tool result before it re-enters an expensive model's context."""
    response = client.chat.completions.create(
        model="openai/gpt-4o-mini",
        messages=[
            {
                "role": "system",
                "content": (
                    "Condense this tool output to the facts a downstream agent needs. "
                    "Preserve every identifier, number, and error message exactly. "
                    "Drop formatting, repetition, and anything decorative."
                ),
            },
            {"role": "user", "content": raw},
        ],
        max_tokens=1024,
        temperature=0,
    )
    return response.choices[0].message.content

A verbose tool result entering a large model's context on every turn of a long agent loop is one of the more expensive habits in agent design. Condensing it here first costs a fraction of what it saves, and mechanical transformation is exactly what a small model handles well.

Node.js

BASH
npm install devupai
JAVASCRIPT
import DevupAI from "devupai";

const client = new DevupAI({
  apiKey: process.env.DEVUP_API_KEY,
});

const response = await client.chat.completions.create({
  model: "openai/gpt-4o-mini",
  messages: [
    {
      role: "system",
      content: "Extract the search keywords from this query. Reply with a JSON array of strings, nothing else.",
    },
    { role: "user", content: userQuery },
  ],
  max_tokens: 128,
  temperature: 0,
});

console.log(response.choices[0]?.message?.content);

Streaming

PYTHON
stream = client.chat.completions.create(
    model="openai/gpt-4o-mini",
    messages=[{"role": "user", "content": "Summarise this thread in three sentences."}],
    max_tokens=512,
    stream=True,
)

for chunk in stream:
    if chunk.choices and chunk.choices[0].delta.content:
        print(chunk.choices[0].delta.content, end="", flush=True)

With no reasoning pass, the first token arrives immediately rather than after a deliberation phase — which is what makes this model usable in interactive interfaces where a reasoning model would feel stalled.


Running It at Volume

The tasks this model suits are the tasks that run thousands of times, so the things that go wrong are throughput problems.

Set a tight max_tokens. A one-word classification does not need a 4,096-token ceiling. The ceiling is not what you pay, but it caps what an unexpected response can cost.

Use temperature: 0 for anything with one correct answer. Classification, extraction, routing. Variance on a deterministic task is noise you are paying for.

Prefer schemas over parsing prose. A schema removes both a failure mode and a post-processing step.

Watch the input side. On short outputs, the prompt frequently costs more than the completion. A long system prompt repeated across a million calls is the largest line in many high-volume pipelines — and the strongest argument for fine-tuning it away.

Batch where the shape allows it. Classifying twenty short items in one request costs far less in overhead than twenty separate requests.

Use predicted outputs on edit-style tasks. When most of the output is already known, supplying it turns composition into confirmation.

Debounce anything triggered by typing. A search box or autocomplete firing on every keystroke is the classic way a cheap model produces an expensive bill.

Cap retries. A failing item retried without a ceiling is a loop.


When to Choose It

Strong fit for classification, extraction, tagging, translation, keyword generation, routing, and reformatting at volume; for subagents inside a larger system; for interactive paths where predictable low latency matters more than depth; and for any narrow, stable task worth fine-tuning.

Weaker fit for multi-step reasoning, complex analysis, difficult code, and anything depending on knowledge after October 2023.

The clearest signal to move up: if you are writing increasingly elaborate prompts to coax a correct answer out of this model, a more capable one will get there with a simpler prompt and probably fewer total tokens.


Limitations

  • Knowledge ends October 2023. Anything later requires retrieval or a search tool, and the model will not tell you when it is out of date.
  • No reasoning capability. Multi-step logic, complex analysis, and difficult problems belong on a model built for them.
  • 16,384-token output ceiling, well below the context window.
  • Text and images in, text out. Audio and video are explicitly unsupported, and the model does not generate images.
  • Architecture is not disclosed — no parameter count, no structure, no weights.
  • Standard foundation-model limitations apply, including hallucination. Validate any extracted figure before it reaches a system of record.
  • Bound retries and loops with a ceiling.
  • Not a safety layer. Apply your own moderation and validation before acting on model output in a production system.