Supporting Another AI Provider Meant Listening to Another Workflow

On June 15, Open Free Max added support for Kimi Code.

That sentence can be read as a line in a feature list. Another provider became available. The menu grew. People who preferred that tool could bring it into the same workspace as their projects and other AI sessions.

The product lesson was larger than the menu.

An AI provider is not only a source of answers. For people who work through command-line tools, it is also a set of habits. It has a way of starting, a rhythm of interaction, expectations about where the person will be, and behaviours that become familiar through repeated use. People do not choose a tool and then forget its character. They build working methods around it.

Supporting another provider therefore meant listening to another workflow.

We use "listening" carefully here. We are not inventing a customer interview or claiming a wave of requests that is not present in the supplied history. The evidence is the product milestone itself: OFM expanded its provider support on June 15. To make sense of that decision, the workspace had to treat the new tool as more than a label that launched a generic AI experience.

Compatibility would only be useful if it respected difference.

That idea changed how we thought about the role OFM should play. The product was not trying to declare one provider the correct choice or force every tool into an identical mould. It was becoming a shared place where several ways of working could remain recognisable while gaining a common layer of project context, visibility, and control.

A provider choice is often a workflow choice

From a distance, AI coding providers can appear interchangeable.

They accept instructions. They inspect project material. They produce text or changes. They run in terminals. If the category is described broadly enough, one tool can sound much like another.

People do not work at that distance.

They notice how a tool starts, what it asks, how it displays progress, when it waits for input, how it represents a continuing session, and what happens after an interruption. They learn which kinds of instruction produce useful results. They develop confidence in particular boundaries and work around others. Over time, the provider becomes part of the choreography of the project.

Changing providers can therefore feel like changing more than a model. It can alter the tempo of the day.

OFM needed to respect that reality because its purpose was not to replace every command-line AI tool with a single internal assistant. It was to give people a better way to coordinate the tools they already chose. If support existed only when those tools behaved identically, the product would be asking users to give up part of their working method in exchange for organisation.

That would be a poor trade.

Adding Kimi Code support on June 15 made the distinction concrete. The provider belonged in OFM, but it did not need to become a disguised copy of another provider. The workspace needed enough common structure to make the session visible and useful without erasing the provider's own mode of interaction.

This balance would become more important as OFM supported more tools. A shared workspace gains value from consistency, but consistency can become destructive when it denies meaningful difference.

The product had to learn where common structure helped and where it merely made the implementation look tidy.

The first temptation was a universal shape

A universal provider shape is attractive.

Every tool appears in the same list. Every session launches through the same action. Every active state looks the same. Every result follows the same lifecycle. The product becomes easier to explain, and each new provider appears to require only a new name behind an existing slot.

Some of that consistency is valuable. A person should not have to relearn the entire OFM interface each time they choose another AI tool. Projects should remain projects. Sessions should remain identifiable. Common actions should keep familiar locations and consequences.

The danger lies in assuming that visual consistency proves behavioural equivalence.

One provider may present an interactive choice where another begins immediately. One may make continuing a previous session central to its workflow while another emphasises a fresh start. One may expose status in a form the workspace can recognise easily; another may communicate progress differently. The person using the tool already understands some of those patterns and expects them to remain available.

If OFM flattened every difference, the universal shape would leak. The interface might show a clean common state while the underlying session waited for something else. A resume action might promise continuity the provider represented differently. A launch flow might insert unnecessary steps for one tool and omit a meaningful step for another.

The product would look consistent and feel unreliable.

So the common layer needed to stay modest. It could organise projects and sessions, provide a place to see work, and offer shared navigation. Provider-specific behaviour had to be observed rather than wished away.

This is not an argument for inconsistency everywhere. It is an argument for honest consistency: unify what has the same human meaning, and preserve differences that change what the user expects.

Kimi Code gave OFM another real workflow against which to test that boundary.

Listening without making the interface louder

Respecting another workflow does not mean exposing every provider detail in the main interface.

That would create a workspace covered in exceptions. Each provider could arrive with its own terminology, status labels, setup explanations, and controls. The user would see all the differences at once, even when they only cared about the tool active in the current project.

Listening required restraint.

The product needed to understand enough about the provider to host it responsibly while showing only what helped the person make a decision. Is this tool available? Is the session active? Which project does it belong to? Can the person interact with it in the way the tool expects? Can they return to the work later when the provider supports that path?

Those questions are user questions, not architecture questions.

We do not need to publish the private implementation used to support Kimi Code. This Build in Public story is not an integration guide, and readers do not benefit from a recipe that exposes how the product connects internal pieces. The meaningful transparency lies in the decision: provider support was judged by the continuity of the user's workflow, not by the presence of a logo.

That also meant avoiding premature abstraction. When a product has seen only a small number of workflows, it is easy to mistake their similarities for universal rules. Each new provider is evidence. It can confirm that a shared interaction truly has common meaning, or reveal that the existing design was accidentally tailored to the first tools supported.

Kimi Code was new evidence.

OFM could adapt its common layer where the new workflow exposed a false assumption. It could preserve the provider's own behaviour where forcing uniformity would make the experience less honest. The visible interface did not need to narrate that negotiation.

It needed to feel as though the provider belonged.

People should be able to bring their preference with them

Provider choice can be practical, personal, or both.

A person may prefer the quality of one tool for a certain kind of project. They may already have access to it. They may like its interaction style, trust its familiar limits, or use it because it fits the environment in which their project lives. Those reasons do not need OFM's approval.

The workspace's role is to avoid turning its own preferences into a barrier.

This mattered to the larger identity of Open Free Max. The name implies openness not as a promise that every external tool is identical or free of constraints, but as a commitment to giving users room to choose how they work. A command centre should not become a toll gate that only coordinates the provider its builder happens to favour.

Adding Kimi Code was one step toward that pluralism.

It did not mean every provider would be supported immediately or equally. Each addition creates real product work. Tools differ, evolve, and sometimes expose less of the state a shared workspace would ideally understand. OFM has to test support rather than announce compatibility based on a launch button alone.

Choice without dependable behaviour is not much of a choice.

The June 15 milestone therefore carried both expansion and obligation. Kimi Code users could bring another preferred tool into OFM. In return, OFM had to continue learning how to represent that tool without misleading them about what was active, available, or resumable.

This standard protects users who switch providers as well as those who remain loyal to one. A multi-provider workspace should let a person choose the right tool for a project without turning every switch into a change of organisational system.

The provider can change.

The project should still feel like home.

Compatibility is proven in ordinary moments

The word "support" can hide a low bar.

A product launches another product, therefore support exists. That may be sufficient for a prototype. It is not sufficient for a workspace someone depends on across several projects.

Useful compatibility appears in ordinary moments.

The tool needs to be found when the person expects it to be available. It needs to open in the intended project context. The visible session needs to correspond to the activity the person is actually using. Text and interaction need to remain usable. Closing, returning, and switching should have understandable consequences.

None of these moments is an impressive demonstration by itself. Together, they determine whether the provider feels native to the working day or merely attached to the side of the product.

That is why listening to workflow matters more than checking a technical connection. A successful launch can still produce a poor experience if the workspace ignores what happens immediately afterward. The person does not celebrate that a process started; they want to continue with the task.

OFM's history around this period shows repeated attention to those ordinary moments. File names with spaces needed to reveal correctly on Windows. Prose needed comfortable wrapping. active cards needed contextual titles. Slow system work needed to stop freezing the whole interface. Another provider entered that same environment of expectations.

The product could not treat its addition as isolated.

Kimi Code support had to coexist with the details that made OFM feel trustworthy elsewhere. Provider pluralism would only improve the product if each workflow inherited the same care around project context, visibility, and control.

Compatibility was not a gate that became permanently green on June 15.

It was a relationship OFM would have to maintain.

Difference revealed the purpose of the common layer

When several tools share one workspace, the obvious question is what should become common.

OFM's answer was beginning to take shape. The common layer should help people manage the parts of work that remain meaningful across providers: projects, visible sessions, orientation, continuity, and the ability to move between activities without losing the larger map.

It should not pretend that every provider thinks or behaves the same way.

This distinction gave the product a clearer purpose. OFM did not need to compete with each provider at being that provider. It needed to be good at the space around them: where the project lives, how the person sees current work, how they return after an interruption, and how several tools can belong to one working environment.

The provider could retain its own interaction. The workspace could retain the project.

This separation is useful for users because provider landscapes change quickly. A preferred tool today may be joined by another tomorrow. A person may use different providers for writing, investigation, coding, or repetitive work. If all project organisation is trapped inside one provider's experience, every change carries a high continuity cost.

OFM was moving toward a more durable layer. The workspace could hold the human map while providers supplied different forms of AI assistance inside it.

That ambition remained incomplete on June 15. Session continuity would later become a larger multi-provider question, and support would expand again. It would be inaccurate to project all later capability backward into the Kimi Code milestone.

What we can say is that another provider tested the emerging division of responsibilities.

OFM organised.

The provider worked in its own way.

The user chose how those two belonged together.

What this meant for people using OFM

For users, the immediate change was straightforward: Kimi Code became another supported choice inside Open Free Max.

The broader benefit was freedom from an unnecessary product decision. A person did not have to abandon their preferred provider simply because they wanted OFM's project-centred workspace. They could bring more of their existing method with them.

There was no claim that all providers became identical.

In fact, the value depended on the opposite. People could choose among tools because those tools offered different experiences and strengths. OFM's job was to make the organisational layer more consistent while allowing the provider workflow to remain recognisable.

This article does not provide a setup guide. It does not describe private connection details, internal detection, or launch instructions. Those details change and belong in product documentation where users need them, not in a founder story intended to explain the decision.

The user-facing meaning was simpler. OFM was widening the doorway.

We do not have a supplied metric for Kimi Code adoption, a count of requests, or evidence that one provider improved a particular outcome. We therefore make none of those claims. Adding support was a documented product milestone, and the lesson comes from what multi-provider support requires, not an invented success story.

The practical standard remained observable: when a user chose Kimi Code for a project, OFM should help that session belong to the workspace without asking the user to forget how their chosen tool worked.

The best version of support feels uneventful.

The person selects the tool they intend to use, enters the project context they recognise, and begins working. OFM remains present enough to organise the session and quiet enough not to compete with it.

Another provider increased the cost of assumptions

The first implementation of any product contains assumptions that do not look like assumptions.

A launch always begins this way. A session always presents this kind of state. A command-line tool always uses this interaction pattern. A user always starts fresh rather than returning. These statements may match the first supported workflow so well that they feel like facts about the category.

The next provider turns them back into questions.

That was one of the most useful effects of Kimi Code support. It increased the cost of designing OFM around any single tool. A shortcut that made perfect sense for one provider could no longer be treated automatically as the universal path. A generic label needed to be tested against another real interaction. The product had to notice which assumptions belonged to AI work broadly and which belonged only to the examples seen so far.

This process can make development slower in the short term. Generalising responsibly requires observation, exceptions, and sometimes revision. It is less convenient than declaring that every provider fits one contract.

It also makes the product more resilient.

An abstraction shaped by several real workflows is less likely to collapse when the next tool arrives. A shared interface that openly permits difference can evolve without breaking every existing path. Most importantly, users are less likely to encounter a product that says it supports their provider while quietly expecting them to use it like another one.

OFM would later add more command-line AI tools, and continuity across them would become its own product problem. June 15 was not the end of that evolution. It was an early point where plurality stopped being theoretical.

Every new provider would bring another chance to discover what OFM had assumed.

Listening meant letting those discoveries change the product.

Openness has maintenance costs

Supporting choice is easy to celebrate and difficult to maintain.

Providers update their tools. Interaction patterns change. Installation conditions vary across operating systems. Session behaviours evolve. A workspace that supports several providers inherits a moving set of relationships.

OFM could have chosen a narrower path. Supporting one preferred tool would reduce variation and make some interface decisions easier. The product could optimise deeply around one workflow and ask everyone else to adapt.

That remains a plausible product strategy for others.

It did not match the direction OFM was taking.

People with many projects often already use several AI tools. Their choice can depend on the task, access, habit, or environment. A workspace intended to help them coordinate that reality becomes less useful if it simplifies development by denying the reality.

The trade-off is ongoing maintenance. Each supported provider must remain more than a forgotten entry in a menu. Availability needs to be understandable. Changes need to be noticed. Common workflows need to remain coherent, and provider-specific behaviour needs room to evolve.

We should not pretend that this cost disappeared after June 15. Openness is a commitment to continued product work, not a one-time feature. Some integrations will lag behind a provider change. Some differences will be difficult to represent cleanly. The product will need to decide where dependable support is possible and where a claim would be premature.

The honest boundary is better than a long list of nominal compatibility.

Listening to another workflow meant accepting responsibility for that boundary.

The product became a host

Kimi Code support helped reveal a useful metaphor for OFM.

The workspace was becoming a host.

A good host creates common ground without demanding that every guest become identical. There is a place to arrive, enough structure to understand what is happening, and respect for the different purpose each person brings. The host does not need to become the centre of every conversation.

For OFM, the common ground was the project-centred environment. Providers could appear as distinct tools inside it. Sessions could remain visible. People could move across their work while keeping a broader map than any single provider needed to hold.

The metaphor has limits. Software providers are not guests, and product design requires exact behaviour rather than hospitality alone. But it captures the position OFM was choosing. The workspace would create order around different AI workflows rather than erase their differences to make its own interface easier.

That position also kept the user at the centre. The relationship was not OFM choosing providers for people. It was people choosing tools and OFM helping those choices coexist with projects, memory, plans, and future continuity.

On June 15, that future was only beginning. Kimi Code support was one milestone among many, not evidence that the multi-provider challenge had been solved. Yet it made the direction concrete.

Another provider entered the workspace.

OFM had to make room without pretending the newcomer had always behaved like everything already there.

That is what listening looked like in product form.

The question that followed the addition

Adding a provider answers one question: can this tool belong here?

It immediately creates another: can the user's work remain continuous when the tool changes?

That second question would grow in importance as OFM expanded. A person might begin with one provider, prefer another for a different project, or return to a previous session after time away. The workspace would need to preserve orientation without implying that context moves perfectly between tools when it does not.

The Kimi Code milestone did not solve cross-provider continuity, and we will not rewrite history to make it do so. It did establish the plural environment in which continuity would become unavoidable.

That is a valuable kind of Build in Public lesson. Product evolution is not a line of isolated solutions. Each solution changes the questions the product is capable of seeing. Supporting another provider widened choice and exposed the limits of provider-specific assumptions. It also made the shared layer around those tools more important.

The next work would not be simply to add more names.

It would be to understand what people need to carry across them: project identity, working context, session recognition, local knowledge, and confidence about what can or cannot resume. Some of those capabilities would arrive later. Some remain open questions because providers expose different possibilities.

The principle from June 15 continues to guide the answer.

Listen before flattening.

Unify meanings, not appearances.

Let users bring their preferences.

Be honest when two workflows cannot support the same promise.

Supporting Kimi Code was a feature. Treating it as another real way of working was the product decision.

That decision made OFM slightly less simple to build and substantially more faithful to the people it was being built for.