No nos acostumbramos a programar en Windows, así que montamos Linux por dentro

Setup probado en Windows 11 con WSL2 (distro Ubuntu por default). Todo lo descrito aquí lo corrimos nosotros mismos, ningún fabricante nos pidió cubrir estas herramientas ni hubo embargo de por medio.

No es que Windows sea malo para programar. Es que después de años en Linux y macOS, la mano no se acostumbra. Así que en vez de pelearnos con eso, atacamos el problema: metimos Linux por dentro de Windows y probamos varias formas de sacarle jugo.

Esto no es un tutorial a fondo de ninguna herramienta — es el resumen de lo que probamos y cómo nos fue. Si alguna te interesa a detalle, dinos en redes y con gusto hacemos el tutorial completo.

WSL: Linux virtualizado sin salir de Windows

WSL (Windows Subsystem for Linux) nos da un Linux integrado al equipo, corriendo junto a Windows en vez de en una máquina virtual aparte. La razón de usarlo es exactamente esa: programar con una terminal Linux de verdad, sin salir de nuestra máquina de siempre.

La instalación está bien documentada en el tutorial oficial de Microsoft, pero en resumen es abrir PowerShell y correr:

wsl --install

Esto instala Ubuntu como distro por default y deja la app de WSL fijada en la barra de tareas, lista para abrir una terminal con Linux de fondo.

Visual Studio Code apuntando a WSL, no a Windows

Tener la terminal no sirve de mucho si el editor sigue viendo el sistema de archivos de Windows. Para que VS Code trabaje directo sobre los archivos de la instancia de Ubuntu, seguimos el tutorial oficial de WSL + VS Code. En resumen:

1. Instalamos VS Code en Windows.
2. Instalamos la extensión WSL de VS Code.
3. Desde la terminal de WSL, corremos code . sobre la carpeta del proyecto.

Con eso, VS Code abre una ventana conectada a Ubuntu — el editor vive en Windows, pero el código, la terminal integrada y el entorno son Linux.

Claude Code corriendo sobre nuestra instancia de Ubuntu

Con Linux y editor resueltos, el siguiente paso fue no perder tiempo en tareas repetitivas. Instalamos Claude Code directo en la instancia de Ubuntu, con dos caminos posibles:

curl -fsSL https://claude.ai/install.sh | bash

npm install -g @anthropic-ai/claude-code

Nosotros lo instalamos con el script de bash y no tuvimos ningún problema. El resultado: Claude Code editando archivos dentro de Ubuntu y los cambios reflejándose al instante en la ventana de VS Code conectada por WSL.

Modelos locales con LM Studio, para cuando no quieres pagar ni depender de internet

Ya con el flujo de código más rápido, quisimos aprovechar la tarjeta gráfica del equipo y correr modelos de IA en local — sin costo por token y sin depender de conexión. Para esto, instalamos LM Studio, pero esta vez corriéndolo desde Windows directo, para evitar cuellos de botella innecesarios entre capas.

Antes de descargar cualquier modelo, vale la pena pasar por canirun.ai — cortesía de midudev — para tener una estimación de qué modelos aguanta tu equipo. No es un cálculo exacto, así que la recomendación real es probar y quedarte con el que mejor te funcione.

Con el modelo descargado y LM Studio corriendo, ya podíamos pedirle código sin gastar un peso ni depender de internet.

OpenCode + LM Studio: conectar el modelo local a un flujo de agente

Trabajar modelo por modelo desde la interfaz de LM Studio es poco práctico. El siguiente paso fue conectar esos modelos locales a OpenCode para tener un flujo de agente parecido al de Claude Code, pero sin costo. Esta parte sí tiene más pasos — si algo no queda claro, búscanos en redes y lo resolvemos o armamos el tutorial completo.

Primero, exponemos LM Studio como servidor accesible desde fuera de Windows. Desde PowerShell:

lms server start --bind 0.0.0.0

Es importante el --bind 0.0.0.0: sin eso, WSL no puede alcanzar el servidor porque queda atado solo a Windows.

Después, instalamos y configuramos OpenCode dentro de la instancia de Ubuntu siguiendo el tutorial oficial de OpenCode para WSL.

Con ambos corriendo, falta decirle a OpenCode dónde buscar los modelos. Se edita (o se crea) el archivo de configuración:

vim ~/.config/opencode/opencode.json

Y dentro va algo así:

{
  "$schema": "https://opencode.ai/config.json",
  "provider": {
    "lmstudio": {
      "npm": "@ai-sdk/openai-compatible",
      "name": "LM Studio (local)",
      "options": {
        "baseURL": "http://<IP_LM_STUDIO_API>:1234/v1",
        "apiKey": "lmstudio"
      },
      "models": {
        "google/gemma-4-12b": {
          "name": "Gemma 4 - 12b"
        },
        "qwen/qwen3.5-9b": {
          "name": "Qwen 3.5 9b"
        }
      }
    }
  }
}

El id de cada modelo se obtiene desde LM Studio; el name lo defines tú, es solo para identificarlo dentro de OpenCode. Con el archivo guardado, OpenCode ya puede abrir y encontrar los modelos locales sin pasar por Claude ni por ningún servicio de pago.

Extra: la misma tarjeta gráfica, ahora también para macOS

Como plus, probamos combinar el mismo modelo local con una Mac en la misma red, usando LM Studio Link. Suena más complicado de lo que es:

1. Se instala LM Studio en la Mac (asumiendo que ya está configurado y corriendo en Windows).

2. Con la cuenta de LM Studio activa, se activa la opción LM Link desde Windows.

¿Y ahora qué?

Este es el mapa de lo que probamos, no la última palabra. Si programas en Windows y tampoco te acostumbras, WSL sigue siendo el punto de entrada más simple; de ahí para arriba, Claude Code, LM Studio y OpenCode son piezas que se combinan según cuánto quieras gastar y cuánto control quieras tener sobre el modelo.

Si quieres que profundicemos en alguna — instalación paso a paso, comparativa de modelos locales, o el flujo completo de OpenCode — dinos en nuestras redes.

https://www.tiktok.com/@pixavid
https://www.instagram.com/pixavid
https://www.threads.com/@pixavid
https://www.youtube.com/@pixavid-games