A serious user delegates tasks. A power user designs and delegates workflows. The difference isn’t more prompts or a bigger token bill. It’s a loop: capture work once, route it to the right model (often a local one on your Mac), execute with limits, and don’t call anything done without proof.
What this isn’t. Not a benchmark. Where I describe how a product behaves, I cite the vendor’s docs. Where I describe how I work, that’s what I do. Where I generalise about “power users”, that’s opinion, and I’ll say so. Nobody publishes a user-percentile distribution, and I’m not going to invent one.
Using AI every day doesn’t make you a power user
Most people who use these tools daily are serious users. Good prompts, the right model for the job, real tasks handed over. But every task starts from zero. The context is in your head, the checking is by eye, and next week the same job gets prompted again from scratch.
The power-user shift is from “help me do this” to “run this workflow and prove it worked”. The unit of work stops being a conversation and becomes a queue item with an owner, a definition of done, a route to a model, and a piece of evidence that closes it.
You can’t read that off a usage meter. Token consumption swings with the model tier, the reasoning effort, the context length and the tools attached. OpenAI’s own Codex docs list four tiers, from Sol for the hardest work down to Luna for cheap repeatable tasks, plus a reasoning dial from light to max. Two people doing the same job can differ by an order of magnitude. My own account showed 35% of a weekly allowance used at one point this week, and since I didn’t snapshot the start of the window, that number tells you nothing about any one session. Someone once guessed this kind of multi-system use sits “in the top few percent” of users. It’s a guess. Treat it as one.
The loop
Every workflow I run passes through the same six stations. Work travels the ring, the only green is at Verify, and a human gate sits in front of Execute.
- Capture. Issues, messages, alerts and ideas go into one ranked queue. Two queues is none.
- Scope. Before any model is asked anything: the outcome, the risk, who has authority, how it rolls back, what “done” means.
- Route. Deep reasoning for architecture and consequential changes. Fast or local models for search, triage, formatting and checks. On a Mac with enough unified memory, local is a real tier, not a fallback.
- Execute. Let the agent inspect, change, test and iterate, within limits. Production writes, publishing, external messages, purchases and deletion wait for a person.
- Verify. Check deployed truth, not agent confidence. The model saying “done” is a claim. A passing probe is evidence.
- Reuse. Keep what worked as a runbook, a skill or an automation, so the next pass costs less.
Notice there’s no station called “prompt”. Prompting happens inside Route and Execute and it’s the least reusable part. The stations that compound are Scope, Verify and Reuse, which are exactly the ones that feel like overhead.
The stack, in seven layers
Tools matter less than layers, because each layer answers a different question. Swap the names for your own; keep the layers.
| Layer | What I use | The question it answers |
|---|---|---|
| System of record | Linear GitHub project docs | What’s the priority, the state, the decision, the evidence? |
| Deep reasoning | Codex Sol Claude ChatGPT | Architecture, diagnosis, risky changes, final review. |
| Fast execution | Codex Luna / Spark local Qwen / Muse on the Mac | Search, triage, formatting, narrow edits, routine checks. |
| Execution tools | shell Git SSH WP-CLI browser | What actually changes the system and leaves an artifact? |
| Connections | MCP APIs purpose-built CLIs | How does a model reach an app or a dataset, and no further? |
| Evidence | tests diffs logs screenshots probes | Plausible answer, or verified outcome? |
| Reuse & automation | skills runbooks cron Hermes | How does attended success become controlled automation? |
Three of those layers only work because of how the products behave. The Model Context Protocol spec is explicit that hosts must get user consent before invoking any tool and should treat tool descriptions from untrusted servers as untrusted; that’s what makes “bounded access” real rather than hopeful. Anthropic’s skills are directories with a SKILL.md that load progressively, so a repeated workflow costs nothing until it’s needed. And Hermes Agent documents built-in cron, messaging gateways and “any endpoint” as a model provider, which is what lets a scheduled job run against a model served from the Mac Studio on my desk instead of a metered API. That’s the link to this site: automation is where local models earn their keep, because scheduled, high-volume, low-stakes work is the work you don’t want to pay per token for. My field report on three models running one Hermes job shows how that goes, including the run that failed.
One complete example: launching a WordPress domain
Launching a site on a new domain touches DNS, TLS, WordPress URLs, a deployment, a rollback and acceptance checks. A serious user does it in an afternoon of prompting. A power user runs it as a loop.
- 1 · QueueThe approved launch is a Linear issue with the domain, the owner and the go/no-go criteria.
- 2 · PlanA deep model maps DNS, URLs, TLS, deployment, rollback and acceptance checks before anything is touched.
- 3 · ChangeGit, a deploy script that snapshots first, WP-CLI, the Cloudflare API. Every change leaves an artifact.
- 4 · ProveResolve DNS from outside, read the certificate, walk the routes, submit a form, check it on a phone, log in.
- 5 · PreserveCommit the evidence, close the issue, improve the launch skill.
Step four is the whole difference. A model that just ran wp option update home will tell you it worked. The only way to know is to ask the internet. And notice the routing: planning deserves a deep model, but the probes in step four are small, repeatable checks a local model on the Mac can run every hour for free.
The usual failure: great tools, no queue
The failure I see most, including in my own past, isn’t missing tools. It’s a full stack sitting on top of no queue. Work arrives in chat, gets prompted immediately, and is “done” when the conversation ends. Nothing is preserved, so next week costs the same as this week. The fix is unglamorous: one ranked queue, one owner per item. Three rules keep it honest.
One build, one background task
A third stream is where verification quietly stops happening.
Artifact + verification + evidence + next owner
Missing any of the four? Back on the queue. “The agent said it passed” isn’t the second one.
Humans hold the gate
Production writes, publishing, external messages, purchases, deletion and scope changes get a person’s yes.
Prompt, runbook, skill, automation
- Prompt
- Runbook
- Skill
- Automation
Nothing gets automated the first time. Do it by hand and watch every step. The second time, write down the steps, the checks and the rollback. Once that runbook has survived a few real runs, make it a skill: the instructions, a script for the boring parts, the reference material the model would otherwise rediscover. Only work with a stable definition of done, a reliable probe and no production write in its path graduates to a schedule. That’s where Hermes and a local model take over, and where you stop being in the loop for every run. Never for the gate.
Start tomorrow
Five moves
- One ranked queue, one owner per item. Close the other inboxes.
- Write outcome, risk, rollback and “done” into the item before the first prompt.
- Make “local on the Mac” a tier for search, triage, formatting and checks.
- Name the actions only a human may approve, and configure the agent to stop there.
- Record one piece of outside evidence before closing anything. The second time you do a job, write the runbook.
None of this needs a bigger allowance. Most of it shrinks one, because the volume work moves to the machine on your desk and the expensive model only gets the questions that deserve it.
Sources: OpenAI, Codex docs — Models · MCP specification (2026-07-28) · Anthropic, Agent Skills · Nous Research, Hermes Agent docs · WP-CLI · Cloudflare API. The percentile remark is a private estimate, not a measurement; the 35% figure is an unbracketed snapshot and isn’t attributed to any session.