Last Week
Last week, a network problem with my self-hosted runners interrupted development. This week, I ran into another dependency that could stop me from getting work done: access to the AI tools I now use throughout my workflow.
It was a short week. I did not get home until roughly halfway through it, and most of the progress was on marketing and the product launch rather than new app features.
Shokken is available in the US on Android and iOS. I am preparing a much lower introductory price, limited both in time and in the number of users who can receive it. I expect that to arrive within the next week or so. In the meantime, get in touch if you want to use the app at the new pricing, and I can arrange a license manually.
The app store listings and website are also due for an overhaul. I am continuing the Thursday tutorial videos on the Shokken channel, showing how the app works and what the guest experience looks like. Those are all parts of the launch effort.
The Jobs I Forgot to Bound
While I was traveling, I used Codex remotely to run jobs on my computer at home. These were mostly unattended discovery, repair, and maintenance tasks.
I made a mistake: I did not give the jobs a stopping rule.
A task might try a fix, find that it does not work, try again, and keep going. Sometimes it needs a person to intervene, offer a different approach, or ask it to research the problem before making another attempt. Letting it continue does not guarantee that it is making progress.
I could have said, for example, to stop after five unsuccessful rounds. I did not. The jobs kept running throughout the day, and by the time I checked, they had exhausted my weekly allowance.
That made my dependence on these tools very obvious. I could still find the error message from a failed build or test job. But researching the cause and implementing the fix manually would take much more time than the workflow I had become used to.
I now rely on AI assistance to be effective at the pace I want to work. Losing access exposed how little preparation I had made for that situation.
Dependence Is Something to Manage
I do not think depending on a useful tool is automatically a problem.
Even something as ordinary as writing with a pencil depends on other people: someone supplies the materials, someone makes the pencil, and someone gets it to me. I do not need to perform every step myself to use the result.
Programming already works through layers of abstraction. I can build an application in a high-level language without writing every processor instruction myself. I see AI as another layer: I can describe what I want in ordinary language and work with an agent to produce the code.
That still takes expertise. My experience of building and maintaining an app involves a lot more judgment and intervention than handing over one long prompt. I still need to recognize when the tool is stuck, understand the work, and guide it.
The dependency I need to manage is having so much of that workflow tied to one provider. If I run out of usage, cannot get the plan I need, or find that the pricing no longer works for me, I need another way to continue.
Switching Models Is Only Part of the Work
I used Claude before Codex, so returning to Claude Code is an obvious possibility. But a coding workflow includes more than access to a model.
There is also the surrounding application, often called the harness. It handles the conversation, the repository, the tools the agent can use, and the configuration that makes everything work together.
Switching harnesses means checking my instructions, repository setup, tool connections, and authentication again. Some instructions can be shared, but I still need to make sure the whole workflow works in the other application. Having another subscription would not, by itself, give me a ready replacement.
The alternative that interests me is using a harness that can connect to multiple providers. That is why I tried OpenCode before, and why I want to revisit it now.
I liked the idea. The difficulty was that my earlier setup kept losing details I needed it to remember.
What Happens When the Conversation Gets Too Long?
An agent has a limited amount of conversation it can work with at once. As a long task fills that space, compaction reduces earlier context into a smaller form so the work can continue.
The important question for me is what survives that process. A task includes the original request, but it also accumulates corrections, constraints, failed attempts, and small decisions made along the way.
In my experience, Codex has handled that continuity well. In the OpenCode setup I was using, I repeatedly found that important conversational details disappeared after compaction.
Here is a hypothetical example of the kind of problem I mean. Suppose I ask for two buttons and then clarify that I want them centered. The agent makes that change, continues working on other things, and eventually compacts the conversation. After that, it puts the buttons back on the left.
I remind it to center them. It works through more changes, compacts again, and forgets again.
Writing the requirement into a GitHub issue or an execution plan gave it something durable to refer to. But development also involves lots of smaller decisions made in conversation. I do not want to turn every one of those into a separate documentation task just to keep the agent from undoing it later.
That was the frustrating part of my earlier OpenCode experience: I was spending time and usage repeating decisions I had already made. I went back to Codex because I needed to get work done on Shokken.
The Backup Needs to Work Before I Need It
Now I have another reason to revisit that choice. My higher-usage subscription lapsed, and I was unable to renew the tier I had been using. The lower allowance available to me has been difficult to fit around my workload.
That is a separate problem from my mistake with the unattended jobs. I need to bound those jobs properly, but I also need a workflow that can keep going when access to one provider changes.
I do not have a finished plan yet. OpenCode remains interesting because it could let me change providers while keeping more of the surrounding workflow in place. I need to find out whether I can make it reliable enough for the way I work.
Next Week
I want to try a simpler OpenCode setup. The Oh My OpenCode plugin I was using felt as though it added too much complexity, so I am considering removing it and working with the built-in Plan and Build modes.
Grok is another model I want to explore. A lot of my work needs a reliable agent that follows through on ordinary tasks; it does not always need the most capable model available. I need to try an alternative on my own work before deciding whether it fits.
The marketing work continues alongside that exploration: weekly product videos, app store improvements, and website improvements. Discovery is still the first problem to solve. The app store listings have not attracted much traffic, and although the website is starting to get visitors, I am not yet seeing a reliable flow from the website to the stores.
I am continuing to push bug fixes, with no major feature updates this week. The priority is getting people to find Shokken, understand what it does, and try it, while keeping my development tools available enough to support that work.