GPT-6

Overview

GPT-6 is the sixth generation of OpenAI's GPT line of large language models. It is sold as a family of tiers that trade cost and speed against capability. It is aimed at general reasoning, coding, writing and assistant work, and it is often used as a reference point when teams compare models. Exact sizes, training data and scores are not published in full, so any claim about internals should be treated with care.

For tabular data, GPT-6 is a text-first model. It reads a table as text, such as CSV, JSON or Markdown, and reasons over it with language skills. This works well for small tables, schema questions, SQL writing and explanation. It is not built to learn directly from millions of raw rows. Models that are pre-trained on tables, covered in /model/research, fill that gap. The two are best seen as partners: a language model plans and explains, and a tabular model predicts.

What it is

GPT-6 is a generative pre-trained transformer. "Generative" means it produces text one piece at a time. "Pre-trained" means it first learned from a very large body of text and code. "Transformer" names the neural network design that lets every token look at every other token in its context.

A family of tiers is typical for this generation of models. A larger tier gives stronger reasoning at higher cost and latency. A smaller tier is faster and cheaper and suits high-volume work. Teams often route easy requests to a small tier and hard ones to a large tier.

What it can usually do

• Answer questions and explain ideas in plain language.
• Write and review code in many languages.
• Follow long instructions and keep a role or format.
• Call tools and functions when given a schema.
• Produce output that matches a JSON schema.
• Read images and other inputs in some tiers.
• Summarize, translate, classify and extract.

What it is not

• It is not a database. It does not store your rows unless you place them in its context.
• It is not a statistics package. It can write code to compute a mean, but its own arithmetic over long columns can be wrong.
• It is not a guarantee of truth. It can produce fluent text that is false.
• It is not a drop-in replacement for a trained predictive model on a large table.

Where it came from

The GPT line began with a 2018 paper on generative pre-training, which showed that a transformer trained to predict the next word could be fine-tuned for many tasks. The underlying transformer design came from the 2017 paper "Attention Is All You Need". Later releases grew in scale and showed that large models could follow instructions from a few examples in the prompt, a trait called in-context learning. The 2020 paper on GPT-3 made that idea well known.

After that, the focus moved from raw scale to usability. Instruction tuning and reinforcement learning from human feedback made models follow requests more reliably. Later generations added longer context, tool calling, image input and stronger step-by-step reasoning. GPT-6 sits in that line. For a related generation, see GPT-5.6.

Trends that shaped this generation

• Longer context windows, so more rows or documents fit in one prompt.
• Reasoning modes that spend extra compute thinking before answering.
• Tool use as a first-class feature, so the model can call code, search and databases.
• Structured output modes that enforce a schema.
• Tiers that let buyers choose a cost point.

How it works

The sections below explain the mechanism with everyday pictures. They describe the general design of this class of model, not any private detail of GPT-6.

Step 1: Break text into tokens

The model does not read letters or words directly. A tokenizer cuts text into small pieces called tokens. A common word may be one token. A rare word may be several. Numbers are often split into chunks, which is one reason arithmetic over long digit strings is error-prone. See BPE and SentencePiece for how tokenizers are built.

Think of tokens like Lego bricks. Any sentence is built from a fixed box of brick types.

Step 2: Turn tokens into vectors

Each token becomes a list of numbers called an embedding. Tokens with similar meaning end up with similar numbers. Position information is added so the model knows order.

Think of an embedding as a pin on a huge map. Nearby pins mean related ideas.

Step 3: Attention

Stacked transformer layers let each token weigh every other token. This weighing is called attention. It lets the model connect a pronoun to its noun, or a column header to a value ten lines below.

Think of a meeting where each person listens to everyone and decides whose comments matter most for their own next sentence.

Step 4: Predict the next token

At the end of the stack the model outputs a probability for every possible next token. One is chosen, added to the text, and the process repeats. This loop is why output arrives piece by piece.

A temperature setting controls randomness. Low values pick the likeliest token. High values allow more variety.

Step 5: Pre-training

During pre-training the model reads huge text and code collections and learns to predict the next token. It gains grammar, facts, code patterns and reasoning habits as a side effect.

Step 6: Post-training

After pre-training, the model is tuned to be helpful and safe. Common methods include supervised fine-tuning on good answers, preference learning and reinforcement learning. See SFT and RLHF.

Step 7: Reasoning and tools at inference

At run time, a reasoning mode can generate hidden or visible intermediate steps before the final answer. Tool calling lets the model emit a structured request, such as a function name and arguments. Your code runs the tool and returns the result. The model then continues. See Function calling and Structured outputs.

A mental model for tables

A table pasted into a prompt becomes a long string of tokens. Row and column structure is only implied by commas, pipes or line breaks. The model must infer the grid from text. That is why format matters. A clean Markdown or CSV layout with clear headers gives better results than a messy paste.

Key concepts and terms

A worked example

This example uses a language model to turn a plain-language question into SQL, then runs the SQL on a table. It shows the safe pattern: the model plans, code computes.

The setup

A table named orders has columns order_id, region, amount and placed_at. The goal is to find the average order amount by region for the last 30 days.

The prompt

You write read-only SQL for PostgreSQL.
Schema:
  orders(order_id int, region text, amount numeric, placed_at timestamp)
Return only SQL. No prose.
Question: average order amount by region for the last 30 days, highest first.

The call

The code below uses a generic client shape. Names are placeholders.

import json
import psycopg

def ask_model(client, prompt):
    reply = client.generate(
        model="gpt-6",
        input=prompt,
        temperature=0,
    )
    return reply.text.strip()

def run_sql(sql):
    forbidden = ("insert", "update", "delete", "drop", "alter")
    if any(w in sql.lower() for w in forbidden):
        raise ValueError("write statements are not allowed")
    with psycopg.connect("postgresql://reader@example.internal/shop") as conn:
        return conn.execute(sql).fetchall()

sql = ask_model(client, prompt)
rows = run_sql(sql)
print(json.dumps(rows, default=str))

A likely result

SELECT region, AVG(amount) AS avg_amount
FROM orders
WHERE placed_at >= NOW() - INTERVAL '30 days'
GROUP BY region
ORDER BY avg_amount DESC;

Why this pattern works

• The model handles language and SQL syntax, which it is good at.
• The database does the arithmetic, which it is exact at.
• A read-only account and a keyword guard limit damage.
• Temperature zero keeps the output stable between runs.

Adding a prediction step

If the next question is "which customers will churn", the language model should not guess from a pasted sample. The better flow is to export features, call a tabular predictor such as TabPFN, and ask the language model to explain the result to a business reader.

A second example: checking a prediction with a tool

This example shows a tool-calling loop. The model is given one tool that scores a row with a tabular predictor. It decides when to call it.

tools = [{
    "name": "score_row",
    "description": "Return churn probability for one customer row",
    "parameters": {
        "type": "object",
        "properties": {
            "tenure_months": {"type": "number"},
            "plan": {"type": "string"},
            "monthly_spend": {"type": "number"},
        },
        "required": ["tenure_months", "plan", "monthly_spend"],
    },
}]

def score_row(tenure_months, plan, monthly_spend):
    # placeholder: call a tabular predictor hosted at example.internal
    return {"churn_probability": 0.31}

messages = [{"role": "user", "content":
    "Customer: 8 months, plan basic, spends 24. Is churn likely? Explain."}]

while True:
    reply = client.chat(model="gpt-6", messages=messages, tools=tools)
    if not reply.tool_calls:
        print(reply.text)
        break
    for call in reply.tool_calls:
        result = score_row(**call.arguments)
        messages.append({"role": "tool", "name": call.name,
                         "content": str(result)})

What to notice

• The number comes from the predictor, not from the language model.
• The language model chooses arguments and writes the explanation.
• The loop ends when the model stops asking for tools.
• A cap on loop count is wise, so a confused model cannot call tools forever.

Numeric walk-through of the cost idea

Suppose a table has 20 columns and each row costs about 60 tokens as CSV. Then 1,000 rows cost about 60,000 tokens. At 100,000 rows the cost is about 6,000,000 tokens, which will not fit in any context window and would be costly even if it did. A tabular predictor reads the same rows as numbers in one pass at a small fraction of that cost. This simple arithmetic explains why row-heavy work leaves the language model.

Strengths and limitations

Strengths

• Strong general reasoning and writing.
• Good code generation and review.
• Flexible: one model handles many tasks with only a prompt change.
• Tool use lets it act on live systems.
• Tiers let teams match cost to need.
• Wide ecosystem of libraries and guides.

Limitations

• Hallucination can occur, especially with numbers and citations.
• Long tables cost many tokens and can exceed context.
• Row-level numeric precision is weak without tools.
• Results can vary between runs unless settings are fixed.
• Behavior can shift between model versions.
• Data sent to a hosted API leaves your network, which matters for regulated data.
• Cost grows with prompt size and output size.

Where the limits bite on tables

How it compares with alternatives

Choosing is rarely about one winner. A practical team tests two or three candidates on its own prompts and tables, scores them with a fixed rubric, and keeps the cheapest that passes. See LLM-as-judge and Evals for ways to score outputs.

Role in tabular foundation models

A tabular foundation model is a model pre-trained to learn from raw tables, so that it can predict, impute or flag anomalies on a new table with little or no task-specific training. GPT-6 is not that kind of model, but it relates to it in concrete ways. The architecture and ideas of tabular models are described at /model/architecture and the evidence at /model/benchmarks.

Text view versus table view

A language model sees a table as a string. A tabular foundation model sees a grid. In the grid view, rows are samples and columns are features, and each cell has a type. The model can attend across rows and across columns. See Axial attention for one way to do both.

A language model must rediscover this grid every time from punctuation. That costs tokens and risks misalignment.

Mixed types and missing values

Real tables mix numbers, categories, dates and free text. A tabular model gives each type a suitable encoding. A language model turns everything into tokens, including numbers, and relies on learned habits. Missing values are a clear case. In a tabular model, a missing cell can be masked and predicted. This is the idea behind Masked cell modeling and Imputation networks. In a prompt, missing cells appear as odd strings, and the model may treat "N/A", "null" and blank differently.

No column names

Many raw tables have headers like col_7. A tabular foundation model can learn from the values alone, since it was pre-trained on tables where names were absent or random. A language model leans on names for meaning. Without them, its advantage fades. When names do exist, a language model is useful for semantic work, such as guessing that dob is a date of birth.

Pre-training on synthetic tables

Tabular foundation models are often pre-trained on large numbers of synthetic tables, drawn from random causal graphs and mechanisms. They learn a general skill of fitting patterns from a table given as context. Language models are pre-trained on text. Their table skill is a by-product. See Synthetic data generation and TabICL.

In-context learning

Both families use in-context learning, in different forms. A language model sees a few input and output examples as text. A tabular model sees the full training table as context and predicts test rows in one forward pass. The tabular version is exact about structure and scales to many more rows per token of cost.

Continual learning

A tabular model can be updated as new data arrives without forgetting old patterns when methods such as Experience replay or EWC are used. A hosted language model is not updated per customer. Teams get "freshness" by retrieval, not by weight change. See Agentic RAG.

Imputation and anomaly detection

For filling gaps or flagging odd rows, a tabular model works on the numbers directly. See Anomaly detection. A language model can still help by explaining why a row was flagged, drafting a ticket, or proposing a rule.

Sector and semantic classification

Deciding what a table is about, such as retail, health or logistics, uses column meaning. A language model is a good fit when headers are readable. A tabular model with semantic heads, as in Semantic sector heads, works from the values and distribution. A combined system can use both and compare.

A sensible division of labor

Practical guidance and best practices

Prompting

• State the role, the task and the output format in the first lines.
• Give the schema explicitly for SQL tasks.
• Use short examples when the format is unusual.
• Ask for JSON that matches a schema when code will read the result.
• Keep temperature low for extraction and SQL.

Working with tables

• Send a sample, not the whole table. Include the header, types and a few rows.
• Describe units and coding for missing values.
• Let tools compute totals, ratios and counts.
• Use a read-only database account.
• Validate every generated SQL statement before running it.

Cost and latency

• Route simple tasks to a smaller tier.
• Cache stable prompt prefixes where the service supports it.
• Trim context. Remove columns the task does not need.
• Stream output when users wait on screen.
• Set budgets per request. See Cost and latency budgets.

Safety and privacy

• Remove or mask personal data before sending it. See Data tokenization.
• Treat retrieved text as untrusted. See Prompt injection defense.
• Log prompts and outputs under your retention rules.
• Add checks on output with Guardrails.

Evaluation

• Build a small fixed test set from real tasks.
• Score with exact checks where possible, such as SQL result equality.
• Use a judge model only with a clear rubric, and spot-check by hand.
• Re-run the set when the model version changes.

Prompt patterns that suit tabular work

A small configuration for a production call

model: gpt-6
temperature: 0
max_output_tokens: 800
timeout_seconds: 30
retries: 2
tools:
  - score_row
  - run_readonly_sql
guardrails:
  block_write_sql: true
  mask_columns: [email, phone, national_id]
logging:
  store_prompts: true
  retention_days: 30

Release checklist

• The prompt, tools and schema are stored in version control.
• A fixed test set runs on every change.
• Latency and cost are tracked per request type.
• A fallback path exists for timeouts and errors.
• A human reviews high-impact outputs.
• Sensitive columns are masked before the call.
• The model version is pinned where the service allows it.

Monitoring after launch

• Track the share of requests that fail schema validation.
• Track tool-call errors and loop counts.
• Sample outputs weekly and read them.
• Watch for drift in user questions, which may need new prompts or new tools.
• Keep a record of which model version produced which output, so incidents can be traced.

Reading a model announcement critically

• Check which tier a published score refers to.
• Check whether tools or extra reasoning time were allowed.
• Check whether the test set may have leaked into training data.
• Check how many runs were averaged.
• Prefer your own test set over any public number.

Governance notes

• Record who approved the use of a hosted model for each data class.
• Keep a list of columns that must never leave your network.
• Review provider terms on data retention before launch.
• Plan an exit path, such as a second model that can take over with a prompt change.

Common mistakes

• Pasting a large table and trusting the sums.
• Asking for a prediction on a big table without a trained predictor.
• Leaving temperature high for extraction work.
• Skipping schema in the SQL prompt, then blaming the model for wrong column names.
• Running generated SQL with write permissions.
• Sending personal data without masking.
• Comparing models on one cherry-picked prompt.
• Assuming a new version behaves like the old one without testing.
• Treating confident wording as evidence of accuracy.
• Ignoring token cost until the invoice arrives.
• Using a judge model that shares biases with the model under test and never checking by hand.

Frequently asked questions

What is GPT-6?

GPT-6 is OpenAI's sixth-generation family of large language models. It is offered in tiers that trade capability against cost and speed, and it is used for reasoning, coding, writing and assistant tasks. Public detail about its size and training data is limited, so teams judge it by testing on their own work.

Is GPT-6 a tabular foundation model?

No. It is a text-first language model that can read tables written as text. A tabular foundation model is pre-trained on tables and works on the grid directly. The two serve different jobs and often work well together.

Can GPT-6 analyze a spreadsheet?

It can read small spreadsheets pasted as text and answer questions, and it can write code or SQL to analyze larger ones. For exact numbers, the better pattern is to let it write the query and let a database or a script do the calculation.

How do I get reliable structured output from it?

Provide a schema, use a structured output mode if your plan offers it, keep temperature low and validate the result in code. If validation fails, retry with the error message in the prompt. This pattern is covered in Structured outputs.

How does it differ from GPT-5.6?

GPT-5.6 belongs to the previous generation and is still widely deployed. GPT-6 is the newer line. Differences in quality, speed and cost vary by task, so the safe answer is to run both on your own test set before switching.

Should I fine-tune it for my tables?

Usually start with better prompts, retrieval and tools. Fine-tuning helps when you need a fixed style or a narrow task at scale. It does not teach the model to out-predict a trained tabular model on your data.

How do I handle private data?

Mask or tokenize sensitive fields before sending them, use a read-only account, apply your retention policy to logs and check the provider terms. For strict cases, keep sensitive work on models you host yourself.

Does a longer context window remove the need for retrieval?

Not fully. A long window lets more text fit, but cost and latency rise with size, and models can miss details in the middle of very long inputs. Retrieval keeps prompts small and focused.

How should I compare it with Gemini 4 or Claude Opus 5.5?

Build a test set from your real tasks, fix the prompts and settings, score outputs with exact checks or a clear rubric, and compare quality, cost and latency together. Leaderboards are a start, not an answer. See Gemini 4 and Claude Opus 5.5.

Can it replace gradient boosting on a classification task?

For tables with many rows, trained models such as XGBoost or a tabular foundation model usually give better and cheaper predictions than prompting a language model. Use the language model around the predictor, not in place of it.

Glossary

• Attention: the mechanism by which tokens weigh other tokens.
• Context window: the token limit for one request.
• Embedding: a numeric vector that represents a token.
• Fine-tuning: extra training on a narrower dataset.
• Hallucination: fluent output that is not true.
• In-context learning: picking up a pattern from examples in the prompt.
• Inference: running a trained model to get output.
• Latency: delay before a response arrives.
• Pre-training: the first large training stage.
• Post-training: tuning after pre-training for helpfulness and safety.
• Structured output: output that must match a schema.
• Temperature: a randomness setting.
• Token: a small unit of text.
• Tool call: a structured request for external code to run.
• Tier: a size and price level inside a model family.
• Tabular foundation model: a model pre-trained on tables for prediction, imputation and related tasks.

Summary

GPT-6 is OpenAI's sixth-generation family of language models, sold in tiers and used for reasoning, coding and assistant work. It reads tables as text, which is fine for small samples, schema questions and SQL writing, but weak for exact arithmetic and large-scale prediction.

The strongest pattern is a split of duties. Let GPT-6 plan, translate questions into queries, name columns and explain results. Let databases compute, and let tabular foundation models, described at /model/research, /model/architecture and /model/benchmarks, learn from the raw rows. Test on your own tasks, keep data private, validate outputs, and re-check when versions change.

Related

It belongs to Frontier models in my stack, under LLMs, retrieval, and evaluation. Others in the same group: