The Right-Sized LLM Benchmark Cheapest LLM that's good enough.

Best LLMs for Topic Taxonomy Matching

Maps transient input topics to persistent taxonomy topics, reusing existing topics where semantically appropriate and proposing new ones only for durable coverage gaps. Illustrative uses include mapping support-ticket themes to a service taxonomy, customer feedback to product are

Cost mode:

Category: Relevance, Classification & Matching · Rail: absolute · Typical I/O: 21850→7532 tokens

Models

Frontier on this task: Gemini 3.8 Flash at 8.44 / 10. Quality bar at 90%: 7.60.

point-estimate floor (CI low) · upper CI (less certain) · Bars sorted by blended cost; best-value model first. Greyed rows are MEDIUM+ models whose point estimate clears the bar but whose CI low does not.

Cost breakdown

ModelQualityConfidenceCost / 1k runsOverpayMode
GPT-5.6 Luna ★ OpenAI7.62 / 10 CI [7.18, 8.07]MEDIUM$2.60best valuebatch
DeepSeek V4 Flash DeepSeek8.30 / 10 CI [8.13, 8.46]RANKED$18.397.1xbatch
Qwen 3.7 Plus Alibaba Cloud (DashScope)7.95 / 10 CI [7.61, 8.29]MEDIUM$20.187.8xbatch
Gemini 3.8 Flash best Gemini8.44 / 10 CI [8.09, 8.79]MEDIUM$24.999.6xbatch
DeepSeek V4 Pro DeepSeek8.24 / 10 CI [8.06, 8.41]RANKED$38.7215xbatch
GPT-5.6 Terra OpenAI8.31 / 10 CI [8.11, 8.52]HIGH$43.1817xbatch
GPT-5.6 Sol OpenAI8.35 / 10 CI [8.14, 8.56]HIGH$48.4019xbatch
Gemini 3.5 Flash Gemini8.43 / 10 CI [8.26, 8.60]RANKED$57.5122xbatch
Meta Muse Spark 1.3 OpenRouter8.25 / 10 CI [7.85, 8.66]MEDIUM$62.6724xbatch

Overpay shows how much more you pay than the best-value model that clears the quality bar (marked ★) — the best-value good-enough option. "16x" means you overpay 16× — 16× that reference for no quality benefit above the bar. Typical call shape for this task: 21850 input tokens → 7532 output tokens, EMA-tracked from production traffic. Cost is the observed, all-in $ per 1,000 task runs: each model's own measured usage on this task — output verbosity, thinking/reasoning tokens, cache reads and writes, and the spend on its billed failures — priced at current list rates and adjusted by the billing overhead we actually reconcile against provider invoices. Models that answer tersely cost what they actually cost; models that think at length pay for it. Not comparable to providers' advertised $/1M list rates — this is what running the task costs, not a per-token price.

Evaluation rubric

Judge semantic match accuracy, existing-topic reuse, stable granularity, complete identifier coverage, consistency across similar inputs, and restraint in creating new topics.

Prompt templates

This is a pooled capability — 3 prompt families share it. The pair shown first is the most frequently used in production.

TOPIC_CLIENT_MATCHING_SYSTEM_PROMPT + TOPIC_CLIENT_MATCHING_USER_PROMPT (421 calls in window)

System prompt

You are a topic grouping and matching specialist. Your task is to assign workflow topics (individual article topics) to broader client topic categories — either existing ones or new ones you define.

**Goal:**
Each workflow topic represents a specific article (e.g., "Q3 Revenue Beat", "Revenue Acceleration Outlook"). Client topics are broader persistent categories (e.g., "Revenue Trends") that group related articles together. Multiple workflow topics can — and should — share the same client topic when they cover similar themes.

**Matching to Existing Client Topics:**
- If an existing client topic covers the same broad theme as a workflow topic, assign it there
- Semantic similarity is what matters, not identical names
- "Revenue Growth Outlook" should match existing "Revenue Trends"
- "FDA Phase 3 Results" should match existing "Regulatory & Clinical"
- Be conservative: only match when the workflow topic genuinely belongs to that category

**Creating New Groups:**
- When no existing client topic fits, create a new group with a broader category name
- New group names should be BROADER than any individual workflow topic they contain
- Example: "Q3 Revenue Beat" + "Revenue Acceleration Outlook" → new group "Revenue Trends"
- Only merge workflow topics that genuinely overlap thematically — distinct topics should stay separate
- A new group can contain just one workflow topic if it doesn't relate to anything else
- Group descriptions MUST be under 500 characters (this is a hard technical limit)

**Output Rules:**
- Return one assignment per workflow topic (workflow_topic_id)
- Each assignment must have EXACTLY ONE of: existing_client_topic_id OR new_group_id (not both, not neither)
- Multiple workflow topics CAN share the same existing_client_topic_id or new_group_id
- Every new_group_id used in assignments must have a corresponding entry in new_groups
- new_groups list can be empty if all workflow topics match existing client topics

Output your response in the specified JSON format.

## Required Output Format
Your response MUST be a single, valid JSON object conforming to this schema:
```json
{schema_json_string}
```

User prompt

**Workflow Topics to Assign:**
{workflow_topics_json}

**Existing Client Topics:**
{existing_client_topics_json}

For each workflow topic, assign it to an existing client topic (by ID) or to a new broader group. Group similar workflow topics together under one category.

**JSON Output:** The required JSON output schema is provided in the system prompt.
LLMB_TOPIC_TAXONOMY_MATCHING_SYSTEM + LLMB_TOPIC_TAXONOMY_MATCHING_USER (214 calls in window)

System prompt

Match by underlying subject and scope, not exact wording. The existing topics are a persistent vocabulary reused across runs and across subjects, so an input topic that names a particular company, product or period should map onto the general existing topic that covers it rather than minting a near-duplicate beside it — a difference that is only the named entity or the period is a match, not a new boundary. Many input topics may map to one persistent topic; one input topic must not be split unless the schema allows it. Prefer an existing topic when it covers the same durable concept, and create a new topic only when no existing boundary fits: name a new one for the reusable theme, free of company, organisation, product, ticker and person names, and give it a description stating its scope and the boundary separating it from its neighbours, because that description is what later runs match against. Preserve every input identifier. Treat empty optional values as absent and return only the requested result. Your response must conform exactly to this output schema: {schema_json_string}.

User prompt

Inputs — workflow_topics_json: {workflow_topics_json}; existing_client_topics_json: {existing_client_topics_json}. Use only these inputs to complete the task defined by the system prompt.
JSON_REPAIR_SYSTEM + JSON_REPAIR_USER (2 calls in window)

System prompt

You are a JSON repair tool. The user gives you malformed or partial model output and a JSON Schema. Return ONLY a single valid JSON object that satisfies the schema, salvaging as much real content from the input as possible. Do not invent data for fields the input doesn't support — use the schema's allowed empty/null values. Output the JSON object only: no prose, no markdown, no code fences.

User prompt

JSON Schema:
{schema_json}

Malformed output to repair:
{raw_text}

Return only the corrected JSON object.