Coder Legion - Recent posts tagged output

AI Email Classifier Cost per 1,000 Messages: Real Math

Thu, 08 Oct 2026 15:50:00 +0000

For 1,000 typical text emails, the model API can cost roughly $0.05 to $1.08, or about PHP 3 to PHP 66 at a rounded PHP 61.55 per US dollar. That estimate assumes 900 input tokens and 30 output tokens per message, no attachments, no retries, and one classification call per email.

Partner disclosure. This guide includes a partner link to n8n Cloud. If you sign up through it, I may earn a commission at no extra cost to you.

The low token bill is real, but it is not the whole operating cost. Your automation platform, monitoring, human review, and the consequences of a wrong route can cost much more than inference. Prices and exchange rates may change, so keep the formula and replace the rates instead of trusting a static total.

Practical answer: budget about $0.10 to $0.25 per 1,000 ordinary emails for a small classification model, then evaluate accuracy on your own inbox. A model that costs five cents but misroutes valuable leads is not the cheaper option.

The workload behind the estimate

A useful comparison needs the same input and output size for every model. This article uses a typical business email workload rather than each provider's most flattering example.

Component per email	Assumed tokens	What it includes
Classification instructions	250 input	Category names, definitions, edge-case rules, and output instructions
Email content	650 input	Subject, cleaned body, and a small amount of sender context
Classification result	30 output	One label plus compact structured fields such as reason and review flag
Total for 1,000	900,000 input 30,000 output	No attachment extraction, second model call, retry, or human-written reply

Token counts vary by provider and tokenizer. Treat 900 and 30 as planning inputs, then replace them with usage data from the API response or provider dashboard. Long quoted threads, HTML, signatures, disclaimers, and pasted documents can multiply the input without improving the decision.

The cost formula

Provider pages normally quote text prices per one million tokens. The calculation is:

cost = (input_tokens / 1,000,000 × input_rate)
     + (output_tokens / 1,000,000 × output_rate)

Typical 1,000-email workload:
cost = (900,000 / 1,000,000 × input_rate)
     + (30,000 / 1,000,000 × output_rate)

Example for OpenAI GPT-5.4 nano at the rates checked on July 20, 2026:

input  = 0.9 × $0.20 = $0.1800
output = 0.03 × $1.25 = $0.0375
total  = $0.2175, rounded to $0.22 per 1,000 emails

Current model API comparison

These totals use standard synchronous API pricing, without free tiers, batch discounts, cached-input discounts, regional uplifts, or taxes. The selected models are small or cost-focused options that can plausibly handle classification. Model quality is not equivalent, so the last column is a cost comparison, not a ranking.

Rate check: every provider price in this table was checked against the linked official source on July 20, 2026. The PHP estimates use a BSP rate of PHP 61.548 per US dollar checked on the same date. To update any peso estimate, use PHP estimate = USD total × current PHP per USD. For example, $0.2175 × 61.548 = PHP 13.39.

Model	Input / 1M	Output / 1M	Typical 1,000 emails
Groq Llama 3.1 8B Instant	$0.05	$0.08	$0.047 / about PHP 3
Google Gemini 2.5 Flash-Lite	$0.10	$0.40	$0.102 / about PHP 6
OpenAI GPT-5.4 nano	$0.20	$1.25	$0.218 / about PHP 13
Anthropic Claude Haiku 4.5	$1.00	$5.00	$1.05 / about PHP 65
OpenAI GPT-5.6 Luna	$1.00	$6.00	$1.08 / about PHP 66

OpenAI describes GPT-5.4 nano as suitable for classification and other simple high-volume tasks. Its newer GPT-5.6 guidance points cost-sensitive new workloads toward Luna, but Luna costs more in this narrow token calculation. Test both only if the quality gain matters for your categories. Google calls Gemini 2.5 Flash-Lite its smallest and most cost-effective model for at-scale use. Anthropic's current Haiku tier costs more per token, while Groq's Llama 3.1 8B rate is the lowest in this selected set.

Email length changes the bill, but not equally

Output is tiny for a classifier, so input length usually drives the total. This sensitivity table keeps output compact while changing the amount of text sent to the model.

1,000-email workload	Input / output	Gemini 2.5 Flash-Lite	GPT-5.4 nano	Claude Haiku 4.5
Short	400k / 25k	$0.05	$0.11	$0.53
Typical	900k / 30k	$0.10	$0.22	$1.05
Long	2M / 40k	$0.22	$0.45	$2.20

The long scenario is still inexpensive as a token bill. It is also a warning: paying to resend an entire quoted conversation may expose unnecessary customer data and make the classification noisier. Clean the message before the model call.

What the token estimate leaves out

Automation platform cost

n8n Cloud is priced by workflow executions, not by node or step. If one incoming email starts one production workflow, 1,000 emails normally consume 1,000 executions. The model API remains a separate provider charge when you connect your own credential. If you already have unused execution capacity, the incremental platform cost may be zero. If the classifier forces a plan upgrade, the subscription difference can dwarf a 22-cent model bill.

One n8n execution can contain several items, but the Text Classifier documentation says each item is passed to the model. Grouping emails into one scheduled execution can reduce execution usage, while the token charge still follows the number and size of classified items.

Retries and output repair

A failed request, provider retry, or second-pass validation adds another call. n8n's Text Classifier has an Enable Auto-Fixing option that sends a schema parsing error back to the model and asks it to repair the output. That is useful, but it means the estimate above is no longer one call per email when repair is triggered. Measure the repair rate before assuming it is free.

Human review and mistakes

Suppose a reviewer spends 30 seconds on 10% of 1,000 emails. That is 50 minutes of work. Even at a modest internal hourly rate, review costs far more than the API tokens. The review may still be a good investment if it catches invoices routed to sales, urgent complaints marked as routine, or valuable leads sent to the wrong queue.

The correct metric is not only cost per 1,000 messages. Track cost per correctly classified message, manual-review rate, false-negative rate for urgent categories, and the operational cost of each error.

A simple n8n cost-measurement workflow

n8n already has a Text Classifier root node. It accepts an input prompt, category names and descriptions, optional multiple classes, an Other branch for unclear matches, a custom system prompt, and optional auto-fixing. For cost measurement, keep the workflow smaller than a full email router:

Email trigger or scheduled inbox fetch
  → Edit Fields: subject + cleaned body + minimal sender context
  → Text Classifier: named categories and descriptions
     ↳ connected small chat model
  → Log: provider, model, input tokens, output tokens, category
  → Route Other and selected high-risk categories to review

The separate AI email routing guide covers the downstream workflow. This article stays focused on cost measurement and model choice.

Use categories that are testable

Define categories by the action they trigger. For example: sales_lead, support, billing, urgent_complaint, and other_review. Give each category a short description and two or three edge rules. Do not ask the model for a paragraph when one label and a compact reason are enough.

Keep Allow Multiple Classes To Be True off when the business requires one owner. Use the documented Other branch instead of discarding an unclear item. Discarding may look efficient, but it can hide the messages most in need of review.

Log actual usage

Provider response fields differ, so inspect the output from your selected n8n chat-model node or the provider dashboard. Record input tokens, output tokens, model ID, retry count, latency, chosen category, and the reviewer's corrected category. Recalculate weekly:

observed cost per 1,000 =
  total provider cost / classified messages × 1,000

cost per correct classification =
  (provider + platform allocation + review labor) / correct decisions

Reduce cost without weakening the classifier

Use deterministic rules first. Known senders, exact aliases, and clear invoice mailbox rules do not need an LLM.
Remove quoted history. Classify the newest message plus only the minimum thread context required for meaning.
Strip HTML and signatures. Boilerplate consumes input and can introduce misleading terms.
Return a compact schema. A label, short reason, and review flag are enough for routing.
Do not add search or tools. An inbox classifier should not browse the web or call unrelated tools.
Measure auto-fixes and retries. A low base price can double if malformed output repeatedly triggers a second call.
Test a small model first. Upgrade only when a measured accuracy gap is worth the higher rate.

Choose the model by evaluation, not the price table

Start with at least 100 to 200 representative emails that a person has already labeled. Include short replies, forwarded threads, vague subjects, multilingual messages, promotions, complaints, and categories that are easy to confuse. This is an operational starting point, not a universal statistical guarantee.

Test	What to measure	Decision
Overall accuracy	Correct labels divided by all tested messages	Useful for orientation, not enough for rare urgent classes
Per-category recall	How many real messages in a category the model found	Prioritize billing, complaints, security, and other costly misses
Other or review rate	Share of messages that need a person	Convert the review share into minutes and labor cost
Correction stability	Whether prompt or model changes improve the same held-out set	Use a versioned test set before changing production

If two models are close, choose the simpler operational fit: supported credential, stable model ID, acceptable latency, data-processing requirements, and clear usage reporting. A few extra cents per 1,000 emails can be a sensible trade for fewer manual reviews.

Questions small teams usually ask

Can the classifier really cost less than one dollar?

Yes. A classification output is short, and small models have low token rates. The estimate stops being valid when you send long histories, extract attachments, ask for generated replies, use a larger model, or trigger repair and retry calls.

Does n8n include the model tokens?

Do not confuse n8n's AI Assistant credits with the third-party model used inside your production workflow. With your own OpenAI, Gemini, Anthropic, or Groq credential, the model provider meters the API usage. n8n Cloud separately counts workflow executions according to its current plan rules.

Should I use the cheapest model?

Use the cheapest model that passes your labeled evaluation and operational requirements. Price alone cannot tell you whether a model understands your category boundary, language mix, or unusual messages.

Should low-cost classifications send automatic replies?

Classification and outbound sending are separate risk decisions. Route first. If AI also drafts a customer-facing response, use a duplicate-safe human approval gate until measured evidence supports narrower exceptions.

Sources checked

n8n Cloud for small teams

Measure the classifier before you scale it

n8n Cloud is the simplest starting point if you want to connect an inbox, test categories, and log real usage without maintaining a server. Affiliate disclosure: I may earn a commission if you sign up through this link, at no extra cost to you.

<a href="https://n8n.partnerlinks.io/6mg2xng7s1m6" target="_blank" rel="sponsored noopener" class="btn b

Understanding Backpropagation: Calculating Gradients for Hidden Layer Weights and Biases

Tue, 30 Jun 2026 20:23:01 +0000

Hello, I'm Ganesh. I'm building git-lrc, an AI code reviewer that runs on every commit. It is free, unlimited, and source-available on Github. Star git-lrc on GitHub to help more developers discover the project. Do give it a try and share your feedback for improving the product.

In the previous article, we derived formulas for updating the output layer weights w3, w4, and bias b3. Now, we will understand how to calculate the gradients for the hidden layer parameters: w1, b1, w2, and b2.

How are w1, b1, w2, and b2 connected to the prediction?

To find the gradients of the parameters in the hidden layer, we need to trace how changing these values affects the final prediction and the error (SSR).

Let's recall the structure of our neural network:

For the top neuron:

x1 = input * w1 + b1

y1 = f(x1) = log(1 + e^x1) (using the softplus function)

For the bottom neuron:

x2 = input * w2 + b2

y2 = f(x2) = log(1 + e^x2) (using the softplus function)

Finally, the prediction:

Predicted = y1 * w3 + y2 * w4 + b3

And the prediction error:

SSR = Σ (observed − predicted)²

Since w1, b1, w2, and b2 are not directly connected to the output prediction, we must use the chain rule to backpropagate the error from the output layer back to the hidden layer.

Applying the Chain Rule to the Hidden Layer

Let's calculate the gradient for the top neuron's weight w1 first.

A change in w1 affects x1, which affects the output y1, which affects the predicted value, which finally affects the SSR.

So, by the chain rule:

dSSR/dw1 = dSSR/d(predicted) * d(predicted)/dy1 * dy1/dx1 * dx1/dw1

Let's calculate each of these values:

1. dSSR/d(predicted)

As we saw in the previous articles, this is the derivative of SSR with respect to the predicted value:

dSSR/d(predicted) = -2 * (Observed - Predicted)

2. d(predicted)/dy1

Since Predicted = y1 * w3 + y2 * w4 + b3, and all other terms are treated as constants w.r.t y1:

d(predicted)/dy1 = w3

3. dy1/dx1

Since y1 = log(1 + e^x1), the derivative of the softplus function is the logistic sigmoid function:

dy1/dx1 = e^x1 / (1 + e^x1)

4. dx1/dw1

Since x1 = input * w1 + b1, differentiating w.r.t w1 gives:

dx1/dw1 = input

Final formula for dSSR/dw1:

Multiplying these parts together, we get:

dSSR/dw1 = -2 * (Observed - Predicted) * w3 * (e^x1 / (1 + e^x1)) * input

Deriving the Gradient for Bias b1

Similarly, for the top neuron's bias b1:

dSSR/db1 = dSSR/d(predicted) * d(predicted)/dy1 * dy1/dx1 * dx1/db1

The only term that changes here is the last one:

dx1/db1 = 1 (since x1 = input * w1 + b1, derivative w.r.t b1 is 1)

So:

dSSR/db1 = -2 * (Observed - Predicted) * w3 * (e^x1 / (1 + e^x1)) * 1

Deriving the Gradients for the Bottom Neuron (w2 and b2)

Following the same logic, we can find the gradients for the bottom neuron's parameters:

For weight w2:

dSSR/dw2 = dSSR/d(predicted) * d(predicted)/dy2 * dy2/dx2 * dx2/dw2

dSSR/dw2 = -2 * (Observed - Predicted) * w4 * (e^x2 / (1 + e^x2)) * input

For bias b2:

dSSR/db2 = dSSR/d(predicted) * d(predicted)/dy2 * dy2/dx2 * dx2/db2

dSSR/db2 = -2 * (Observed - Predicted) * w4 * (e^x2 / (1 + e^x2)) * 1

Improving Prediction with self Learning

Once we calculate all these derivatives (dSSR/dw1, dSSR/db1, dSSR/dw2, dSSR/db2), we can update the hidden layer weights and biases using gradient descent:

Step size w1 = derivation w1 * Learning rate
New w1 = old w1 - Step size w1

Step size b1 = derivation b1 * Learning rate
New b1 = old b1 - Step size b1

Step size w2 = derivation w2 * Learning rate
New w2 = old w2 - Step size w2

Step size b2 = derivation b2 * Learning rate
New b2 = old b2 - Step size b2

By doing this repeatedly, the model minimizes the error and converges to the optimal values for all weights and biases.

Conclusion

We have successfully derived the formulas to calculate the gradients for w1, b1, w2, and b2. Combined with the output layer derivations, we now have the math for the entire neural network's backpropagation!

In the next article, we will see how to implement this in code.

Any feedback or contributors are welcome! It’s online, source-available, and ready for anyone to use.

⭐ Star git-lrc on GitHub