I Like Codex, but It Can't Use DeepSeek, So I Built a Local Gateway

Recently, I open-sourced a small tool called AgentGate.

It wasn't a big project I planned from the start.

Nor did I make it because AI agents are trendy and I wanted a related product.

Its origin was very specific:

I quite like using Codex, but I wanted Codex to use DeepSeek.

It turned out not to be that simple.

Codex uses the OpenAI Responses API. DeepSeek mainly offers an OpenAI Chat Completions compatible interface.

The two protocols don't match.

In other words:

I like the Codex experience. I also want DeepSeek's model capabilities and cost advantages. But they can't connect.

This problem sounds small.

But for someone like me who uses AI to write code every day, it's very real.

I don't want to give up a tool I'm comfortable with just to use DeepSeek. Nor do I want to change a bunch of configurations, environment variables, Base URLs, and API keys every time I switch models.

So I ended up building a local gateway.

It lets Codex call DeepSeek through a local entry point.

That tool is AgentGate.

---

At first, I just wanted Codex to use DeepSeek

I generally prefer how Codex works.

It fits better into the development workflow.

For example, analyzing code, modifying files, executing tasks, and advancing development based on context—these experiences feel more natural to me.

But regarding models, I don't want to be tied to a single provider.

Sometimes I want to use OpenAI. Sometimes I want to try Anthropic. Sometimes I want DeepSeek. Sometimes I look at Kimi, MiniMax, OpenRouter, or other compatible interfaces.

Different models have different characteristics.

Some are stronger at reasoning. Some are faster. Some are cheaper. Some are better for everyday coding tasks. Some have better multimodal capabilities.

So I hope the tool and model aren't too tightly coupled.

I can keep using the tool I like. I can switch models based on the scenario.

But when I actually started, I found the problem wasn't just changing an API address.

Codex sends Responses API requests. DeepSeek accepts Chat Completions format.

Someone needs to do protocol conversion in between.

That was AgentGate's earliest core capability:

Convert Codex's Responses API into Chat Completions requests that DeepSeek can understand.

This way, Codex remains Codex.

DeepSeek remains DeepSeek.

AgentGate handles the translation in between.

For me, the value is direct:

I can keep using the tool I like while also using the model I want.

---

The real problem isn't the model, but the protocol mismatch

Previously, I focused more on the models themselves.

Which model is stronger. Which is cheaper. Which has a longer context. Which has better coding ability. Which is more stable in responses.

These are certainly important.

But after building AgentGate, I increasingly feel:

The truly troublesome part of AI coding tools isn't just model capability, but the fragmentation of the entire integration chain.

Some tools use the Responses API. Some use the Anthropic Messages API. Some use Chat Completions. Some providers support native protocols. Some only support compatible interfaces. Some models support reasoning_content. Some support tool_use. Some support images. Some don't.

If you're just playing around occasionally, these differences are tolerable.

But if you use them daily, they become a burden.

Because what you really want to do is write code, modify projects, and advance tasks.

Not study the protocol details of every tool and provider.

I want Codex to do a task.

What I care about is:

Can it understand the context? Can it correctly modify code? Can it execute reliably? Can it recover when it fails?

But there's a lot to handle behind the scenes.

Request format conversion. Model name mapping. Tool call adaptation. Streaming output must not break. Error messages must be understandable. And ideally, fallback to a backup provider on failure.

These aren't what users want to worry about.

But if not handled well, users get interrupted by them every day.

So AgentGate's first value isn't "adding another layer of proxy."

It's:

Consolidating these scattered protocol differences into a local gateway.

---

As I worked, I discovered DeepSeek doesn't support multimodal

Initially, I focused on connecting Codex to DeepSeek.

After text tasks worked, the experience improved a lot.

But soon I hit another problem:

DeepSeek doesn't support multimodal image requests.

This issue is quite common in AI coding scenarios.

For example, you want the agent to look at a UI screenshot. Look at an error page. Look at a product prototype. Look at a design mockup. See where a layout is off.

In such cases, the request may include images.

If the backend provider doesn't support Vision, it usually fails outright.

So what to do?

The simplest approach:

Don't use images.

But that's not right.

Because the problem isn't that users shouldn't send images.

Nor that Codex shouldn't handle images.

The real problem is:

Different providers have inconsistent capabilities.

DeepSeek handles many text and code tasks well. But it doesn't support multimodal. I've verified that KimiCoding can properly handle multimodal requests.

So a better approach isn't making users decide manually each time.

It's letting the gateway decide.

Text-only tasks can prioritize DeepSeek. Image-bearing tasks automatically skip DeepSeek and switch to KimiCoding, which supports multimodal.

That's why AgentGate later added Vision-aware routing.

---

Text goes to DeepSeek, images go to KimiCoding

Now, a usage path I'm fairly confident about is:

Codex text tasks go to DeepSeek.
Codex image/multimodal tasks go to KimiCoding.

This experience is much more natural than manual switching.

Because I don't have to think every time:

Does this request have images? Can DeepSeek handle it? Do I need to switch providers manually? Do I need to change config files? Do I need to change the model name again?

These should be handled by the tool.

So AgentGate checks whether the request contains images during routing.

If it's pure text, it can go to DeepSeek. If it includes images, it skips providers that don't support Vision and automatically goes to a multimodal provider like KimiCoding.

This feature sounds like a technical detail.

But in real use, it solves an attention problem.

Because I'm supposed to be writing code.

I don't want to stop mid-task to think about which provider to use this time.

A good local tool should absorb as many of these decisions as possible.

---

Later, I also built a transparent proxy

Initially, protocol conversion was needed because Codex and DeepSeek protocols differ.

But as I worked, I found:

Not all requests need conversion.

In some cases, the client and upstream provider already use the same protocol.

For example, Chat Completions to Chat Completions. Or a provider that natively supports the protocol.

In such cases, forcibly splitting and reassembling adds risk.

So AgentGate includes both protocol conversion and transparent proxy.

Transparent proxy means:

Don't modify the request body if you don't have to.

Only do the necessary things:

Replace the target address. Inject the provider API key. Handle model mapping. Log requests. Do local authentication. Failover when necessary.

Pass through the request and response as-is as much as possible.

This is important for stability.

Because the more protocol conversion, the more places things can go wrong.

Use transparent proxy when possible. Only convert when necessary.

This is also a principle I increasingly value when building tools:

Don't complicate simple things just to look capable.

Tools should shield users from complexity, not create new complexity.

---

Smart switching isn't for show, it's to reduce interruptions

AgentGate later added Provider Chain and smart switching.

This feature wasn't for aesthetics either.

It's because daily use of AI coding tools often encounters instability.

For example:

A provider is rate-limited. A model times out. An interface returns 5xx. A model doesn't support the current input. A service is temporarily unavailable.

If users have to switch manually every time, it's exhausting.

Especially since AI coding tasks aren't usually simple Q&A.

It might be reading files. Understanding project structure. Analyzing problems. Generating modification plans. Executing multi-step tasks continuously.

If it breaks mid-way due to provider issues, it severely impacts the experience.

So I wanted AgentGate to handle some of this automatically.

For example:

If provider A fails, try provider B. If a provider doesn't support images, don't send image requests to it. If a provider fails repeatedly, put it in cooldown. Different protocols can have different route profiles. Codex, Claude Code, and OpenCode can each have their own routing chains.

The goal isn't "more features."

It's to make the workflow more stable.

What really affects efficiency in AI coding tools isn't often a few seconds faster on a single response.

It's whether the tool can reliably support continuous work.

---

Currently verified stable paths

Here are the paths I've verified and am fairly confident about:

Scenario	Routing	Status
Codex → AgentGate → DeepSeek	Responses API to Chat Completions	Verified
Codex text tasks → DeepSeek	Protocol conversion	Verified
Codex image/multimodal tasks → KimiCoding	Vision-aware smart switching	Verified
Skip DeepSeek when images are not supported	Vision routing	Verified
KimiCoding as Vision provider	Handles multimodal requests	Verified
Chat Completions client → AgentGate	Transparent proxy	Verified

This path is clear to me now.

I didn't build AgentGate to make an abstract "AI gateway."

I built it because of a very specific need:

I like Codex, but I want to use DeepSeek.

Then I hit an even more specific problem:

DeepSeek doesn't support multimodal, so image requests need to automatically switch to KimiCoding.

Only later did it evolve into:

Protocol conversion. Transparent proxy. Multi-provider management. Smart switching. Request logging. Client configuration management.

These features weren't brainstormed from the start.

They grew out of real usage problems.

---

This project also made me rethink "real needs"

Earlier, I wrote an article about whether a need is worth pursuing, based on whether it's truly painful, frequent, close to money, whether it distracts, and whether it's the right stage.

AgentGate is a great example for me.

Its need wasn't imagined.

I actually use AI to write code every day. I really like Codex's experience. I really want to use DeepSeek. I really hit protocol incompatibility. I really hit DeepSeek not supporting multimodal. I really don't want to manually switch providers every time. I really need request logs to diagnose issues.

These problems are specific and frequent enough.

So I was willing to turn it into a tool.

This is different from many "seemingly useful" needs.

Some needs just sound reasonable.

But you might not actually use them daily. You might not be willing to invest time. You might not be able to clearly state which specific problem they solve.

AgentGate's origin wasn't like that.

From the start, it was clear:

I want Codex to use DeepSeek. I want DeepSeek, which doesn't support images, to automatically step aside. I want image requests to go to KimiCoding. I want to reduce configuration and switching costs in AI coding.

The more specific the problem, the easier the product converges.

---

Boundaries matter too

Another thing I care about with AgentGate:

It's not a replacement for Codex.

Nor a replacement for Claude Code. Nor OpenCode. Nor a new IDE.

It's just a local gateway.

Codex remains Codex. Claude Code remains Claude Code. OpenCode remains OpenCode.

AgentGate only handles the connection between them and providers.

This boundary must be maintained.

Because once a tool's boundaries are unclear, it easily becomes bloated.

Today you want model switching. Tomorrow a chat interface. The day after an IDE. Then a plugin marketplace, team management, cloud sync, workflow platform.

Each direction seems valuable.

But if you do everything, you might end up with nothing sharp.

So I'm very restrained about AgentGate's positioning:

A local model gateway and provider switching tool.

It solves connection, conversion, routing, logging, and configuration issues.

It doesn't redefine AI coding tools.

With clear boundaries, the project is less likely to spiral out of control.

---

Open-sourcing is just the beginning of real validation

AgentGate is now open source.

But I don't think that means it's done.

More accurately, it's entering the next round of validation.

Because my own usage only represents one scenario.

Others might primarily use Claude Code. Others might use OpenCode. Others might connect to OpenRouter. Others might use a self-hosted OpenAI-compatible interface. Others might care more about cost. Others might care more about stability. Others might care more about multimodal. Others might care more about request logs and diagnostics.

These scenarios will in turn validate AgentGate's boundaries and capabilities.

Which capabilities are universal. Which are just my habits. Where it's not simple enough. Where configurations are too complex. Which error messages are unclear. Which providers need further adaptation.

This is also a product path I'm increasingly comfortable with:

First solve your own real problem. Then open-source it to get real feedback. Then continuously refine based on feedback.

Don't assume you have everything figured out from the start.

Many products aren't planned; they're refined through real use.

---

Final thoughts

For me, AgentGate isn't just a small open-source tool.

It's more like a real solution distilled from my recent experience with AI coding tools.

It started with:

I like Codex, but I want to use DeepSeek.

Then it became:

DeepSeek doesn't support multimodal, so let image requests automatically go to KimiCoding. Different protocols aren't compatible, so do protocol conversion. Don't mess with requests that can pass through directly, so do transparent proxy. Providers fail, so do smart switching. Problems are hard to diagnose, so do request logging. Client configuration is troublesome, so do one-click configuration.

It didn't start from a grand concept.

It started from a small, specific, recurring problem.

This reinforces what I increasingly believe:

Good tools don't have to be big from the start.

They can first solve a real bottleneck. First make it usable for yourself. Then gradually verify if others need it too. Finally, keep refining based on real usage.

That's how AgentGate came to be.

I like Codex. I want to use DeepSeek. I don't want to be stuck by protocols. I also don't want to manually switch to KimiCoding every time because DeepSeek doesn't support multimodal.

So I built a local gateway.

It may not be complex, but it solves problems I really encounter every day.

For someone building products, that might be the best starting point.