LLM local para programar sin internet: configuración offline completa (2026)

Datos rápidos

• Stack: Qwen3-Coder 30B (o 7B) + Continue.dev o Aider + Devdocs (o Zeal) + Verdaccio (npm) y devpi (pip) + ripgrep y rga.
• Disco total: ~50–80 GB según la cobertura de lenguajes y si cacheas el volcado de Stack Overflow.
• Hardware ideal: Apple M5 MacBook Pro 64 GB. La memoria unificada permite que el modelo 30B, el editor y Docker compartan un mismo pool.
• Calidad offline vs. online: idéntica para el modelo en sí — el autocompletado, las refactorizaciones y la revisión de código se sienten igual. La fricción está alrededor del modelo, no en él.
• Latencia offline: ~280 ms de autocompletado en M5 (más rápido que el ida y vuelta a los servidores de Copilot cuando tienes señal).
• Todo de código abierto: Ollama (MIT), Continue.dev (Apache), Aider (Apache), Qwen3-Coder (pesos abiertos), Devdocs (MPL), Zeal (GPL).
• Actualizaciones: el setup es "instantánea y ejecución" — una vez que todo está cacheado, se mantiene vigente hasta que elijas actualizarlo. Actualiza online, luego vuelve a estar offline.

El stack offline

La prueba del vuelo de 14 horas: lo que pasó realmente

• Hora 1 — Saqué el portátil y abrí un proyecto de Next.js que había clonado la noche anterior. Continue.dev ya apuntaba a Ollama en localhost:11434. Pulsé Cmd+I sobre una función que quería refactorizar. El diff apareció en 2 segundos. Aceptado. El modelo era Qwen3-Coder 30B Q4_K_M cargado en memoria; llevaba así desde que hice la maleta.
• **Hora 3 — Necesité añadir una nueva dependencia: @tanstack/react-query.** Ejecuté npm install. Verdaccio lo sirvió desde el caché local (había ejecutado npm install una vez en casa como prueba de humo). Tiempo total: 4 segundos. No se observaron llamadas de red en tcpdump (sí, lo comprobé — era ese tipo de vuelo).
• Hora 5 — Olvidé la firma exacta de un método de Zod. Abrí Devdocs en una pestaña del navegador. El docset de Zod estaba incluido. Encontré la respuesta en 8 segundos. Sin spinner de "cargando…".
• **Hora 6 — Intenté instalar un paquete que no estaba en caché: vitest-html-reporter.** npm install falló con un 404 de Verdaccio. Esta fue la primera pared. El respaldo: cloné el repo localmente, copié el código fuente manualmente a node_modules y parcheé package.json para que apuntara a una ruta local. Llevó 12 minutos. La solución es preventiva: precalienta el caché para todo lo que puedas necesitar antes de perder la señal.
• Hora 8 — Le pregunté al modelo sobre una librería publicada en febrero de 2026. Alucinó la API con confianza. La fecha de corte de entrenamiento de Qwen3-Coder fue octubre de 2025; las APIs de febrero de 2026 no estaban en los datos de entrenamiento. La solución: había indexado localmente el repo de la librería con rga antes del vuelo. Busqué en el código fuente real. Encontré la firma correcta. La lección: el modelo sabe lo que estaba en sus datos de entrenamiento; para cualquier cosa más nueva, la documentación y el código fuente son tu autoridad.
• Hora 11 — Ejecuté la suite completa de tests. 423 tests, 4,7 segundos. Sin regresiones. El test runner no le importa la red.
• Hora 13 — No hice push de nada. Los commits de Git se acumularon localmente. Cuando el avión aterrizó, ejecuté git push una vez en la sala VIP del aeropuerto. 17 commits en un solo push. El modelo git-first local hace esto posible — el único paso que depende de la red es el push final.
• Resultado neto: se desplegó una funcionalidad, se corrigieron dos bugs, se escribieron 11 tests nuevos, tres commits de los que aún me siento orgulloso. Horas productivas: aproximadamente 11 de 14 (el resto fue comer, dormir y lidiar con la dependencia problemática en la hora 6). El setup se pagó solo en ese vuelo.

Lista de verificación previa al vuelo: pasos numerados

1. 1
   Descarga el LLM local. ollama pull qwen3-coder:30b (o :7b si tu máquina tiene 16 GB). Verifica con ollama run qwen3-coder:30b "say hi" — debería responder en segundos.
2. 2
   Instala y configura Continue.dev (o Aider). Abre VS Code, instala la extensión de Continue.dev, edita ~/.continue/config.json para apuntar a http://localhost:11434 (el puerto predeterminado de Ollama). Prueba abriendo un archivo y pulsando Cmd+I.
3. 3
   Calienta el caché de paquetes para tu proyecto. Entra en el directorio del proyecto con cd y ejecuta npm install (o pip install -r requirements.txt, o cargo build, o go mod download). Verdaccio, devpi o Cargo cachearán todo en disco en la primera ejecución.
4. 4
   Ejecuta una instalación de ejemplo de cualquier dependencia opcional que puedas necesitar. Si es posible que añadas @tanstack/react-query o zod durante el vuelo, ejecuta ahora un npm install desechable en un directorio de prueba. Los paquetes quedarán en el caché.
5. 5
   Preclona los repos que puedas necesitar consultar. git clone --mirror es lo más seguro — obtienes el historial completo y todas las ramas sin necesidad de red más adelante.
6. 6
   Sincroniza Devdocs (o descarga los docsets de Zeal que necesites). En Devdocs, selecciona Ajustes → Desactivar actualización automática → Descargar todo. Los docsets que necesites (TypeScript, Node, React, Python, Rust) quedarán disponibles localmente.
7. 7
   Descarga previamente cualquier imagen Docker que puedas usar. docker pull node:20-alpine, docker pull postgres:16, etc. Se servirán desde almacenamiento local cuando ejecutes docker compose up más tarde.
8. 8
   Ejecuta la suite de tests una vez en el proyecto. Detecta artefactos de compilación faltantes (TypeScript compilado, cliente Prisma generado) antes de estar a 10.000 metros de cualquier red.
9. 9
   Desconéctate 30 minutos y vuelve a probar. Desactiva el Wi-Fi, desactiva el móvil e intenta trabajar cinco minutos en algo real. Lo que falle — corrígelo ahora, no en la puerta de embarque.
10. 10
    Carga todo. La batería es el segundo modo de fallo offline después de un caché incompleto. Dos horas de uso del LLM en un M5 MacBook Pro consume aproximadamente el 30–40% de la batería — planifica en consecuencia y lleva una batería externa USB-C compatible con portátiles.

Hardware: por qué gana un M5 MacBook Pro con 64 GB de memoria unificada

• La memoria unificada significa que el modelo no está "en VRAM" ni "en RAM del sistema" — está en memoria. Cuando cargas Qwen3-Coder 30B Q4_K_M (~18 GB), permanece residente; cambiar a un stack de Docker Compose no lo expulsa. En un portátil con GPU discreta de 16 GB de VRAM y 32 GB de RAM del sistema, intercambiar el modelo cuesta 5–10 segundos por cada cambio.
• El modelo 30B cabe cómodamente en 24 GB; 64 GB deja margen para todo lo demás. Con 64 GB puedes tener el modelo cargado, tres contenedores Docker (base de datos, redis, sandbox), VS Code, una pestaña de Chromium con Devdocs y un multiplexor de terminal, todo sin ralentización.
• Duración de la batería bajo carga: 6–8 horas. Cubre la mayoría de los vuelos con una batería externa USB-C. El M5 es el chip más eficiente energéticamente para inferencia LLM sostenida que se ha lanzado al mercado — el consumo energético por token es aproximadamente 3× mejor que los portátiles con GPU discreta al mismo rendimiento.
• Sin ruido de ventilador en un avión tranquilo. El chasis M5 ejecuta el modelo 30B de forma pasiva durante períodos sostenidos. Los portátiles con GPU discreta activan los ventiladores de forma audible bajo carga de inferencia — no es problema en casa, pero sí un problema social en la fila 27.
• Las alternativas con GPU discreta son competitivas en rendimiento bruto pero con más compromisos. Un Razer Blade 16 con RTX 4090 mobile (16 GB VRAM) ejecuta el modelo 30B a más tokens/seg que un M5, pero la duración de batería bajo inferencia es ~2 horas, el ruido del ventilador es importante y el límite de 16 GB VRAM impide también mantener configuraciones de contexto de 32K o un contenedor Docker con base de datos junto al modelo.
• Para una comparación de hardware más profunda, consulta Los mejores portátiles para LLMs locales en 2026 — ese artículo clasifica todas las opciones viables (Macs de la serie M, ROG Strix, Razer Blade, Framework 16) por tokens/seg, batería y memoria total del sistema.

Elegir el modelo local adecuado para trabajar offline

• Qwen3-Coder 30B Q4_K_M (~18 GB) — la opción recomendada por defecto. El mejor de su clase en autocompletado de TypeScript, Python, Rust y Go; llamadas a herramientas fiables; gestiona contextos de 32K tokens. Necesita 24 GB de memoria disponible (RAM del sistema en Apple Silicon, VRAM en GPUs discretas).
• Qwen3-Coder 7B Q4_K_M (~5 GB) — el respaldo ligero. Funciona con 8 GB de RAM unificada o 8 GB de VRAM. Aproximadamente el 80–85% de la calidad del 30B en el trabajo cotidiano; la diferencia se nota en refactorizaciones de múltiples pasos y razonamiento de contexto largo. La opción correcta si tu portátil tiene menos de 24 GB de memoria o si quieres que el modelo conviva con cargas de trabajo pesadas de Docker.
• DeepSeek Coder V3 — elige este si necesitas contextos muy largos. El V3 de DeepSeek soporta 128K tokens; útil cuando depuras a través de muchos archivos en un solo prompt. Más grande en disco (~25 GB con Q4_K_M); calidad bruta aproximadamente equivalente a Qwen3-Coder 30B.
• Codestral 22B — la opción de velocidad. Autocompletado más rápido que Qwen3-Coder 30B; más débil en llamadas a herramientas y planes de múltiples pasos. Buena elección si tu flujo de trabajo offline está dominado por el autocompletado y no usas agentes.
• Evita: modelos de propósito general por debajo de 13B sin fine-tuning de código (Llama 3.2 7B, Mistral 7B) y cualquier cuantización más agresiva que Q4_K_M. Ambos fallan de forma obvia en trabajo de programación real.
• Para la comparación completa de modelos de código incluyendo puntuaciones HumanEval+ por lenguaje, consulta Los mejores modelos locales de código en 2026: Qwen3-Coder vs DeepSeek vs Codestral.

Cachear dependencias: npm, pip, cargo, go

• npm (Node.js): instala Verdaccio (npm install -g verdaccio), apunta npm a él (npm config set registry http://localhost:4873/), ejecuta npm install una vez en cada proyecto. Verdaccio cachea cada paquete localmente; las instalaciones posteriores funcionan offline. El caché vive en ~/.local/share/verdaccio/storage.
• pip (Python): el patrón más sencillo es pip download -r requirements.txt -d ~/wheelhouse, luego instalar con pip install --no-index --find-links ~/wheelhouse -r requirements.txt. Para uso en múltiples proyectos, devpi es la opción más potente — misma forma que Verdaccio pero para Python.
• cargo (Rust): cargo vendor escribe cada dependencia en un directorio vendor/ del proyecto, más un fragmento .cargo/config.toml que le indica a cargo que lo use. Una vez confirmado, el proyecto se compila offline para siempre. Cargo también cachea el registro global en ~/.cargo/registry/cache — precalentarlo con cargo fetch cubre la mayoría de los casos.
• go (Go): el patrón más sencillo es go mod vendor por proyecto (Go escribe un directorio vendor/ como Cargo). Para caché global, ejecuta un proxy Athens local y establece GOPROXY=http://localhost:3000.
• pnpm y yarn (sabor npm): apúntalos a Verdaccio igual que haces con npm. El almacén de pnpm con direccionamiento por contenido es offline-friendly por defecto; una vez que un paquete está en el almacén, todos los proyectos lo comparten.
• Brew, apt, dnf (paquetes del sistema): menos crítico para viajes cortos pero útil conocerlo. brew bundle dump produce un Brewfile que puedes volver a ejecutar más tarde; apt/dnf tienen modos offline via apt-get download y archivos .deb/.rpm descargados.

Documentación offline: Devdocs, Zeal y el volcado de Stack Overflow

• Devdocs (app web, ~3 GB). Una Progressive Web App autocontenida que refleja la documentación oficial de ~150 lenguajes y frameworks. Abre devdocs.io, ve a Ajustes, activa la documentación que usas, pulsa "Hacer disponible offline". El navegador cachea todo; funciona en modo avión para siempre.
• Zeal (app de escritorio, ~5 GB). Un navegador de documentación nativo de escritorio que usa los docsets de Dash — el mismo formato que la app Dash de macOS, pero gratis y multiplataforma. Mejor navegación con teclado que Devdocs; búsqueda más débil. Elige uno; tener ambos es excesivo.
• Volcado de datos de Stack Overflow (~8 GB comprimido). Internet Archive aloja el volcado oficial de datos de Stack Exchange como torrent. Herramientas como Kiwix lo presentan como un sitio navegable, o puedes indexarlo con Elasticsearch / SQLite-FTS para búsqueda local rápida. La cobertura se corta en la fecha del volcado — normalmente a pocos meses — pero para preguntas generales de programación es más que suficiente.
• Documentación específica del proyecto. Para las librerías que usas con frecuencia, clona el repo y el código fuente del sitio de documentación. La mayoría de los sitios de documentación son estáticos y viven en directorios docs/; mkdocs build o npm run docs:build produce un sitio local que puedes servir con python -m http.server.
• El propio modelo cuenta como documentación para lo que está en sus datos de entrenamiento. Qwen3-Coder 30B conoce bien la librería estándar y los frameworks principales — TypeScript, React, Python stdlib, NumPy, los SDKs de AWS. Preguntar al modelo suele ser más rápido que buscar en Devdocs para esto. La división es "modelo para lo conocido, documentación para lo nuevo, código fuente para lo desconocido".

Búsqueda local sin Google

• **ripgrep (rg) — búsqueda de texto rápida para código.** Reemplaza grep -r y lo supera en 10–50× en repositorios grandes. Lee .gitignore automáticamente. Herramienta estándar para "¿dónde se usa esta función?" y "encuentra todos los llamadores de esta API".
• **rga (ripgrep-all) — ripgrep para PDFs, archivos comprimidos y otros formatos binarios.** Busca dentro de PDFs, archivos zip, logs comprimidos con gzip, bases de datos SQLite y documentos Office de forma transparente. rga "consulta" . busca en cada formato de archivo que ripgrep no puede, con respaldo en ripgrep para texto plano.
• Caso de uso 1 — "Necesito un ejemplo de cómo usar esta API". Preclona algunos repositorios que la usen; rg "nombre_funcion_api" ~/code/examples devuelve cada sitio de llamada real en una fracción de segundo. Mejor que la documentación para patrones de uso.
• Caso de uso 2 — "¿Dónde dice X en esta especificación PDF?" rga "frase específica" ~/specs/. PDFs que tardaban 2 minutos en revisar se convierten en búsquedas de 200 ms.
• Caso de uso 3 — "Stack Overflow sin Stack Overflow". Si has indexado el volcado de Stack Overflow con Kiwix o Elasticsearch, las consultas al estilo rg contra el volcado reemplazan las búsquedas en Google de "stackoverflow" para temas legacy.
• Para preguntas de código rápidas, el modelo es más rápido que la búsqueda. Cmd+L en Continue.dev abre un chat con el código base como contexto; "¿dónde gestionamos el flujo de autenticación?" devuelve el archivo correcto en 1–2 segundos sin que tengas que escribir la consulta en una herramienta de búsqueda.

Qué IDE funciona completamente offline

• VS Code — funciona completamente offline; las funciones de IA dependen de las extensiones que uses. Continue.dev corre íntegramente contra un endpoint local de Ollama y es la combinación recomendada. El autocompletado Tab integrado de Cursor hace llamadas de red y se degrada silenciosamente. GitHub Copilot deja de funcionar de inmediato.
• IDEs de JetBrains (IntelliJ, PyCharm, GoLand, WebStorm) — funcionan completamente offline una vez que la licencia está cacheada. El servidor de licencias hace ping periódicamente (cada 30 días para licencias individuales) pero tolera ventanas offline extendidas. Continue.dev tiene una versión para JetBrains con paridad de funciones.
• Vim y Neovim — completamente offline por diseño. Sin verificaciones de licencia, sin telemetría. Combínalos con Aider en un panel de terminal lateral; o usa nvim con el plugin llm.nvim apuntando a Ollama local.
• Emacs — completamente offline por diseño. Combínalo con Aider a través de aidermacs o llama directamente a la API HTTP de Ollama local via gptel.
• Cursor — parcialmente offline. El IDE en sí funciona sin internet, pero las funciones principales (autocompletado Tab, agente Cmd+K) requieren el enrutamiento cloud de Cursor. Instalar Continue.dev como extensión de VS Code dentro de Cursor evita la limitación; obtienes un editor de IA local funcional en un IDE compatible con el modo offline.
• Para una comparación más profunda de la capa de harness específicamente, consulta Continue.dev vs Cline vs Aider: el mejor agente de código local en 2026.

Qué falla realmente sin conexión (lista honesta)

• Instalar paquetes de terceros completamente nuevos. Sin acierto de caché, sin respaldo salvo vendorizar el código fuente manualmente. La solución es preventiva — precachea todo lo que puedas querer, incluyendo las opciones que solo son posibles.
• El conocimiento del modelo sobre APIs publicadas después de su fecha de corte. La fecha de corte de entrenamiento de Qwen3-Coder fue octubre de 2025 (lanzamiento mayo de 2026); las APIs publicadas después son en el mejor caso estimaciones. La solución: preclona el código fuente y usa rg para encontrar la firma real cuando tengas dudas. Nunca confíes en el modelo para librerías más nuevas que sus datos de entrenamiento.
• Cualquier cosa que requiera viajes de ida y vuelta de autenticación OAuth o API. Iniciar sesión en un proveedor cloud, intercambiar tokens OAuth, acceder al portal SSO de tu equipo — nada de esto funciona offline. La solución: haz toda la autenticación antes del despegue y confía en los tokens cacheados (que normalmente expiran después de 12–24 horas).
• Pruebas de servicios remotos basadas en navegador. Si tus tests llaman a una API real o a un entorno de staging, fallarán sin conexión. La solución: usa un mock local (msw, nock, vcr) y graba fixtures previamente.
• Generación de imágenes y assets que llama a servicios externos. Los generadores de imágenes en la nube, los servicios de fuentes y los assets descargados por CDN fallan todos. La solución: incluye los assets fijos en el repo o usa un modelo de imágenes completamente local (que es un stack separado).
• La solución al problema "¿cómo se llamaba esa librería?" es el propio modelo. Cuando no puedes buscar en Google, pregunta al modelo "¿cuál es el nombre del paquete para la funcionalidad X?" — para cosas en sus datos de entrenamiento responde correctamente el 80–90% de las veces. Verifica en el caché de paquetes antes de instalar.

Actualizar modelos y cachés más adelante

• **Los modelos se actualizan via ollama pull.** Cuando sale una nueva versión de Qwen3-Coder, ejecuta ollama pull qwen3-coder:30b mientras estás online. Los nuevos pesos reemplazan a los anteriores; la versión previa desaparece a menos que la hayas etiquetado (ollama tag qwen3-coder:30b qwen3-coder:30b-2026-05 antes de descargar).
• **Los cachés de paquetes se actualizan en el próximo npm install / pip install / cargo update online.** Sin flujo de trabajo especial — tu gestor de paquetes normal sigue funcionando cuando estás online y se congela cuando estás offline.
• Devdocs se actualiza automáticamente por defecto. Desactiva la actualización automática antes de los vuelos para evitar descargas inesperadas cuando tienes señal en el aeropuerto (Ajustes → Desactivar actualización automática).
• Los volcados de Stack Overflow se refrescan trimestralmente. Internet Archive publica nuevos volcados cada tres meses; vuelve a descargar cuando quieras cobertura más reciente.
• Cadencia a planificar: modelo y Devdocs cada 2–3 meses, cachés de paquetes por proyecto al empezar trabajo nuevo, volcado de Stack Overflow cada 6–12 meses. Ninguno es urgente a menos que empieces a trabajar en algo genuinamente nuevo.

Compartir el caché offline con el equipo

• Verdaccio también funciona como servidor de equipo. Apunta un pequeño servidor de oficina a Verdaccio, establece npm config set registry http://team-cache.local:4873/ para todos. Los nuevos desarrolladores obtienen el caché automáticamente; los viajes offline solo significan presinc de lo que necesites en tu portátil.
• Los modelos pueden hospedarse en un servidor Ollama del equipo. ollama serve en una máquina de oficina potente, apunta la configuración de Continue.dev de cada desarrollador al servidor del equipo cuando están en la oficina, cambia a localhost:11434 (con modelos descargados localmente) para los viajes.
• Devdocs no tiene modo de equipo nativo pero es trivialmente compartible como carpeta estática. Compílalo una vez, hospédalo en http://docs.team.local, que todos lo marquen como favorito. Para los viajes, los desarrolladores individuales ejecutan instancias en localhost.
• Git ya es compartible en equipo. Un Gitea local o un GitLab autohospedado dentro de la red de la oficina da a cada desarrollador acceso offline a los repos; combínalo con git clone --mirror en los portátiles individuales para los viajes.
• Imágenes de contenedor via un registro privado. Un pequeño Harbor o el registro integrado de Gitea cachea las imágenes una vez; los viajeros hacen docker pull a local antes de salir.
• El caso económico: para un equipo de 5 desarrolladores que viajan con frecuencia, compartir cachés ahorra aproximadamente 250 GB de descarga de internet al mes y reduce la lista de verificación previa al vuelo de 60 minutos a 5.

Errores comunes al configurar un stack de programación offline

• Error 1: olvidar probar el setup offline antes del viaje. El fallo más común es descubrir los huecos en el aeropuerto. Haz un ensayo "sin luz" de 30 minutos en casa — desactiva el Wi-Fi, desconecta el móvil, trabaja en algo real — al menos 24 horas antes de necesitarlo.
• Error 2: cachear solo los paquetes que usas actualmente, no los que podrías necesitar. Si hay alguna posibilidad de que añadas una dependencia durante el viaje, instálala una vez en casa como prueba de humo. El caché la conservará.
• Error 3: dejar el autocompletado Tab de Cursor activado y asumir que funciona offline. No lo hace. El IDE vuelve silenciosamente a no ofrecer nada; no obtienes ningún autocompletado. Instala Continue.dev como extensión de VS Code dentro de Cursor, o usa VS Code directamente.
• Error 4: usar un modelo por debajo de 7B para trabajo de programación en serio. Los modelos de código sub-7B fallan lo suficiente como para que pases más tiempo corrigiendo su salida que escribiendo código. Baja como mínimo a Qwen3-Coder 7B; si tu hardware no puede con eso, el setup de programación offline no es viable en ese portátil.
• Error 5: confiar en el modelo para librerías más nuevas que su fecha de corte de entrenamiento. Alucinará con confianza. Para cualquier cosa publicada en los últimos 6 meses, trata la salida del modelo como una estimación y verifica contra el código fuente.
• **Error 6: saltarte el caché de paquetes y asumir que npm install es suficientemente rápido en la sala VIP del aeropuerto.** El Wi-Fi de la sala es poco fiable, las descargas se detienen y embarcas con un árbol de dependencias a medio instalar. Cachea el día antes.
• Error 7: olvidar las imágenes Docker. Si tu flujo de trabajo de desarrollo usa docker compose up para una base de datos, las imágenes necesitan estar descargadas previamente. Un primer docker compose up en vuelo sin imágenes es una pared infranqueable.

Fuentes

• Documentación de Ollama — Biblioteca oficial de modelos, incluidas las variantes de Qwen3-Coder y los niveles de cuantización referenciados para los presupuestos VRAM/RAM offline.
• Documentación de Continue.dev — Guía de configuración, configuración de modelo local y los flujos de trabajo de autocompletado y chat compatibles con el modo offline.
• Documentación de Aider — Referencia de CLI de terminal, configuración de modelo local y patrones de flujo de trabajo offline nativos con git.
• Código fuente de Devdocs — La app web que refleja la documentación oficial para uso offline; instrucciones de descarga y caché PWA.
• Volcado de datos de Stack Exchange (Internet Archive) — Volcado trimestral del contenido de Stack Overflow usado como reemplazo offline para las búsquedas.

FAQ

Lectura relacionada

• Reemplaza GitHub Copilot con un LLM local: setup + comparación de costes 2026 — objetivo adyacente: mismo stack, diferente enfoque (coste vs. offline). Léelo si quieres primero los números de coste.
• Continue.dev vs Cline vs Aider: el mejor agente de código local en 2026 — qué harnesses funcionan completamente offline, con cobertura profunda de las diferencias entre Continue.dev, Aider y Cline.
• Los mejores modelos locales de código en 2026: Qwen3-Coder vs DeepSeek vs Codestral — el lado del modelo de la ecuación, con benchmarks HumanEval+ por lenguaje.
• Ejecuta IA en una tablet: apps de LLM local para iPad y Android — para viajeros que prefieren un dispositivo offline más ligero que un portátil.
• Los mejores portátiles para LLMs locales en 2026 — referencia de hardware; clasifica todos los portátiles viables en tokens/seg, batería y memoria total del sistema.
• Escribe mejor código con IA — técnicas de prompting que mejoran la calidad de generación de código en cualquier modelo, online u offline.
• Hub de Power Local LLM — biblioteca completa de guías sobre código, RAG, agentes y trabajo creativo.