The Text Classifier node gives each category its own output branch, which makes it a router rather than a labeller. That distinction is what makes it useful and what makes it easy to misuse.
Classification in a workflow usually starts as a chain of IF nodes checking for keywords. It works until the third exception arrives, and by the tenth the branch logic is longer than the rest of the workflow and nobody remembers why one condition checks for a trailing space.
The Text Classifier node replaces that with a model, a list of categories, and one output connector per category. It is genuinely the right tool sometimes. Here is when, and what it does badly.
Table of contents
- How it is wired
- Category descriptions are the prompt
- Multiple classes and the fallback branch
- Cost, latency, and the node freezing
- When an IF node is still the better answer
- Running classification workflows continuously
- How this fits the rest of the stack
- FAQ
How it is wired
The Text Classifier is a root node: it needs a language model connected underneath it, the same way the AI Agent node does. Without one attached, it will not run.
The configuration is three parts:
- Input Text — an expression pointing at the field to classify, typically something like the body of an email or a support message.
- Categories — a name and a description for each. The description is the actual instruction to the model, so it does the real work.
- Options — notably
Allow Multiple Classes To Be Trueand the fallback behaviour for items that match nothing.
Each category becomes its own output on the node. Wire each to its own branch and the routing is structural rather than conditional — there is no IF node reading a label field afterwards.
Category descriptions are the prompt
This is where classifiers succeed or fail, and it is consistently under-invested. A category named Urgent with the description urgent things will classify roughly at random.
Descriptions should state the boundary, not the label. Compare:
- Weak:
Billing— “billing questions” - Strong:
Billing— “Questions about an invoice, a charge, a refund, a payment method, or a subscription plan change. Not questions about what a plan includes, which are Sales.”
The clause that names the neighbouring category is doing most of the work. Classification errors cluster at the boundaries between similar categories, so every description should say what it excludes as well as what it covers.
Keep the category count low. Three to six is a workable range. Beyond that, accuracy drops and the workflow becomes a diagram nobody wants to open.
Multiple classes and the fallback branch
Allow Multiple Classes To Be True lets one item fire several outputs at once. A message that is both a bug report and a billing complaint goes down both branches.
That is correct behaviour and a common source of confusion, because the same item now exists on two branches. If those branches later converge on a node that writes a record, you get two records. Either use a Merge node deliberately, or leave multi-class off unless you need it.
The fallback matters just as much. By default an item matching no category is discarded, which silently loses data. Set the fallback to route unmatched items to an Other output and wire that to something — a queue, a table, a notification. Unmatched items are the best signal you have that your categories are wrong, and throwing them away means never finding out.
Cost, latency, and the node freezing
Every item is a model call. A hundred items is a hundred calls, with the latency and cost that implies. This is the practical difference from an IF node, and it is why classification belongs after cheap filtering, not before it.
Filter first with a plain IF or Filter node — drop automated notifications, out-of-office replies, anything with an obvious deterministic signature — and classify only what survives. It is common to cut the volume reaching the classifier by half this way.
The freezing complaint that turns up in the community is usually rate limiting rather than a bug. The classifier fires one request per item as fast as it can, the provider throttles, and requests hang rather than failing cleanly. Wrap the classifier in a Loop Over Items node with a modest batch size, and set a timeout and retry policy on the model node so a stalled request fails instead of holding the execution open.
When an IF node is still the better answer
A classifier is not a free upgrade. Reach for deterministic logic when:
- The signal is structural — a header, a sender domain, a status field, a webhook event type. Never pay for inference to read a field that already says what it is.
- The decision has compliance or financial consequences. A model that is right 95% of the time is not an approval mechanism.
- Volume is high and margins are thin. Per-item inference costs add up quickly at scale.
- You need reproducibility. Identical input does not guarantee identical output from a model unless you have configured it carefully.
The strongest designs use both: deterministic rules for everything that has a clean signal, a classifier for the genuinely ambiguous remainder, and a human queue for the fallback branch. That gets the accuracy where it matters and keeps the bill proportionate.
Running classification workflows continuously
A classifier is usually attached to something that never stops — an inbox, a webhook, a queue. That means an instance that is always up, holding provider credentials, with logs you can read when accuracy drifts after a provider updates a model.
It also means storage. The useful habit is writing every classification decision to a database — the input, the chosen category, the timestamp — so you can audit accuracy later rather than relying on the impression that it seems fine. That is a managed Postgres or MySQL next to the workflow instance.
On RunxBuild, n8n runs as a managed tool with environment variables and credentials in the dashboard, autoscaling between plans you choose, and a managed database available on the same platform for the decision log.
How this fits the rest of the stack
The Text Classifier is a router that costs a model call per item, which makes it excellent for ambiguous text and wasteful for anything a field already answers. Filter cheaply first, classify the remainder, and log every decision so you can check the accuracy claim later. Running that continuously means an always-on instance plus a database for the log, and the RunxBuild hosting calculator shows both as separate line items before you build around them.
Useful related references:
- n8n AI Agent Node: What It Does and When a Plain Chain Is Better
- n8n + Qdrant: A Vector Search Node for Real Workflows
- n8n HTTP Request Node: The Auth and Error Playbook
- Node services on RunxBuild
FAQ
Do I need a language model connected to the Text Classifier?
Yes. It is a root node and will not run without a model attached underneath it, in the same way the AI Agent node works. The model you choose affects accuracy, latency and per-item cost.
How many categories should I define?
Three to six works well. Accuracy falls as categories multiply, mostly because their boundaries start to overlap. If you need more, consider classifying in two stages — a coarse pass, then a finer one on a single branch.
What happens to items that match no category?
By default they are dropped, which silently loses data. Configure the fallback to send unmatched items to an Other output and wire it to a queue or table. Unmatched items are your best evidence that the category definitions need work.
Why does the Text Classifier node freeze?
Usually provider rate limiting rather than a node fault — requests hang instead of failing. Wrap the classifier in a Loop Over Items node with a small batch size, and set an explicit timeout and retry policy on the model node so stalled calls fail fast.
Can one item match multiple categories?
Yes, with the Allow Multiple Classes To Be True option. Be aware the item then travels down every matching branch, so any node where those branches converge will see it more than once. Use a Merge node deliberately if that matters.