When the Tool You Built On Fails You

I started this article in Claude because I couldn't move the work forward in ChatGPT. That wasn't the plan. After months of building a writing and publishing process around ChatGPT, I was using another tool to explain why the first one had become so hard to work with.

I started this as a story about a platform having a bad week. That is too small a frame. The harder question is what happens when a tool you depend on becomes unreliable—and whether you can keep working with it without giving it more trust than it has earned.

The Sunday I lost

Sunday night is when I do most of my week's work. It's when I schedule articles and posts, and when I get time for the projects that never fit into a normal day, like developing and launching new skills. Losing that time means carrying the unfinished work into a week that already has other things in it.

Over one Sunday and Monday, work I thought was automated or accessible wasn't. A scheduled LinkedIn post didn't appear, and the task history showed no run. Around the same time, I couldn't reach chats and images as expected through my Big Bucks Football project. I created a new chat, but I had to find it through Recents instead of the project folder, and I still had trouble working with its images.

One apparent disappearance turned out to have an explanation: the main chat had been pinned outside the usual project view. The project and its local files were intact. That was a relief. It didn't resolve the newer chat and image problems, but it did mean I needed to be careful about calling the work lost.

For about a week, I'd been rebooting, resetting and clearing caches to keep things moving. We were also mapping my systems to understand where they had become too heavy. I wondered whether we were doing too much, whether the platform was changing underneath us, or whether something else was wrong. I can't prove those events had one cause. What I could see was that work I expected to be there, or to have happened, wasn't dependable.

The failure that didn't look like one

The missed run wasn't what bothered me most. It was the article that looked finished and wasn't.

I used “Run now” on an AI BYTS article, expecting to publish a piece that had already passed through the voice and editorial process. It went directly to the website. When I read the live page, it sounded like content instructions. The interest and personality we'd spent so much time developing weren't there.

I had trusted the safeguards enough to check after instead of before. We'd worked through this problem many times. We'd created voices for the different publications because I didn't want everything coming out sounding like generic AI copy. I thought we'd reached a place where I could rely on that work.

I still can't tell which steps that action ran or why the expected safeguards didn't stop the article. I know what I read on the site. And I know I was back to moving dates around so I could make time to review the work myself.

That is what changes the relationship. A rough answer in a chat is easy to catch. An unattended workflow can make failure look like success: something has been published, but I can't rely on it having received the treatment I expected. The problem is the gap between what I think the system did and what I can verify it did. When the result goes out under my name, I carry that gap.

The part that stings

For a week or two, my skills and automations ran well enough that I thought I had reached the system I was building toward. The skills held, the automation held, and I could finally see how the pieces would work together. That experience is part of why it's difficult to walk away. I've seen this work.

I was willing to try Astra early because it had been so consistent for me. For a while, it felt like I'd found something that worked especially well for me. I used all three reset tokens trying to build the system that now feels at risk if the platform has another bad stretch.

The subscription question adds pressure. I had misread the emails, and I'm glad we checked. My bill was still $200 a month for Pro 200. The notice described a reduction in included Work and Codex usage starting October 30, at the same price. The credit grant and Sites hosting notice were separate; they weren't a promise of unlimited usage. I had that wrong. OpenAI's Pro tier details (opens in a new tab)

I haven't turned this work into a profit yet, and I'm not ready to pay $500 a month for Pro 500. Correcting my reading of the emails matters. So does the time I've spent trying to get back to a level of reliability I'd already experienced. A subscription is one cost. Losing the time set aside for the work, then finding something unsuitable published under my name, is another.

What I can carry with me

This doesn't mean every part of the system is trapped here. My voice rules, editorial standards and core files are written material I can keep in Google Drive. Those are the decisions I've worked through and the standards I want the work to meet. They still have value if another tool is running them.

Other AI tools support skills too, though their packaging and execution aren't guaranteed to match. Scheduling, project history, images, credentials and publishing connections are harder to move. Until I try carrying a real workflow across, I won't know how much of the system is portable and how much needs rebuilding. ChatGPT Skills (opens in a new tab) · Claude Skills (opens in a new tab)

So the next move is smaller than a wholesale migration. Keep the essential rules and files somewhere I control. Test one workflow somewhere else and see what transfers, what needs rebuilding, and whether the work is easier to verify. Slow down long enough to make the system easier to work with. I don't need another mountain of logs to solve a problem created by too much complexity.

For public work, I want a compact record of which piece was reviewed and what the reviewer actually checked. If that record is missing, the article waits. A record can still contain a weak judgment, so a PASS by itself won't settle the question. The article has to be worth putting my name on.

Back where I started

I don't have to decide today that ChatGPT is indispensable or unusable. But if an unattended system can't show that it completed the steps protecting work under my name, it shouldn't publish. And if the platform can't reliably preserve access to the work and context I need, the relationship may no longer be worth its cost—however much I've already built here.

That's why the good stretch matters as much as the bad one. I know why I kept building. I also know why I'm questioning it now. Correcting a mistaken assumption doesn't make the lost time disappear, and remembering how well it worked doesn't tell me what will happen next Sunday.

I was trying to make the tool reliable enough to hold my system. The next version has to make the system portable enough to survive the tool. That feels like coming back to the beginning. It’s also where this article ends.