Gender-API vs. ChatGPT: which should determine the gender of a name?
Both can tell you that Sandra is usually female. Only one of them can tell you how it knows, give you the same answer next year, and price a million names before you start.
The short answer
- Use an LLM when you need a judgement about a handful of names, or prose you can read — an explanation, an origin, a salutation.
- Use a name database when the answer has to be identical tomorrow, has to come with evidence, has to be priced per record, or has to survive a question from a data-protection officer.
- At volume the deciding difference is not accuracy — it is accounting. 9,124,598 first names across 192 countries, each answer carrying its own sample count, against a generation that cannot show its work.
- They combine well. Give the model the API as a tool — we publish a hosted MCP server for it — and the label comes from the data while the wording comes from the model.
What the two things actually are
Gender-API.com is a lookup service over a name database. 9,124,598 first names, broken down by the country they were observed in, 192 countries supported. You send a name, you get back a gender, a probability and the number of samples the answer rests on. Nothing is generated.
ChatGPT — and every other general-purpose language model — is a text generator. It knows that "Sandra" appears in female contexts because that is how the word behaved in its training text. That is a genuinely useful signal, and for common names it produces the right label. But there is nothing in the architecture that stores how many Sandras were female in Portugal, so there is nothing to quote, threshold or audit.
That single structural fact drives every practical difference below.
SIDE BY SIDE
The differences that hold regardless of which model you pick.
| What you need | Gender-API.com | General-purpose LLM |
|---|---|---|
| Same answer for the same input, every time | Yes — it is a database lookup | No — sampling, prompt wording and model version all move it |
| Evidence behind a single answer | Sample count and probability per result, per country | None; a confidence number, if asked for, is itself generated |
| Coverage you can state in writing | 9,124,598 names, 192 countries | Unknown and unstated |
| Country-specific answers | A country, locale or IP parameter changes the result | Only if you say so in the prompt — and it is still a guess |
| Behaviour in twelve months | Same endpoint contract, published as OpenAPI; v1 and v2 both still live | Models are deprecated and replaced; answers shift with them |
| Batch processing | 100 names per request, or a CSV of up to 10 million rows | Context limits, chunking, rate limits and retries you write yourself |
| Unit of cost | One credit per lookup, from a package you bought in advance | Tokens in and out — varies with prompt length and retries |
| Where the data is processed | Servers in Germany, processing inside the EU, DPA on request | Depends on the vendor, the plan and the region you are given |
| Splitting a full name, reading a name out of an e-mail address | Dedicated endpoints | Prompt engineering, and it fails silently on edge cases |
| A name nobody has data for | Says so — result_found is false, or the probability is low | Answers anyway, in the same confident tone |
| Explaining a name, its origin or its variants | Not what it is for | Genuinely better — this is what a language model is for |
What does it cost to determine the gender of a million names?
Here is the method rather than a marketing number, so you can redo it with today's rates.
With an API: One lookup is one credit. Our best published volume rate works out at about €0.35 per 1,000 names, so a million names is roughly €349 net — a fixed amount, known before you start, on a VAT invoice. Credits from one-off packages do not expire.
With an LLM: You pay per token, in both directions, for every request and every retry. Batching several names into one prompt brings the per-name cost down, but you re-send the instructions with every batch, long names and unusual scripts cost more tokens than short ones, and a malformed answer costs you the retry as well. The result is an estimate, not a number you can put in a budget.
To be fair about it: for a few thousand names, a general model is cheap enough that none of this matters. The crossover arrives with scale — and earlier than the token price suggests, because the engineering around batching, retries and validating the output is work you do not have to do against a lookup endpoint.
Reproducibility: the point that usually decides it
Gender a customer list twice and get two different results, and you now own a problem you cannot explain: which run was right, what changed, and what do you tell the person who was addressed as "Mr" last month and "Ms" this month.
A lookup is deterministic. The same name with the same country returns the same gender, the same probability and the same sample count. When the underlying data grows, the sample count grows with it — visibly, in the response — so a change is something you can point at rather than something that just happened.
A generated answer has no such guarantee. Temperature, a new model version, a reworded system prompt, a safety adjustment you were not told about: any of them can flip a borderline name, and none of them leaves a trace in your data.
Every answer carries its own evidence
A single request to the v2 endpoint:
POST https://gender-api.com/v2/gender/by-first-name
{ "first_name": "Sandra" }{
"input": { "first_name": "Sandra" },
"details": {
"credits_used": 1,
"samples": 464,
"country": null,
"first_name_sanitized": "sandra",
"duration": "436ms"
},
"result_found": true,
"first_name": "Sandra",
"probability": 0.85,
"gender": "female"
}Two fields do the work that no generated answer offers. "samples" is how many observations the answer rests on, and "probability" is the share of them that were female. Together they let you set your own bar — accept results above 0.9 with a decent sample count, send the rest to manual review — instead of accepting one confidence level for your whole database.
Full reference: the v2 API documentation.
The same name is not the same gender everywhere
Andrea is predominantly male in Italy and predominantly female in Germany. Jean is male in France and largely female in English-speaking countries. Nikita is male in Russia and usually female elsewhere. These are not exotic edge cases — they are ordinary names in ordinary customer lists.
Ask a general model without naming a country and you get whichever reading dominated its training text, which in practice means the English-language one. The API takes the country explicitly:
A locale (en_US) or the visitor's IP address work just as well, and there is a separate endpoint for the reverse question — which country a name comes from.
GDPR, and where the names you send actually go
First names of real customers are personal data, so this is a procurement question, not a footnote. What we can state plainly:
- We are a German company; all our servers are located in Germany and the data is processed inside the EU.
- A data-processing agreement can be requested in your account.
- Server logs contain the submitted name and are kept for 14 days, for accounting reasons.
- Uploaded CSV and Excel files are stored encrypted and deleted after ten days.
- Every purchase produces a proper VAT invoice, and EU VAT IDs are handled correctly.
Whether a given model vendor is acceptable for the same data is a question for your data-protection officer — but it is a longer question, and one you have to ask again each time the vendor changes a sub-processor. Our answers are on the privacy overview.
When ChatGPT is the better choice
This page would not be worth reading if the answer were always "buy the API". It is not:
- A one-off job. Forty names in a spreadsheet, no pipeline, nobody will ever re-run it.
- You want the reasoning, not the label — the origin of a name, its variants, how it is normally shortened, how to address someone politely in a given culture.
- Names no database has: new coinages, fictional characters, transliterations that exist in no registry. A model will make a reasonable guess where a lookup simply has nothing.
- The output you need is free text, not a field — a greeting line rather than a gender column.
We are not being generous here, we use them the same way: the name-origin descriptions on our own name pages are generated by a language model, because prose is what a language model is good at.
The best setup is both: let the model call the API
If you are already building on an LLM, you do not have to choose. Modern models call tools, and a gender lookup is an ideal tool: a narrow question with a factual answer the model has no data for.
We publish a hosted MCP server so any MCP-capable assistant or agent can query the database directly. Its tools are query_first_name, query_full_name, query_email, get_country_of_origin and get_statistics.
For your own tool definitions there are official clients for nine languages (PHP, Python, Node, Java, Go, Ruby, Rust, Perl, .NET), an OpenAPI description, and a prompt-ready implementation guide at /skill.md that you can hand straight to a coding assistant.
The division of labour is the point: the model decides what to do, the database decides what is true.
Frequently asked questions
Can ChatGPT determine the gender of a name?
Yes, and for common first names it is usually right. What it cannot do is tell you how many records the answer rests on, guarantee the same answer twice, or give a different answer for the same name in a different country. It also answers just as confidently for names it has never seen, which is the failure mode that matters at scale.
Is a gender API more accurate than an LLM?
For a name that exists in a name database, a lookup is accurate by construction: it reports the observed distribution rather than an inference. For an unknown name neither approach can be trusted, but only the lookup admits it. The reliable difference is not a single accuracy percentage — it is that every lookup arrives with a sample count and a probability you can threshold on.
How much does it cost to determine the gender of one million names?
With Gender-API one lookup costs one credit, so a million names is a fixed, known amount — about €349 net at our best published volume rate, on a VAT invoice, agreed before you start. With an LLM you pay per token for every request and every retry, so the bill depends on your prompt length and can only be estimated.
Can I use an LLM and a gender API together?
Yes, and it is the best setup. Give the model the API as a tool — we publish a hosted MCP server for exactly this — and the label comes from the database while the wording comes from the model. The model stops guessing about facts it has no data for.
Does the same name have the same gender in every country?
No, and this is where prompting an LLM without a country goes wrong. Andrea is predominantly male in Italy and predominantly female in Germany; Jean is male in France and largely female in English-speaking countries. The API takes a country, locale or IP address and answers for that country.
What happens with a name the database does not know?
You get result_found: false, or a low probability with a small sample count. That is a signal you can act on — route those records to manual review, or fall back to a model. A generative answer gives you no such signal.
Is Gender-API GDPR compliant?
We are a German company, all servers are located in Germany and the data is processed inside the EU. A data-processing agreement can be requested in your account. Request logs, which contain the submitted name, are kept for 14 days for accounting reasons; uploaded CSV and Excel files are stored encrypted and deleted after ten days.
TRY IT ON YOUR OWN NAMES
Every account includes 100 free lookups per month — enough to check the names an LLM got wrong. No credit card.
API documentation · Genderize a CSV or Excel file · MCP server
