The Day the Terminal Moved Closer to the Work

On June 2, 2026, Open Free Max began with a simple discomfort: the place where a project was discussed and the place where it was changed felt too far apart.

That distance is easy to miss when every tool works by itself. A conversation can happen in one window. A list of tasks can live in another. The actual project can sit somewhere else, with a terminal opened only when it is time to do something serious. Each piece is familiar. The day becomes unfamiliar.

The first question was not how to build another terminal. It was whether the terminal belonged closer to the work at all.

The distance inside a normal working day

The word “terminal” carries a particular image. It suggests commands, files, processes, and a place for people who already know what they are doing. That image was not wrong, but it was incomplete for the product we wanted to make.

AI-assisted work often begins in ordinary language. Someone describes an idea, examines a problem, asks for a change, or tries to understand a project that has become difficult to hold in their head. Then, at some point, the idea has to touch the project. A file changes. A command runs. A result appears. The conversation and the action are part of the same movement, even when the tools treat them as separate worlds.

We were interested in that movement. Not because every user should become a command-line expert, and not because a terminal is exciting on its own, but because the separation created unnecessary moments of doubt. Which project is open? Is the command running in the right place? Did the result belong to the conversation or to an earlier attempt? What was supposed to happen next?

Those questions are not always dramatic. They are small interruptions. Small interruptions accumulate.

The early product was therefore less about adding power and more about reducing the number of times a person had to reconstruct the state of their own work.

The first choice was a product choice, not a layout choice

It would have been easy to describe this as a screen design problem. Put one panel here, another panel there, make the borders clearer, and call the work complete. That framing would have made the decision smaller than it really was.

Moving the terminal closer to the work changed what counted as the work. It meant that execution was not a hidden backstage activity. It was part of the visible project experience, alongside the thinking, the files, and the decisions that gave a task its meaning.

That had consequences. A useful workspace could not be organised only around individual tools. It had to be organised around the state of a project. The person using it should be able to understand where they were, what they were trying to do, and which part of the project was active without opening a separate investigation every time.

We did not have a finished answer on that first day. We had a direction: bring the parts of a working session closer together so that the person does not have to act as the integration layer.

The direction was more valuable than a polished screen. It gave later decisions somewhere to point.

Two possible futures for the workspace

There were at least two credible ways to continue.

One option was to keep the conventional separation. The conversation would be the conversation, the editor would be the editor, and the terminal would remain a specialised surface. This approach was comfortable because it respected familiar boundaries. It also reduced the amount of product thinking required: users already knew which window to use for which job.

The other option was to make the project the centre of gravity. Tools could still exist as tools, but they would be arranged around the work a person was doing. The terminal would not disappear or become decorative. It would become easier to understand as one part of a larger flow.

The second option carried more responsibility. When tools are separate, confusion can be blamed on the gaps between them. When they are brought together, the product has to make the relationship clear. It has to communicate enough context without filling the screen with explanations.

We chose the more demanding direction because the gaps were part of the problem. A workspace that merely assembled familiar panels would look productive while preserving the same mental cost.

The terminal became a neighbour

The useful metaphor was not “the terminal is embedded.” That is an implementation description, and it says very little about how the experience should feel.

The better metaphor was that the terminal became a neighbour. It was close enough to the project that the person could move between intention and action without leaving the neighbourhood of the task. It still had its own character. It still required respect. But it no longer felt like a distant room that had to be visited whenever the work became real.

This distinction mattered because proximity changes behaviour. When an action is visible and near the decision that motivates it, people can notice mismatches earlier. They can see when a result does not fit the original intention. They can return to the surrounding context instead of relying on memory to explain what happened.

That was the experience we were trying to encourage. The terminal was not there to make the workspace look technical. It was there to make the relationship between a thought and its consequence easier to follow.

The product was beginning to take a position: AI work should not feel like a chain of disconnected hand-offs.

What we learned from the first shape of the product

The first lesson was that proximity is not the same as density. Putting more things on one screen does not automatically create a better workspace. If every surface competes for attention, the person still has to perform the integration work, only now inside a busier frame.

The second lesson was that context has to travel with action. A terminal result without a sense of the project can be difficult to interpret. A project view without a way to act can feel like a dashboard that only reports. The value appears in the connection between them.

The third lesson was quieter. Product language shapes product behaviour. If we described the terminal as a separate advanced tool, we would keep designing around separation. If we described it as part of a project workspace, we would keep asking how it supported continuity.

The work did not solve every problem. It made the remaining problems more visible, which was useful. We could now see that sessions, projects, files, and active work would need to be understandable as related things rather than as a collection of windows.

That became one of the early threads in OFM's evolution.

The cost of keeping context in your head

There is a particular kind of fatigue that comes from switching tools. It is not the fatigue of a difficult task. It is the fatigue of remembering what each tool knows and what it does not know.

A person can be perfectly capable of using a terminal and still lose time to the question of where they are. They can be comfortable with AI and still hesitate before moving a result from one place to another. They can manage several projects and still feel that every new window asks them to begin the orientation process again.

We wanted OFM to take on more of that orientation work. That does not mean hiding complexity or pretending that projects are simple. It means making the current situation legible enough that the next action does not require a private reconstruction of the whole day.

This was especially important because the product was not being imagined for one narrow professional identity. It could serve people who build software, people who create content, people who explore ideas, and people who move between projects with different levels of technical depth. The terminal had to be available without becoming a gatekeeping symbol.

That balance remains important. A powerful surface should be close at hand, but its presence should not imply that everyone has to use it in the same way.

What this meant for the people using OFM

For a user, the decision did not need to appear as a manifesto. It could appear as a small reduction in friction.

The project is easier to recognise. The action is easier to locate. The result is less likely to feel detached from the thing that produced it. Moving between thinking and doing still takes attention, but fewer moments are spent wondering which part of the product owns the current state.

That is a modest promise, and we prefer modest promises that survive contact with real work. OFM is not intended to remove every interruption from a complex project. It is intended to make the interruptions meaningful instead of accidental.

The terminal being closer to the work is one expression of that promise. It is not the promise itself.

The question we carried forward

Once the terminal moved closer, a new question appeared: what else should stay with the project?

If the project is the centre, then a session should not vanish into a generic history. A decision should not become detached from the files it affected. A repeated workflow should not need to be rediscovered every time. A person working across several projects should not have to carry the entire map in their head.

Those questions led toward later work around project organisation, sessions, continuity, memory, and the broader shape of the workspace. They were not all solved at once, and they should not be presented as if they were. The first step was simply to notice that the distance between intention and action was a product problem.

The project began on June 2 with that observation.

The terminal moved closer. The work became easier to see as one connected experience. And the direction of Open Free Max became clearer: build a place where advanced tools support human momentum without asking people to become their own operating system.

The first project was also a test of attention

There is a difference between being able to do something and being able to stay focused while doing it. A person may know exactly how to open a terminal, find a project, run the relevant action, and return to the conversation. The sequence can still break the thread of thought that made the action necessary.

That thread is often more valuable than the action itself. It contains the reason for the change, the uncertainty that led to it, and the judgement used to decide whether the result is good enough. When the tools are separated, the thread becomes something the user has to carry from window to window. When the tools are closer, the product has a chance to help preserve it.

This was one of the reasons the early direction mattered even before the workspace felt complete. It gave us a way to judge future additions. Would this make the current project easier to understand, or would it add another surface that the user had to remember? Would the new capability support a decision, or merely create another place where activity could appear?

Those questions do not produce a spectacular demo. They produce a quieter kind of quality. A person finishes a task and realises that they spent their attention on the task rather than on keeping the tools synchronised.

That was the kind of improvement we wanted to pursue.

The terminal was close, but closeness alone was not enough. The product also had to respect the user's attention once they arrived there.

Why closeness must still leave room

Bringing work together can easily become an excuse to show everything at once. That would have been a poor conclusion to the original problem. If the user has to watch every process, every message, every project, and every possible action at the same time, the distance between tools has been replaced by the distance between competing signals.

We were interested in closeness with boundaries. A workspace should make related things available without insisting that they all be active. The person should be able to move from intention to action, then return to the wider project when the action is complete. The surrounding context should remain available, but it should not shout over the thing currently being considered.

This is why the early product direction was not simply “put the terminal in the middle.” The deeper decision was to make context easier to reach while keeping attention under the user's control. That distinction would matter later as the product gained more views, more sessions, and more ways to work.

There is a temptation to describe a unified workspace as a single surface. In practice, unity is a feeling of continuity. The user can understand how one part relates to another, even when the parts remain visually distinct.

That feeling cannot be forced through a layout alone. It comes from consistent names, visible project identity, predictable movement, and a clear answer to the question, “Where am I?”

The first terminal decision was therefore also an early decision about restraint.

The next version of the question

Once the terminal became part of the project experience, the next challenge was no longer getting from a conversation to an action. It was returning to the action later without losing the meaning around it.

Projects do not happen in one uninterrupted sitting. A person leaves for another responsibility, changes projects, tries a different direction, or comes back after the initial urgency has faded. A workspace that only feels coherent while it is open is helpful for a moment. A workspace that helps a person resume is useful over time.

That was the question the first day left behind. How could OFM make the whole working day feel connected, not just the current interaction? The terminal had moved closer to the work, but the work still moved through time. Context would need to travel with it.

We did not have to solve that entire problem on June 2. In fact, trying to solve it immediately would have hidden the value of the first observation under too many ambitions. The important thing was to recognise the direction: the product should reduce the amount of reconstruction required at every return point.

That direction eventually connected to projects, sessions, continuity, memory, and the way people manage several active efforts at once. Each later decision would have its own trade-offs. None of them would make the original question disappear.

The terminal moved closer because the work deserved a home, not because one more panel was missing from the screen.

There was another consequence that was easy to miss. Once the terminal was treated as part of the project, the product could no longer define success only by whether an action completed. It also had to ask whether the person understood what had happened. A result that appears without context can be technically correct and still leave the user unsure whether it belongs to the task they had in mind.

That distinction is important in AI-assisted work because the distance between a request and a result can be surprisingly short. The speed is useful, but speed can hide the need for review. Keeping the action near the surrounding project gives the person a better chance to notice the difference between “something happened” and “the right thing happened.”

The product was not trying to make judgement unnecessary. It was trying to keep judgement close to the evidence.

This also affected the emotional shape of the workspace, without requiring the product to pretend that work is always calm. A person can handle a difficult result more easily when they can see where it came from. They can decide whether to continue, revise, or stop without first searching through a series of disconnected surfaces. The product does not remove uncertainty; it gives uncertainty a place to be examined.

That became a recurring measure for OFM. When a new capability was proposed, we could ask whether it helped people remain present in the work. If it added power but made the state harder to read, it needed another look. If it simplified an action but separated the action from its reason, it was not finished.

The first day did not give us a complete philosophy. It gave us a useful instinct: keep the next action near the question that created it, and keep enough of the project visible that the person can still make a meaningful decision.

That instinct is still present in the product. It is why the terminal was moved closer, and why the move mattered more than the panel itself.

There is a human reason to care about that continuity. A project is not only a sequence of successful actions. It is also the place where a person makes choices about what deserves another attempt and what should be left alone. Those choices are easier when the product keeps the relevant evidence nearby. The user can see enough of the path to distinguish a deliberate pause from an unfinished accident.

This is particularly important when AI is involved. The speed of generation can make a project feel as if it is moving faster than the person's ability to evaluate it. A workspace that joins the conversation to the action gives the user a better place to slow down without losing the thread. It supports momentum, but it does not define momentum as constant motion.

That was the earliest version of OFM's ambition: not to make every task automatic, but to make the transitions between thought, action, and judgement less wasteful. The terminal was the first visible expression of it. The broader product would have to keep proving the same idea in other forms.

Looking back at the starting point, the decision feels less like a screen arrangement and more like an agreement with the user. We will make powerful tools available. We will keep them close to the project. We will try to preserve enough context that you can decide what to do next without rebuilding the entire situation from memory.

That agreement is still unfinished, which is exactly why it remains useful. A product that is still evolving needs a question that can survive new features. The terminal gave us one.