Model Library
Browse and deploy state-of-the-art AI models through the DEVUP Gateway.
Browse and deploy state-of-the-art AI models through the DEVUP Gateway.
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.
A fast, affordable small model for focused tasks. Text and images in, text out.
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.
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.
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.
| Model ID | openai/gpt-4o-mini |
| Snapshot | gpt-4o-mini-2024-07-18 |
| Context window | 128,000 tokens |
| Max output | 16,384 tokens |
| Knowledge cutoff | 1 October 2023 |
| Input | Text, image |
| Output | Text |
| Audio | Not supported |
| Video | Not supported |
| Speed | Fast |
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.
| Capability | Value |
|---|---|
input_types | text, image |
output_types | text |
audio_input | Not supported |
video_input | Not supported |
context_window | 128000 |
max_output_tokens | 16384 |
reasoning | Not applicable |
streaming | Supported |
tool_calling | Supported |
structured_output | Supported — JSON schema |
predicted_outputs | Supported |
fine_tuning | Supported |
requires_prompt | Yes — text prompt required, image optional |
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.
Base URL: https://api.devupai.com/v1 · Model ID: openai/gpt-4o-mini
One of OpenAI's own named use cases.
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.
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.
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.
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.
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.
Where a small model saves the most inside a larger system.
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.contentA 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.
npm install devupaiimport 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);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.
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.
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.