Plugging OpenAI into Coding App
The OpenAI-backed version felt fast right away, but the bigger point is architectural: the same loop, the same tools, and the same interaction pattern carried over without reworking the system around a new model.
I added the OpenAI API to Coding App as another model provider. The app was already set up around interchangeable providers, so this was less about inventing a new path through the system and more about plugging a new model into the path that was already there.
What I liked about this change is that the agent loop and tool system did not need to change. Conversation state, tool execution, streaming, and the general orchestration were already in place. The thing that changed was the provider adapter underneath that loop, not the loop itself.
That made the integration feel almost suspiciously clean. I did not have to rewrite the tools for OpenAI. File inspection, search, targeted edits, Git inspection, and browser actions all kept working through the same tool definitions and execution layer because the contract between the model and the app stayed basically the same.
The speed difference was obvious right away. Responses came back quickly, tool decisions happened quickly, and the whole interaction felt more responsive. In an agentic coding workflow that matters because latency stacks across every inspection step, tool call, and follow-up decision.
A big part of why this works is that the tools are sent to the model as structured definitions. The app sends the available tools with the request, and the model determines what to call, when to call it, and whether it needs another tool result before it can answer.
That is the part I find most interesting. Coding App is starting to feel less like a demo built around one model and more like a harness I could adapt to different purposes and connect to a local or cloud-based LLM. Keep the workspace, keep the tools, keep the inspectable loop, and swap the model underneath to see how it behaves.