n8n Text Classifier Node: Built-in vs Calling Jev from a Workflow

According to n8n docs, the Text Classifier classifies each incoming item with categories you define (name + description). The input prompt usually references a field such as text or chatInput. You attach a chat-model sub-node (OpenAI, OpenRouter, and others). Each category becomes an output handle so downstream nodes wire directly—without building Agent + Switch boilerplate. Optional settings cover multi-class selection, discarding unmatched items or routing them to an Other branch, a customizable system prompt template with a {{categories}} placeholder, and auto-fixing when the model output fails schema parsing.

The built-in node shines when classification is primarily a routing problem inside n8n: one ticket body in, N department branches out. Category descriptions steer the model better than bare names. Auto-fixing reduces brittle JSON parse failures. Teams usually hit limits when they need (1) confidence they can threshold consistently across models, (2) the same label contract in apps outside n8n, (3) abstention before refunds or PII actions, or (4) Score/Noul-style rubrics beyond a flat category list. n8n has floated opt-in confidence scores on the Text Classifier; treat vendor confidence as a weak signal until you measure it on your own tickets.

Neither path replaces evaluation on your labels. The table below contrasts workflow shape and decision contract—not marketing scores.

Stay on the built-in Text Classifier when categories are few and stable, false routes are cheap to undo, everything already runs in n8n, and you mainly need visual multi-branch wiring. Write precise category descriptions, enable Other for ambiguous tickets, and keep auto-fixing on. Log every route with the model id so you can spot drift after a provider upgrade.

A common pattern is: Trigger or webhook → normalize ticket text into state → HTTP Request POST to JevModel’s /api/v1/systemone with Choice questions (2–12 labels) → IF/Switch on the chosen label and any score/probability fields → side effects (Zendesk update, Slack, CRM) only on high-confidence paths → human-review queue otherwise. Keep secrets in n8n credentials. Respect the product budget: validated state is capped (about 8000 characters after validation), 1–8 questions per request, and free verified accounts get a daily successful-run quota. JevModel hosts typesafe/jev-1.13 via OpenRouter; it does not ship model weights into your n8n host.

Treat any model confidence—built-in optional scores or Jev Score/Noul—as something you calibrate on a labeled sample. A practical triage policy: auto-apply safe labels above a high threshold, send mid-band tickets to a human queue with the model’s top labels as suggestions, and force review (or discard) below a floor. Wire the mid and low bands before you connect write actions. For deeper patterns, see confidence-and-abstention and support-triage on this site.

1) Freeze a label dictionary with examples of edge cases. 2) Decide Other vs discard for unmatched items. 3) Pick built-in routing vs shared Jev API based on reuse and abstention needs. 4) Store API keys only in credentials. 5) Measure precision/recall on a holdout of real tickets after every model or prompt change. 6) Gate destructive actions behind thresholds and a human path.