Evolving beyond the AI Vending Machine.

A skill is a set of instructions you write once so a task runs the same way every time. Think of it as a recipe with a name. Where it lives:

• As plain text files in a folder, the same as your memory notes.
• Once created, it's available to every project and every conversation, not just the one you made it in.
• Your assistant app has a settings list where you can see every skill you have.
• It works in both the plain chat window and the more agentic mode.

You create one by describing it in plain English and asking your assistant to make it a skill. It writes and saves the files for you. Then you call it by name, or with a slash command, and it runs. An example from my own job search: one skill scans the sources for new roles, one tailors my CV against a specific description, and one publishes the formatted PDF. Three named steps, one chain, no re-explaining.

What you're hitting is the context window: the assistant's short-term memory, the pool of text it can hold in mind at once. It's finite. Fill it and the session either stops or starts compressing. Two things happen once you outgrow it:

• Compacting. Rather than cutting you off, a good assistant will squash what you've said so far into a summary and keep going. You'll sometimes see it announce this. It buys room, but detail is lost in the squeeze.
• Durable memory. This is the real fix. When your work is grounded in a project, the assistant writes the lasting facts out to files rather than holding them in the conversation. The chat is disposable; the memory is not.

That's the whole reason the Memory layer exists. You stop being hostage to one long chat, because the important things were written down outside it.

Check the privacy settings and switch off training on your conversations if you want your context to stay yours. Do that before you put real work in. What each provider does by default differs, so read their data-usage terms: see Claude's data-training policy.

It only touches what you connect it to, and only the way you allow. Anything outward-facing (a sent message, a published page, a deletion) waits for your review. Grant it read-only where you want it to look but never act.

Worth being precise, because people assume this is just an instruction you give the model and hope it obeys. It's not. When you connect a service you authenticate with that service, and it hands you a permission screen grouped by category: read-only tools, read-and-write tools, write-and-delete tools. I set the destructive and outward-facing categories to require approval, so it has to come back and ask me. Some people automate that away entirely. I don't, because it's still me that the output represents.

Never upload what your employer hasn't cleared, and when in doubt, leave it out. Most of the value is in the structure and the method, not in feeding it sensitive files. If your workplace has an approved enterprise tier, use that for anything work-related.

Also assume the decision may not be entirely yours. On a managed work machine, what's allowed to leave the device is often controlled centrally, which can quietly decide which tool you use for which task. Find that out before you design around it.

I match the model to the job, not to my mood. The line-up I reach for, as of July 2026:

• Sonnet for the mechanical work: routine updates, assembly, summarising something I'll read in thirty seconds. It's what I use most.
• Opus (just released) for anything analytical: rewriting my CV, redesigning a process, anything where the reasoning matters more than the throughput.
• Fable for the rare job I want thought about deeply. It's the most expensive and the most heavily rate-limited, so it's not an everyday choice, and it has a habit of over-thinking and over-formatting.
• Haiku I don't really use, though I may be missing a trick there.

The honest part: I don't run my own benchmarks. There are sites that score models on intelligence, speed and cost per task, and they're interesting, but a one-point difference on an index isn't something I could design a test to expose. So I experiment, pick what works, and move on. One practical consequence: defaults change without warning, so check which model you're on before a big job.

The most capable model is the most expensive, and the spend is in how much you run, not in owning it. Keep the lighter model for routine work, save the top model for the hard jobs, and watch your usage like any budget. For what things cost, see Claude's pricing and the usage-pricing docs.

If you want to see the difference rather than take my word for it, the model comparison sites are the place. They run a fixed set of tasks across every model and report three things: how well it did, how fast it was, and what it cost to finish the task. That last column is the one to watch. The practical read for a subscription, rather than an API bill: if you run everything on the most expensive model, you'll burn through your plan's allowance several times faster than someone doing the same work on a lighter one. Same work, same result, different rate of spend. The top models are also the most rate-limited, so a heavy day tends to hit a ceiling before it hits a bill.

No. None of the layers here are locked behind a top tier. I ran the whole thing on the mid subscription for months and it was fine. What moved me up was one specific habit: I started leaning on the most capable model to rebuild this website, hit its rate limit every few hours, and got annoyed. So: start on what you already pay for, build the first layer, and see if you use it. It's monthly; you can go back down. If you're using it for half an hour a day, the entry paid tier is plenty. For what the tiers and any pay-as-you-go usage actually cost, see Claude's pricing.

It's ongoing, not a one-off setup. At work, something like 25 to 50 percent of my time, on my own rough estimate, has shifted to working through Claude, less on heavy meeting days. In my own time, I spend four to six hours a week iterating on Claude projects. The setup is incremental: you get value from the first layer and grow the rest from real use.

Both, for different reasons. The app is where I do most things: I like reading formatted output rather than plain text, and the visual cue of seeing what I have cooking. The command line is where I build things: more control, more visibility into what it's actually doing, and for anything that touches code it's more reliable than the equivalent mode inside the app. Neither requires you to write code; both are you typing English. One unglamorous factor: on a managed work machine, your employer may control what can be sent out through each, which can decide the split for you regardless of preference.

I built mine on one platform, but the method (a constitution, memory, skills, a delegated team, automation) transfers across tools. Which one fits you, and whether to hedge across several, is exactly the kind of thing worth talking through live.