Does Splitting Work Across AI Tools Really Save Money? Put the Monthly Gap and the Switching Cost in One Table

Last month I sat looking at a billing screen, wondering if moving just one task to a cheaper tool would cut the bill in half. Polishing store descriptions, reading logs, getting code reviewed — all three were going to the same place. As an indie developer who has run wallpaper apps for years, I revisit store descriptions in many languages almost every month. Each pass is small, but the total shows up on the bill.

The short answer first. Splitting only pays off for tasks where the monthly gap beats the effort of switching. If you look at unit prices alone, you will misjudge most of them.

This article gives you a small script that lays the monthly cost and the effort for each task in one table. It is not a ranking of tools. You put in your own prices.

Why unit prices alone mislead

At first I looked only at the "per million tokens" line on a pricing page and moved everything toward the cheaper side. It did not go well.

There are two reasons:

• Even for the same task, a different tool changes how you prepare input and tidy output, and a few minutes pile up on every run
• A task you run only a few times a month has a gap too small to cover the setup of changing tools

What you should compare is not the unit price. It is the gap after multiplying by your monthly volume, plus your own time.

Four numbers per task

You do not need precise measurement. Scroll through recent chat history and a rough order of magnitude is enough.

The script also takes per-tool prices (input and output), the minutes one switch costs you, and what an hour of your time is worth. If you are on a quota or flat-fee plan, read "price" as the money-equivalent of the quota one run consumes. The billing unit differs, but the logic does not.

The break-even script

What it solves: for each task, it prints the cheapest tool and whether switching is worth it.

import csv, json, sys
 
# prices.json: {"tool_a": {"in": 3.0, "out": 15.0}, ...}  (USD per 1M tokens)
prices = json.load(open(sys.argv[1]))
rows = list(csv.DictReader(open(sys.argv[2], encoding="utf-8")))
overhead_min = float(sys.argv[3])   # 道具を切り替える1回あたりの手間（分）
hourly = float(sys.argv[4])         # 自分の1時間の価値（USD）
 
def run_cost(tool, tin, tout):
    p = prices[tool]
    return (tin * p["in"] + tout * p["out"]) / 1_000_000
 
total = {t: 0.0 for t in prices}
for r in rows:
    n, tin, tout = int(r["runs"]), int(r["in_tokens"]), int(r["out_tokens"])
    costs = {t: run_cost(t, tin, tout) * n for t in prices}
    best = min(costs, key=costs.get)
    base = costs[r["current"]]
    saving = base - costs[best]
    switch_cost = n * overhead_min / 60 * hourly if best != r["current"] else 0
    verdict = "切り替える" if saving > switch_cost else "今のまま"
    print(f'{r["task"]:<14} 今={r["current"]} 最安={best} 月の差額={saving:6.2f} 手間換算={switch_cost:6.2f} -> {verdict}')
    for t in prices:
        total[t] += costs[t]
print("全部を1本に寄せた場合の月額:", {t: round(v, 2) for t, v in total.items()})

Why it is written this way: I narrowed the decision to two quantities. Compare the monthly gap with the converted effort, and let the larger one decide. Adding a task means adding a row, and I find it easier to rerun with different assumptions than a spreadsheet.

Running it (the numbers are dummies)

Prepare a price file and a task table. The numbers below are dummy values for illustration, not real prices.

{"tool_a": {"in": 3.0, "out": 15.0}, "tool_b": {"in": 1.25, "out": 10.0}}

task,current,runs,in_tokens,out_tokens
日本語の校正,tool_a,60,6000,1500
コードレビュー,tool_a,40,30000,3000
ログ整理,tool_a,80,12000,800

Assume 1.5 minutes per switch and 20 dollars for an hour of your time.

python3 split_cost.py prices.json tasks.csv 1.5 20

On my machine, it printed the following. The labels are in Japanese because I keep my task names in Japanese: "最安" is cheapest, "月の差額" is the monthly gap, "手間換算" is the converted effort, and "今のまま" means keep the current tool.

日本語の校正   今=tool_a 最安=tool_b 月の差額=  1.08 手間換算= 30.00 -> 今のまま
コードレビュー 今=tool_a 最安=tool_b 月の差額=  2.70 手間換算= 20.00 -> 今のまま
ログ整理       今=tool_a 最安=tool_b 月の差額=  2.00 手間換算= 40.00 -> 今のまま
全部を1本に寄せた場合の月額: {'tool_a': 11.67, 'tool_b': 5.89}

Look only at the last line and it seems to nearly halve. Per task, though, the effort exceeds the gap in all three. In this example, splitting loses money.

How to read the result

After the output, I think in this order:

1. If the converted effort exceeds the gap, stay with the current tool
2. If some task has a gap larger than the effort, try switching only that one
3. If putting everything on a single tool lowers the monthly total, consider consolidating rather than splitting

In the example, as the last line shows, consolidating can beat splitting, because you never pay the switching effort. That was the biggest takeaway for me.

One more thing: be honest with the effort number. Write 0.2 minutes instead of 1.5 and every task says "switch". A conclusion reached with a bent number will not be rewarded by next month's invoice.

How it played out for me

Proofreading store text is a task I run often but with short input per run. The gap was small and the effort won. Reading whole logs is the opposite: large input, a gap that grows. Even so, while each switch took a few minutes of setup, staying put was cheaper.

What I ended up choosing was not splitting at all. I kept one tool and trimmed the input before sending it. Only after building the table did I realize that what I should reduce was the amount of input, not the unit price.

Where people get stuck

• Estimating input size: pasting a long log makes input dominate; polishing a short text makes output dominate. That is why "in" and "out" are separate
• Free tiers and flat plans: inside the free range the gap is zero. Set the price to 0 and decide on effort alone
• Quality differences: this script only sees cost. If output quality differs, try the same input once on each tool before switching, and add the rework time to the effort figure

Next action

Start by writing down three recent tasks with the four fields above. Fill in prices from each vendor's pricing page. I began by replacing the dummy values with my own.

Put a number on the effort before you split. I keep this one step in place before every switch.