Which AI Model Should You Use for Which Marketing Job?

Which AI model should you actually use for marketing work?

More than one, chosen per job rather than per subscription. The gap between the cheapest and most capable models is now roughly two hundred times on input price, so running every task on a frontier model is the most expensive habit in most marketing stacks, and running everything on the cheapest one is the second most expensive.

People ask this question expecting a name. The useful answer is a method, because the names change every few weeks and the reasoning does not.

Here is what the three big vendors currently charge, which jobs belong where, and how to decide without guessing. All prices below are what Anthropic, OpenAI and Google published on their own pricing pages in September 2026, and all of them move, so check before you budget.

Why is price, and not capability, the thing that decides this?

Because capability is roughly sufficient across the board for most marketing tasks, and cost is not. Summarizing a call, drafting a meta description, tagging a lead, cleaning a spreadsheet: none of these are hard problems for a current model. What separates them is how many times a month you do it and what each run costs.

The trap is that the per-run cost of anything feels negligible when you test it once. You run a prompt, it costs a fraction of a cent, and the whole discipline of matching jobs to models feels like premature optimization. Then you automate it, it runs thousands of times, and the bill arrives with a shape nobody predicted.

So the honest framing is not which model is best. It is which is the cheapest model that clears the bar for this specific job, where the bar is defined by what happens when the output is wrong. That single reframing does more for a budget than any prompt engineering.

What do the frontier models cost right now?

They cluster. Anthropic prices Claude Fable 5.1 at 10 dollars per million input tokens and 50 dollars per million output tokens. OpenAI prices gpt-6-astra at exactly the same headline numbers on its standard tier: 10 dollars input, 50 dollars output, with cached input at 1 dollar per million.

Google sits differently. Its Gemini 3.1 Pro Preview is listed at 2 dollars per million input and 12 dollars per million output for prompts up to 200,000 tokens, rising to 4 dollars and 18 dollars above that threshold. That is a materially different price point for a model positioned near the top of its range.

Caching is where the frontier tiers separate more than the headline. Anthropic prices Fable 5.1 cache reads at 25 cents per million tokens. OpenAI prices cached input for gpt-6-astra at 1 dollar per million. If your workload sends the same long context repeatedly, which most content workflows do, that difference compounds far faster than the input price does. I unpacked what that changes in my piece on the Claude Fable 5.1 release.

What do the cheap models cost, and what are they actually for?

They are close to free at marketing volumes, and that is the point. OpenAI lists gpt-5-nano at 5 cents per million input tokens and 40 cents per million output. Google lists Gemini 2.5 Flash-Lite at 10 cents per million input and 40 cents per million output for text, image and video.

The middle tier is where a lot of real work should sit. OpenAI's gpt-5.4-mini is listed at 75 cents per million input and 4 dollars 50 per million output. Google's Gemini 3.8 Flash is listed at 75 cents input and 3 dollars 75 output on the paid tier through 31 December 2026, rising to 1 dollar 50 and 7 dollars 50 from 1 January 2027, which is a price change worth putting in a calendar rather than discovering.

Read those numbers against the frontier tier and the shape of the decision becomes obvious. A job that costs 50 dollars per million output tokens on a frontier model costs 40 cents on a nano model. That is not a rounding difference. If you have never converted a workflow into a token count, start with my explainer on what a token is and how it becomes a bill. That is the difference between an automation you can afford to run continuously and one you run once a quarter and feel guilty about.

Which jobs belong on a cheap model?

Anything where the output is checked by something else before it matters. Classification, extraction, routing, tagging, deduplication, converting messy text into structured fields. These are jobs with a right answer, which means you can validate them mechanically, which means a cheaper model failing occasionally is a detectable and cheap event.

High-volume, low-stakes generation also belongs here. Internal summaries. First-pass alt text. Draft subject lines that a human will pick from. The pattern is that a human or a rule sits downstream and the cost of a mediocre output is a few seconds of somebody's attention rather than a customer seeing something wrong.

The mistake I see most often is teams putting their highest-volume job on their most expensive model because that job felt important when they built it. Volume and stakes are different axes. A job can run ten thousand times a month and still be low stakes, and that combination is exactly what cheap models exist for.

Which jobs actually justify a frontier model?

Three kinds. Anything customer-facing that ships without a human reading it. Anything requiring genuine reasoning across a long document rather than pattern matching. And anything agentic, meaning the model plans, acts, reads the result, and decides what to do next over many steps.

That third category is the one that has changed most. In a multi-step run, an error at step two does not stay at step two, it propagates and gets elaborated on by every subsequent step. A cheaper model that is nearly always right on a single step is not nearly always right across a ten-step workflow, because the per-step error rate compounds, and that arithmetic is unforgiving enough that paying frontier prices is simply correct.

The fourth case, which people forget, is anything with legal or reputational exposure. Pricing claims, competitor comparisons, regulated-industry copy, anything with a number in it. Not because a frontier model cannot be wrong, but because the cost of being wrong is not measured in tokens.

How do you decide without guessing?

Build an evaluation set before you pick anything. Take twenty real examples of the job from your actual work, write down what a good output looks like for each, then run all your candidate models against the same twenty and read the results side by side. It is unglamorous and it takes an afternoon, and it replaces an argument with an answer.

Start from the cheapest model and move up only when the eval set shows you have to. That direction matters. Starting at the top and trying to move down never happens, because nobody wants to be the person who made the output worse to save money, and the eval set is what makes that conversation objective instead of personal.

Then write the decision down next to the workflow, with the date and the reason. Six months later, when a new model ships and somebody asks whether you should switch, that note is the difference between rerunning a test and relitigating a debate. I described the routing side of this in more detail in my notes on routing work between models to control content costs.

What about lock-in, and does using several vendors make it worse?

Using several vendors reduces lock-in rather than increasing it, provided you keep your prompts and your evaluation set outside any one vendor's tooling. The thing that traps teams is not the model, it is building your workflow logic inside a single provider's proprietary features and then discovering the price changed.

Practical portability means three things. Keep prompts in version control, not in a vendor's console. Keep the evaluation set in a plain format you own. And keep the model name in a configuration value rather than hard-coded in twelve places, so that switching is an edit rather than a project.

Anthropic, for instance, lists Fable 5.1 as available through Claude.ai, the Claude API, Claude Code, Claude Enterprise, Amazon Web Services, Google Cloud and Microsoft Azure, which means even a single-vendor choice can have multiple routes. Across 70 plus projects for 25 plus clients over 6 plus years, the migrations that hurt were never about the model. They were about workflow logic that had grown into a place it could not be lifted out of.

What should you do next?

List every job in your stack that calls a model, and put two numbers next to each: how many times it runs a month, and what happens if the output is wrong. That table is the entire decision. Anything high-volume and low-consequence moves down a tier this week. Anything customer-facing and unreviewed stays where it is or moves up.

Then price the top three by volume against the numbers above and see whether your current allocation makes any sense. In most stacks I look at, it does not, and the fix is a configuration change rather than a rebuild. Also put the January 2027 Gemini Flash price change in your calendar now, because that one is published in advance and there is no excuse for being surprised by it.

I do this kind of audit for founders and marketing teams on fixed fees, with most projects landing between 1,000 and 10,000 dollars. If your AI bill has grown faster than your output and you are not sure which job is responsible, reach out and let's chat.