Adapting AI Coding Tools with a Local Multi-Protocol Gateway: A Practical Implementation

1. Background and Problem: Protocol Fragmentation in AI Coding Tools

Today’s AI coding tool ecosystem is notably fragmented. Different tools are built on different underlying communication protocols: some support only the Anthropic Messages protocol, some are designed around the OpenAI Responses protocol, and others use OpenAI Chat Completions or the Gemini protocol. The direct consequence of this fragmentation is that developers cannot freely pair a tool with the model service that fits it best. A coding assistant that speaks only the Anthropic protocol, for example, cannot natively call a model exposed through an OpenAI protocol—and vice versa.

On top of that, these tools keep their configuration files scattered across their home directories in a variety of formats (JSON, TOML, environment variable files, and so on). Editing them by hand is tedious, and it is all too easy to break existing comments, indentation, and key ordering in the process, which makes the configuration hard to maintain. A gateway component that runs locally, speaks multiple protocols, and manages configuration automatically is therefore the key technical answer to both pain points.

2. System Architecture Overview: Local Gateway + Configuration Manager

The solution consists of two core components:

1. Local protocol gateway. It listens on 127.0.0.1:3425 and exposes all four API styles simultaneously: OpenAI Chat Completions, OpenAI Responses, Anthropic Messages, and Gemini. Inside the gateway, requests and responses are converted bidirectionally between protocols, and the conversion fully preserves key semantics such as streaming output, tool calling (Function Calling / Tool Use), and reasoning content.

2. Configuration manager. It provides a graphical or command-line interface. After the user selects a model, the manager modifies only the few necessary keys in the target tool’s configuration file and leaves everything else—comments, key order, indentation style—exactly as it was. Writes are atomic: either the entire change is applied or nothing is written at all, so a configuration file is never left half-broken.

The value of this architecture is that developers can freely mix and match coding tools and models without touching any tool’s source code or understanding the details of each protocol.

3. Key Points of Protocol Conversion

3.1 Semantic Differences Across the Four Protocols

Protocol	Typical request structure	Tool-calling fields	Streaming event model
OpenAI Chat Completions	messages array	tools / tool_calls	SSE delta chunks
OpenAI Responses	input + instructions	tools / function_call	semantic event stream
Anthropic Messages	messages + system	tools / tool_use	content_block_delta
Gemini	contents + systemInstruction	functionDeclarations	chunked responses

The gateway must build mappings between these structures. When converting an Anthropic tool_use block into an OpenAI tool_calls array, for example, it must handle the correspondence between the id, name, and input fields. When converting OpenAI streaming deltas into Anthropic content_block_delta events, it must maintain a state machine that tracks block indices and event types.

3.2 Preserving Streaming Output

Streaming output is central to the user experience of a coding tool. The gateway must keep token-level incremental delivery intact throughout the conversion; the protocol translation must never degrade streaming into a single one-shot response. Implementations typically use an “event-driven + buffered queue” approach: as soon as the upstream returns an incremental chunk, the gateway immediately maps it into the target protocol’s event format and pushes it downstream, while updating an internal state machine to handle tool-call arguments that are split across multiple chunks.

3.3 Preserving Tool Calls and Reasoning Content

For tool calls, the gateway must keep call IDs consistent across the conversion and correctly handle the multi-turn interaction loop: the model requests a tool call, the client executes the tool, the client returns the result, and the model continues generating. For reasoning content (the chain-of-thought output that some models return), the gateway must recognize the corresponding fields and find an appropriate place for them in the target protocol so that nothing is lost.

4. The Configuration Manager’s Write Strategy

The configuration manager follows a minimal-intrusion design. The table below describes generically where each tool type’s configuration is written:

Tool type	Write location	What is changed
Claude Code–style tools	settings.json in the user directory	API base URL, authentication token, and model variables in the environment variables
Codex-style tools	config.toml in the user directory	Adds a model provider table and a model entry; the model list is written to a separate JSON file
Gemini CLI–style tools	settings.json and .env in the user directory	Base URL pointing to the gateway, API key authentication method, model name
OpenCode-style tools	Each tool’s own configuration files	Adds a gateway provider entry, with models written in “provider/model” format

Atomic writes are typically implemented with a “temporary file + rename” pattern: the complete modified content is first written to a temporary file in the same directory, and the original file is then replaced through an atomic rename. Even if the process crashes or power is lost mid-write, the original configuration file remains intact.

Preserving comments and formatting means the parser must not simply deserialize JSON/TOML into objects and serialize them back—that would discard comments and key ordering. The correct approach is precise line-level text replacement, or a parser library that supports syntax-tree preservation: locate the target key first, then modify only its value.

5. Typical Use Cases

Case 1: A tool that only speaks Anthropic calling a non-Anthropic model

Suppose a coding tool only understands the Anthropic Messages protocol, but the developer wants to use a model exposed through the OpenAI Chat Completions protocol. Point the tool’s API base URL at the local gateway. The gateway accepts the Anthropic-format request, converts it into OpenAI format, forwards it to the model service, and converts the response back into Anthropic format. From the tool’s perspective, nothing has changed.

Case 2: A Responses-protocol tool calling a subscription-based model service

Another tool uses the OpenAI Responses protocol, and the developer wants to take advantage of a subscription-based model service. The gateway performs the same protocol mapping, so the tool can use the target model without any modification.

Case 3: Multiple tools sharing the same model configuration

A developer runs several coding tools locally. The configuration manager writes a gateway-pointing configuration into each of them. When it is time to switch models, the developer simply selects the new model in the manager’s interface, and all tool configurations are updated in one pass—no manual file-by-file editing required.

6. Deployment and Verification

1. Start the gateway. Make sure port 127.0.0.1:3425 is not already in use. After startup, use the health check endpoint to confirm that all four protocol endpoints are reachable.
2. Configure the tools. Select the target tool and model through the configuration manager, then check that the written configuration files still keep their original comments and formatting.
3. Verify streaming output. Start a conversation in the tool and observe whether the response arrives incrementally rather than appearing all at once.
4. Verify tool calling. Trigger a conversation that requires an external tool call, and confirm that the tool-call arguments are complete, the call IDs are consistent, and the multi-turn interaction works correctly.
5. Have a rollback path. The configuration manager should provide a “restore defaults” or backup feature so that you can quickly recover if a configuration ends up in a bad state.

7. Conclusion

The combination of a local gateway and a configuration manager is, in essence, a protocol adaptation layer plus a configuration abstraction layer inserted between AI coding tools and model services. The former solves the interoperability problem—“the tool speaks one protocol, the model exposes another”—while the latter solves the operational problem of configuration scattered across multiple tools and error-prone manual editing. Together, they let developers combine tools and models freely at very low cost while keeping configuration files readable and maintainable. For teams that switch between multiple AI coding tools, or that want the flexibility to choose different model services, this approach has clear practical value.