Why We Still Keep Building Termdock
Eight months in, many features that once felt fresh in Termdock are now showing up in bigger CLI tools. That does not change the reason we keep building it. The point was never to survive on feature novelty alone. The point was to make heavy CLI work across multiple projects feel less fragmented.
Termdock has been out for around eight months.
During that time, one thing became pretty obvious. Some of the features that once felt distinct are now showing up in bigger CLI tools. That is normal. Useful ideas do not stay exclusive for long. Still, that reality raises a fair question.
If the features eventually get copied, why keep building Termdock?
My answer is simple. Because the original reason has not changed.
I did not start Termdock to win on feature novelty
I did not start Termdock by thinking about market size first. I did not start with a plan to turn a feature list into a business story.
I started because my own workflow had become irritating.
If you spend most of your day inside the CLI while juggling several projects, you probably know the feeling. The problem is rarely one command. The problem is the endless switching. Switching terminals. Switching workspaces. Switching repos. Switching logs. Switching tests. Switching agents. After enough of that, your attention gets shredded.
That is the problem Termdock has always tried to reduce.
After others catch up, the real question is what still matters
Even now, there are still a bunch of things I care about a lot.
- free terminal splitting
- fast drag and paste workflows
- steadier terminal and git behavior
- smoother multi-workspace switching
- dropping documents and images straight into the workflow
- compressing large documentation before sending it to an agent
- built-in AST search for symbols and relationships
None of those are guaranteed to remain unique forever. That is not really the point. The harder part is not shipping one feature. The harder part is connecting them into a workflow that actually feels good after hours of use. A tool can look impressive from the outside and still feel tiring in real daily work.
That difference matters more than people think.
Why getting copied does not automatically erase the point
I think a lot of tools run into the same misunderstanding. People reduce value to one question: is this feature still unique?
In practice, single features are easy to imitate. What is harder to replicate is the overall feel of the environment. Can you trust the terminal state? Can you move between contexts without losing momentum? Does the tool reduce friction, or does it just add another layer of cleverness on top of an already messy workflow?
That is why being copied does not automatically erase the point. If the tool is solving a problem that keeps showing up in real use, the work is still worth doing.
The business question is real, but it was never the starting point
I am not pretending the business question does not exist. Of course it does. If bigger tools keep absorbing similar ideas, it is reasonable to ask what remains.
But the honest answer is that Termdock did not start as a business-first product. I did not even need it to be open source for that to remain true. The first question was always simpler: do I actually want to use this? Would people who live in the CLI and bounce across multiple projects genuinely want this environment?
As long as the answer is still yes, I do not think the work becomes meaningless.
1.6 changed what Termdock is becoming
One of the most important things in 1.6 was not the sort of feature that immediately shows up in a screenshot.
We added the API layer.
That changes the role of the product in a real way. Termdock is no longer only something a person clicks through manually. It can now be controlled by an agent. You can send commands remotely. You can monitor state remotely. You can plug it into a larger flow. It is no longer only a terminal UI. It is starting to become a terminal environment that can be orchestrated.
The real difference in terminal tools is rarely the feature list
It is easy to compare terminal products by checklist. Does it split panes? Does it support workspaces? Does it have some kind of agent integration?
Those things matter, but they are not the whole story. If you use a tool every day, the bigger questions are more practical. Does switching feel smooth? Does the state stay trustworthy? Does the session become fragile over time? When you drag data into the tool, does it save time or create more cleanup? When agents get involved, does the workflow become stronger or more brittle?
Those are not always the flashiest product bullets. They are still the things that decide whether people keep using the tool.
The 1.6 UI work was about everyday friction, not decoration
1.6 was not only about capabilities. It also cleaned up a lot of UI details.
That may not sound like a big deal if you treat terminal tools as purely functional surfaces. I do not think that view holds up in real use. If you spend hours inside the same environment every day, the feel of the interface matters.
In this release we removed a lot of unnecessary borders. We let the background image extend across the whole workspace. We started adjusting the theme against the background automatically. We still let people tune the overlay and glass blur.
I do not think terminal UI has to be flashy. I also do not think it should feel thrown together. If the environment looks calmer and feels more coherent, that affects whether you actually want to keep it open all day.
Here is the newer UI:

Wallpaper credit:
https://www.pixiv.net/artworks/129657581
And here is an older version:

Put side by side, the difference is not only color. The boundaries feel different. The background sits differently. The information sits on top of the surface in a cleaner way. Not everyone will care. People who spend long hours in this kind of tool usually do.
What I actually want from the next generation
I am less interested in stuffing in more flashy capabilities. I care more about whether the tool feels more dependable after a full day of work.
That is why I do not think of the next version as a simple roadmap of features. I think of it as a direction. I want Termdock to move toward something that feels steadier, smoother, and easier to trust.
Make long-running work feel steadier
Fewer weird edge cases. Fewer moments where the UI looks active but the state does not feel trustworthy.
Push context switching down even further
Less interruption when moving across terminals, workspaces, agents, and toolchains.
Let agents plug into the workflow for real
Not just usable by a person, but naturally controllable as part of a larger agent-driven workflow.
This kind of work does not always look dramatic from the outside. It still changes daily use in a very obvious way. Less jank. Less breakage. Better interaction feel. More confidence in long-running sessions. More stable agent workflows.
That matters more to me than one more flashy headline feature.
Why I still want to keep building it
Being caught up to does not automatically erase the reason a tool exists. Sometimes it just confirms that the problem you saw was real in the first place.
What I care about now is whether we can keep improving the part that affects real daily work. Less switching. Less interruption. Better rhythm. More trust.
As long as that still feels worth chasing, I will keep building Termdock.