Scripts on a Subscription: The Hidden Cost of AI Agent Skills

For most of my career, automating something started with a small calculation. The task takes 30 seconds. I do it once a week, maybe once a month. Writing a script for it will take an hour. Is it worth it?

Often the honest answer was no. There is even a famous xkcd chart for exactly this question.

The Old Maths of Automation

The hour of writing was never the whole cost. A script, once it exists, is a small piece of software, and somebody owns it.

Who maintains it when I move to another team? What happens when the API it calls changes, or the CLI it wraps gets a new major version, or the folder it expects is renamed? Does it become one more file in a scripts/ directory that nobody dares to delete? Or does it grow, flag by flag, into the one huge script that does everything and that only one person understands?

These questions were the brake. They kept a lot of small tasks manual, and most of the time that was a reasonable engineering decision, not laziness. Thirty seconds a month is six minutes a year. You don’t build and maintain software to save six minutes a year.

Writing Became Free

That calculation is now broken, and in a good way.

An agent writes the script in a minute. When something outside the script changes and it stops working, I paste the error and the agent fixes it. I don’t even need to remember how the script works, because the agent will read it again next time.

So the cost of writing is close to zero, and the cost of maintenance is close to zero. By the old maths, we should now have a script for everything. Every 30-second task, every monthly chore, every “I always forget the right flags for this” command.

But We Write Skills Instead

That is not what happened. We don’t ask the agent for scripts. We ask it for skills.

And by “we write skills” I mean the agent writes them for us. Describe the task once, in plain language, and there is a new skill. It is easy and it is free. Not really free, but it feels free. So we make one for the weekly report, one for the release checklist, one for cleaning up old branches, one for that 30-second task we never automated before. Tens of them. In a bigger organisation, hundreds, and I don’t see what would stop it reaching thousands.

A skill and a script look like the same thing: a saved way of doing a task. They are not the same thing.

A Skill Is a Script on a Subscription

A script costs something once, when it is written. After that, running it is free. It needs an interpreter and whatever it talks to.

A skill is a set of instructions for a model. Every time it runs, a model has to read it, think, and act. Every run is paid for in tokens.

So a skill is a script on a subscription.

If there is no internet, the skill fails. To be fair, most of the old scripts fail too, because most of them call something remote. But the skill has failure modes the script never had:

• The token budget for the month is used up.
• The provider has an outage, or you hit a rate limit in the middle of an incident.
• The price changes, or the plan does.
• The model the skill was written and tested against is retired, and the next one reads the same instructions a little differently.

There is also the quieter problem. A script does the same thing every time. A skill does roughly the same thing every time. For a weekly summary, “roughly” is fine. For rotating credentials or cleaning up resources, I would like something stronger than “roughly”.

It Is Not Only Scripts

The same thing is happening with metrics.

The numbers a team cares about, such as deployments per week, failed pipelines, open pull requests or cost per environment, used to be collected by a job and stored somewhere: a database, a time series, at worst a spreadsheet. Collecting was cheap, and the history built up by itself.

Now it is easier to ask. A skill goes through the API, counts, and answers in a nice paragraph. Next week we ask again, and the agent counts everything again, from the beginning, for the same price. Nothing is stored, so there is no trend to look at, and nothing to compare against when this week’s number looks strange. Was it really 42 last month, or did the agent count differently that time?

A metric you have to buy again every time you look at it is not much of a metric. Collect it once and store it, the way we always did. Let the agent write the collector, and let it read the stored numbers when you ask a question.

None of this shows up when you have five skills. It shows up when the day-to-day work of a team depends on a few hundred of them, and each one is a small recurring bill and a small dependency on somebody else’s service.

Where the Tokens Belong

I am not arguing against skills. I use them every day, and for some work they are the right tool. Reading a failing pipeline and working out what went wrong needs judgement. So does deciding which of forty alerts matters. That is what the model is for, and I am happy to pay for it.

But a lot of what ends up in skills is not judgement. It is a fixed list of steps written in English, which a model then translates back into commands. Every single run.

For those, the cheaper design is to spend the tokens once. Ask the agent to write the script, review it, commit it. The agent is still the author and still the maintainer, so the old objections stay solved. But the run costs nothing and gives the same result each time.

The skill can stay, as a thin layer on top:

---
name: cleanup-branches
description: Delete merged branches older than 30 days. Use when asked to clean up or prune old branches.
---

Run `scripts/cleanup-branches.sh --dry-run` and show the list.
After confirmation, run it again without `--dry-run`.
If the script fails, read the error and propose a fix to the script.

The agent knows when to use it and what to do when it breaks. A human, a cron job or a pipeline can run the same script with no model involved.

One question is enough to sort the skills you already have: would this still work with zero tokens? If the answer is “it should, but it doesn’t”, there is a script hiding inside that skill.

Food for Thought

I don’t have a conclusion, only questions I can’t stop thinking about.

What does a platform with a thousand skills cost per month, and does anyone own that number? When the budget runs out on the 25th, which tasks stop, and who notices first? How many of those skills would survive a model change without anyone retesting them? And if writing scripts is finally free, why did we stop writing them at the exact moment it became free?

These thoughts are heavily inspired by Kelsey Hightower’s PlatformCon 2026 talk, ZTA: Zero Token Architecture. Watch it. He makes the case far better than I can.

If your team is working out where agents and skills fit into your platform, and where they don’t, get in touch.