1. The Realization: "Claude Code Is Unnecessary"
Claude Code is excellent. It can directly manipulate local files. Responses are real-time. Errors can be identified and corrected immediately. In terms of raw capability, it clearly outperforms the system built today.
And yet: unnecessary.
With Claude Code, data lives on Anthropic's servers. Context disappears when the session ends. Costs accumulate with every use. It is high-performance — but it is borrowed high-performance.
The system built today is asynchronous, with a wait of around thirty seconds. It is not real-time. But the data lives in your own GitHub. Context persists across sessions. The cost is zero, and with every session, the tr/ repository grows.
A choice was made: owned infrastructure over high-performance borrowing. What follows is the reasoning behind that choice.
2. Three Properties of a Tool
Tools share three common properties.
First: ownership does not belong to you. A hammer is yours, but a SaaS tool is not. Terms of service change. Prices increase. Services shut down. All such decisions rest with the provider.
Second: costs scale with usage. The more you use, the more you pay. Operating under a usage ceiling distorts judgment. The question "is this worth the cost?" arises in places where it should never need to be asked.
Third: accumulation does not stay with you. Hundreds of conversations in Claude Code produce nothing durable. The context, the decisions, the patterns — all of it dissolves with the session. The next session starts from zero.
3. Three Properties of Infrastructure
Infrastructure inverts each of these.
Ownership belongs to you. tokistorage/tr is your repository. If GitHub were to shut down, the git repository can be cloned locally and migrated to any hosting service. There is no lock-in.
Costs do not scale with usage. Actions on public repositories run without limits, at no cost. Whether used once a day or ten times, the fixed cost remains zero. The ability to use something without watching the meter changes the quality of decisions made with it.
Accumulation stays with you. Context written to memory/context/ can be pulled in the next session. Skills defined in skills/ compound over time. Data in project/cache/ keeps updating. The more you use it, the more it fits.
4. Is Asynchrony a Flaw?
The system has one clear weakness: it is asynchronous. Push a request, wait for Actions to run, pull the result. Tens of seconds pass.
But looking at actual work, "cannot wait thirty seconds" describes remarkably few tasks. Morning project reviews, status updates, document generation, essay publication — all of these are fine with asynchrony. The demand for real-time response was a habit formed around tools, not a genuine requirement of the work.
Infrastructure does not need to respond instantly. A power plant is not on-demand — it runs continuously, available when needed. This system works the same way.
5. The Design Authority Belongs to Different People
A tool is designed by its provider. Users operate within that design. Feature requests can be submitted; whether they are accepted is the provider's decision.
Infrastructure is designed by you. Write a yaml file in .github/workflows/ and any process can be implemented in Actions. Add a skill definition to skills/ and the behavior of the system changes. Design authority rests with you.
In a single day, three use cases came online: morning briefings, task updates, and essay publication. Tomorrow, a fourth can be designed. The limit is not the provider's roadmap — it is your own imagination.
Tools deplete. Infrastructure grows. The difference comes from who holds the design authority.