AI Coding Tools: How I Actually Use OpenRouter, Kimi Code, and Continue.dev
Table of Contents
I use multiple AI coding tools. That sounds like overkill until you realize that none of them is good enough at everything to be the only one.
This is not a benchmark. I do not have scores or completion rates. It is an opinion about where each tool fits in my workflow, based on what I actually use and what I actually stopped using.
Kimi Code for Infrastructure Reasoning (And Its Limits)
Kimi Code is the tool I reach for when I need to understand something across many files. Helm charts, Terraform modules, Kubernetes manifests, multi-service repositories. The context window and terminal integration make it useful for infrastructure work in a way that IDE plugins are not.
I use it for:
- Debugging across multiple files.
- Reviewing Terraform or Helm for mistakes.
- Writing scripts that touch several services.
- Anything where I would otherwise be grepping and context-switching.
The agent mode is also genuinely useful for mechanical tasks: rename this variable across files, add error handling to these functions, run tests and report failures. I do not let it make unchecked changes to production configs. I learned that the hard way when it suggested deleting a namespace I actually needed. I caught it because I was watching. If I had run it with auto-accept, I would have had a bad afternoon.
Where Kimi Code falls short is speed. It is not fast. A simple autocomplete takes seconds because it is running a full model call. For quick typing assistance, it is the wrong tool. I also stopped using it for Go code because it kept suggesting Python patterns. The model training shows.
OpenRouter for Flexibility (And the Provider Chaos)
OpenRouter is the frictionless one in terms of provider access. I can switch between models without changing my setup. One API key, many models. For day-to-day Python, Go, or TypeScript work, it saves time.
Where it falls short is consistency. Different models have different strengths. If I need to understand why a deployment is failing, I might need to try several models before finding one that gets it. I once spent ten minutes accepting suggestions for error handling before realizing the real problem was in a completely different file that the model had never seen.
I use it for:
- Autocomplete through Continue.dev.
- Small functions and boilerplate.
- Inline suggestions while I write code.
- Experimenting with new models as they come out.
What I stopped using it for: anything that requires understanding the system. It is a typing assistant, not an architect.
The annoyances: it sometimes suggests code that looks right but uses deprecated APIs. I accepted a suggestion for kubectl exec with a syntax that worked in v1.20 but not in v1.28. It passed my mental check because it looked familiar. That cost me twenty minutes of debugging.
Continue.dev for Local Control (And the Setup Tax)
Continue.dev is the tool I use when I want control. It is open source, it supports local models through Ollama, and I can configure exactly which model handles which task. That makes it the best option when I do not want code leaving my environment.
It is also the most configurable. I can add custom context providers and slash commands. That flexibility is great, but it means Continue.dev requires more setup than the others. I spent an evening configuring it to use my local Ollama instance with a custom system prompt. It worked, but the time investment was real.
I use it for:
- Local or self-hosted models.
- Experimenting with new providers through OpenRouter.
- Situations where code privacy matters.
What I stopped using it for: quick tasks. The setup is too heavy for “help me write this function.” I also found that local models are not good enough for complex reasoning yet. My Ollama instance with Llama 3.1 8B is fine for autocomplete but struggles with multi-file Terraform reviews. That is not Continue.dev’s fault. It is the model.
How I Actually Choose (Updated for Reality)
| Task | Tool | Why |
|---|---|---|
| Debugging multi-file infrastructure | Kimi Code | Context window matters |
| Writing or refactoring code in IDE | OpenRouter via Continue.dev | Speed and frictionlessness |
| Local/self-hosted model | Continue.dev | Privacy and control |
| Terminal-based investigation | Kimi Code | Can run commands |
| Quick autocomplete | OpenRouter via Continue.dev | It is already there |
| Privacy-sensitive code | Continue.dev + local model | Code does not leave my machine |
| Complex reasoning with local model | None yet | Local models are not ready |
| Production config changes | None | I do not let AI touch production unattended |
The right answer is often “use more than one.” These tools complement each other more than they compete. But the wrong answer is “let any of them work unsupervised.”
What I Actually Pay
| Tool | Cost | Worth it? |
|---|---|---|
| Kimi Code | ~$20/month | Yes, for infrastructure work |
| OpenRouter | Variable (~$15/month) | Yes, for daily coding and experiments |
| Continue.dev | Free (open source) | Yes, but with setup cost |
| My time debugging bad suggestions | ~2 hours/month | No, but unavoidable |
The hidden cost is the time I spend verifying suggestions. I do not accept AI code blindly anymore. The namespace incident taught me that. Now I read every suggestion, especially for infrastructure code. That slows me down, but it is faster than rebuilding a cluster.
What I Stopped Doing
I stopped using AI for:
- Production Terraform applies. I review the plan manually.
- Kubernetes config changes without a second human review.
- Security-related code. AI suggestions for auth logic are often subtly wrong.
- Anything where the cost of being wrong is high.
I still use AI for:
- Boilerplate and scaffolding.
- Debugging and log analysis.
- Learning new APIs.
- Writing tests.
The line is “can I verify this quickly and cheaply?” If yes, AI helps. If no, I do it myself.
Conclusion
Kimi Code, OpenRouter, and Continue.dev are not interchangeable. Kimi Code is for reasoning across files. OpenRouter is for speed and model variety inside the IDE. Continue.dev is for control and privacy.
Pick the tool that matches the task. Do not force one tool to do everything. And never let any of them work unsupervised on infrastructure that matters.
The best AI coding setup is the one where you know exactly what each tool is good at, what it is bad at, and when to stop using it.