Ads Agents

GPT-5.6 pricing just changed your AI agent economics

Terminal window with model routing rules for AI ad agents across GPT-5.6's three pricing tiers

OpenAI split GPT-5.6 into three models, and it matters for your ad stack

When OpenAI shipped GPT-5.6, they didn't ship one model. They shipped three tiers, unofficially referred to across the community as Sol, Terra and Luna, each with different pricing and different jobs. Simon Willison covered the release, and Latent Space broke down the launch positioning. If you run advertising automation with LLMs in the loop, this is not a headline you skim past. It's a line-item change to your cost model.

We run a lot of agentic work through Claude and MCP against Google Ads, BigQuery and GTM, so we think in terms of cost-per-task, not cost-per-token in the abstract. The three-tier structure is the same shape most model families are converging on: a cheap high-volume model, a balanced workhorse, and an expensive reasoning model. What changes with each release is where the price breaks fall, and that's exactly what decides which model you point at which part of your pipeline.

The three tiers, and what each one is actually for

Think of the tiers by job rather than by name.

The light tier (Luna-class): cheapest, fastest, weakest reasoning. This is your high-frequency, low-stakes worker. Classifying search terms into themes. Tagging ad creative by angle. Deciding whether an inbound lead form is spam. Summarizing a single campaign's daily numbers. You will call this thousands of times a day, so a few cents of difference per thousand calls compounds fast.

The mid tier (Terra-class): balanced cost and capability. This is the workhorse for most drafting and structured analysis. Writing ad copy variants. Drafting RSA headlines against a brief. Producing a plain-language readout of a weekly performance pull from BigQuery. Good enough reasoning to be trusted with judgment, cheap enough to run at scale.

The heavy tier (Sol-class): most expensive, strongest reasoning. Reserve this for decisions with real money attached. Budget reallocation recommendations across campaigns. Diagnosing why a conversion rate collapsed after a landing page change. Multi-step planning where a wrong turn early poisons everything downstream. You call this rarely, and you pay for it deliberately.

The most common mistake is teams standardizing on one model for everything. They either burn budget running the heavy model on trivial classification, or they starve a genuine reasoning task by feeding it to the cheap model and then wonder why the recommendations are shallow.

Cost-per-campaign, not cost-per-token

Token pricing is meaningless until you attach it to a workflow. Here's how we actually estimate it. Take a single mid-sized search campaign and list every LLM touchpoint in a week:

  • Search term classification: high volume, hundreds of calls. Light tier.
  • Creative tagging and analysis: moderate volume. Light or mid tier.
  • Ad copy drafting and iteration: moderate volume, needs quality. Mid tier.
  • Weekly performance narrative: a handful of calls. Mid tier.
  • Budget and bid strategy recommendation: one or two calls, high stakes. Heavy tier.

When you route each touchpoint to the cheapest tier that can do the job well, the weekly cost per campaign is dominated by volume, not by the expensive model. The heavy-tier calls are rare, so even at a premium price they're a small share of the bill. The light-tier calls are frequent, so shaving their per-call cost is where the real savings live.

That's the whole game with tiered pricing. Your total cost is roughly: (huge number of cheap calls × cheap price) + (a few expensive calls × expensive price). Get the routing wrong and you flip that, running expensive calls at high volume, and your cost-per-campaign can multiply several times over for no gain in output quality.

How we think about routing inside an agent stack

We run MCP connecting Claude to Google Ads, BigQuery and GTM for campaign analysis. That setup makes the routing question concrete, because you can see which step touches which data source and how often it fires.

Data retrieval and shaping doesn't need a smart model at all, it needs the connectors. Pull the numbers from BigQuery, pull the campaign structure from Google Ads, confirm event definitions against GTM. The model's job starts after the data is on the table. So the pattern we lean toward is: cheap tier for the wide, repetitive interpretation work, and reserve the reasoning tier for the moment where the agent has to make a call that a human would otherwise sign off on.

A practical rule we use: if the output of a step gets reviewed by a human before anything happens, a mid or light tier is usually fine, because the human is the safety net. If the output of a step triggers an action automatically, or feeds directly into a spend decision, that's where you pay for the heavy tier. Match the model cost to the blast radius of a mistake.

Where a new pricing tier actually changes your decisions

Every time a family like GPT-5.6 reprices its tiers, three things can shift.

First, a task you were doing on the mid tier might now be cheap enough on the light tier, if the light tier got better. Re-test your classification and tagging steps against the new cheap model before assuming you still need the workhorse.

Second, a reasoning task you avoided automating because the heavy tier was too expensive might now be viable. If budget-reallocation logic drops into an affordable range, it moves from "human does this weekly in a spreadsheet" to "agent drafts it and human approves."

Third, the balance point between tiers moves. The whole reason to maintain a routing layer, rather than hardcoding one model, is that these break points shift with every release. Build your stack so that swapping the model behind a task is a config change, not a rewrite.

Don't optimize the model before you optimize the workflow

The biggest cost lever isn't picking Luna over Terra. It's not calling the model at all when you don't need to. Cache repeated classifications. Batch daily summaries instead of streaming them per row. Filter obvious spam with a rule before you ever hand it to a model. Deduplicate search terms before classification. Every call you remove is cheaper than any tier.

// from our practice We've found the same thing on our own instrumentation work. When we relaunched our site, we built a full GTM to GA4 to BigQuery pipeline where every blog view and form event is verified in BigQuery. That verification layer matters here too: if you're going to let agents make spend recommendations off your analytics, you need to trust that the events feeding them are real and correctly defined.

A cheap model reasoning over clean, verified data beats an expensive model reasoning over garbage events every time. The model tier is the last decision, not the first.

The short version

GPT-5.6's split into light, mid and heavy tiers is a reminder to route by job, not by habit. Send high-volume interpretation to the cheap tier, drafting and structured analysis to the workhorse, and money decisions to the reasoning tier. Compute cost per campaign across all your LLM touchpoints, not per token in isolation. And re-test your routing every time a family reprices, because the break points move.

If you want help designing an agent stack that routes models sensibly and sits on analytics you can actually trust, that's the work we do. We connect Claude to Google Ads, BigQuery and GTM through MCP and build the verified data pipeline underneath it. Talk to Bitegrico about your MCP and analytics implementation, and we'll help you size it before you spend on it.

Andrii Krutko
Andrii Krutko
Founder & CEO, Bitegrico

Founder of Bitegrico. 8+ years building marketing analytics and AI-driven workflows for SMBs across e-commerce, fintech, and SaaS — GA4/BigQuery pipelines, GTM architectures, and AI agents that run real production marketing ops.

LinkedIn →

Want this working in your stack?

Free 30-minute analytics audit — we'll look at your GA4/GTM setup and show you exactly what to fix.

Book the audit