De ChatGPT a agentes: qué necesitas entender para empezar hoy

ChatGPT ya no necesita demasiada presentación. Muchísima gente ha probado alguna vez a escribir una pregunta en una caja de texto, esperar unos segundos y recibir una respuesta. Algunos lo utilizan todos los días para trabajar. Otros siguen viéndolo como una especie de Google glorificado que escribe textos más largos.

El salto empieza a parecer bastante mayor cuando sales de ese chat. De repente ves a alguien abrir una terminal, lanzar Codex, Claude Code u OpenCode, decirle que revise un proyecto entero y dejar que el modelo lea archivos, ejecute comandos, busque documentación, modifique código, lance tests y vuelva sobre sus propios errores. Si sigues bajando por el rabbit hole aparecen modelos, providers, APIs, tokens, context windows, MCP, skills, plugins, subagentes, routers, modelos locales, cuantizaciones y una cantidad considerable de gente discutiendo sobre cuál de todas esas piezas es la mejor. Explicado así, empezar a utilizar agentes puede parecer bastante más complicado de lo que realmente hace falta.

Yo también fui entrando en este mundo probando una cosa detrás de otra y durante bastante tiempo mezclaba conceptos que ahora me parecen bastante diferentes. Probaba un modelo porque alguien decía que era mejor, luego otro harness, después una API, OpenRouter y finalmente modelos locales. Con el tiempo fui entendiendo por qué dos personas pueden decir que están utilizando «el mismo modelo» y, aun así, tener experiencias muy distintas: el modelo es sólo una parte de todo lo que lo rodea.

La intención de este artículo es ordenar ese mapa desde el punto de vista de alguien que ya conoce ChatGPT y quiere empezar a utilizar agentes. Quiero explicar las piezas que a mí me costó separar al principio, cómo encajan entre ellas y qué probaría hoy para empezar sin necesidad de aprender antes cómo funciona un transformer, montar infraestructura propia o perseguir cada modelo nuevo que aparece.

De hablar con un chatbot a darle trabajo a un agente

Un chat ya puede hacer bastante. Puedes subirle un documento y pedirle que lo resuma, pasarle una captura para que la interprete, discutir una idea durante una hora o pegarle código para que busque un error. Los productos actuales además han ido incorporando búsqueda web, ejecución de código, análisis de archivos y otras herramientas, así que la frontera entre «chat» y «agente» tampoco es completamente rígida.

La diferencia práctica se nota cuando queremos que el modelo trabaje sobre un entorno y no únicamente sobre lo que conseguimos meter dentro de la conversación.

Imaginemos una tarea bastante aburrida: tengo una carpeta con varios cientos de archivos desordenados y quiero clasificarlos siguiendo unas reglas, renombrar los que no cumplen una convención y generar al final un pequeño informe con los cambios.

Con un chatbot podría explicar el problema, subir algunos ejemplos y pedirle que me escriba un script. Después tendría que copiarlo, ejecutarlo, descubrir que no contemplaba uno de los casos, volver al chat, pegarle el error y repetir el proceso.

Con un agente que tenga acceso a esa carpeta y a una terminal puedo describir el resultado que quiero y dejar que inspeccione primero qué hay realmente allí. Puede listar los archivos, detectar patrones, proponer una estrategia, escribir el script, ejecutarlo, comprobar el resultado y corregirlo si algo falla.

La inteligencia puede venir exactamente del mismo modelo. Lo que ha cambiado es el entorno en el que lo estamos utilizando.

Lo mismo ocurre con desarrollo. Preguntar en un chat «¿por qué falla esta función?» y pegar 50 líneas de código es muy diferente de darle al agente acceso a un repositorio y pedirle que localice el origen de un bug. En el segundo caso puede descubrir que la función que estamos mirando ni siquiera es el problema, seguir una referencia hasta otro módulo, revisar los tests existentes, ejecutar la aplicación y validar el cambio.

La imagen de un «agente» como una entidad completamente autónoma que trabaja durante días mientras dormimos complica demasiado una idea que, para empezar, puede entenderse de forma mucho más simple: un modelo dentro de un bucle con acceso a herramientas.

recibe contexto → decide qué hacer → utiliza una herramienta → observa el resultado → decide de nuevo.

Ese bucle puede durar dos pasos o doscientas iteraciones. La diferencia práctica está en cuánto puede observar el modelo, qué acciones tiene disponibles y cómo incorpora sus resultados para decidir el siguiente paso.

Modelo, proveedor, harness y entorno

Aquí empieza buena parte de la confusión porque productos como ChatGPT ocultan casi todas estas capas. Abrimos la aplicación, seleccionamos si acaso un modelo y empezamos a escribir. En herramientas más abiertas, en cambio, esas piezas dejan de venir empaquetadas y conviene separarlas mentalmente.

La simplificación que a mí me habría gustado tener al principio es esta:

modelo → proveedor → harness → herramientas y entorno

Es un mapa mental deliberadamente sencillo, suficiente para distinguir qué hace cada pieza sin convertir el artículo en una arquitectura universal de sistemas de IA.

El modelo

GPT, Claude, Gemini, Qwen, DeepSeek, Kimi o GLM son familias de modelos.

Aquí podríamos entrar durante horas en parámetros, entrenamiento, reasoning, contexto o benchmarks, pero para empezar no hace falta. Lo importante es entender que el modelo es la pieza que recibe el contexto que le hemos preparado y genera la siguiente salida: puede ser una respuesta para nosotros, código, datos estructurados o la intención de utilizar una herramienta.

A efectos prácticos, hoy existe una división que, aunque sea una simplificación, resulta útil para quien empieza.

Por una parte están los grandes modelos propietarios o frontier de compañías como OpenAI, Anthropic o Google. Normalmente son los modelos que primero vemos integrados en los grandes productos comerciales y los que compiten por las primeras posiciones en muchos benchmarks.

Por otra tenemos un ecosistema enorme de modelos abiertos u open-weight. En los últimos años buena parte de la actividad más interesante de este segundo grupo ha venido de laboratorios asiáticos: Qwen, DeepSeek, Kimi, GLM, MiniMax y muchos otros.

Esta clasificación me sirve para orientarme, pero bastante poco para decidir qué modelo va a ser mejor en un trabajo concreto. Una de las cosas que más me ha cambiado al probarlos es comprobar que para aprender, experimentar o incluso realizar bastante trabajo real no necesitas siempre el modelo más potente que exista esa semana.

Un modelo más barato y rápido puede encajar mejor en tareas repetitivas; otro puede seguir instrucciones de una manera que te resulte más cómoda. Algunos modelos abiertos son ya suficientemente capaces para utilizar herramientas, escribir código y mantener sesiones agentic bastante largas. Por eso, para empezar, me parece mucho más útil escoger algo suficientemente bueno y trabajar con ello que quedarse bloqueado buscando «el mejor modelo».

El proveedor

Aquí aparece otra distinción que al principio puede pasar desapercibida.

Quien crea un modelo y quien ejecuta ese modelo para ti no tienen por qué ser la misma empresa.

Si consumes directamente la API de OpenAI para utilizar un modelo GPT, desarrollador y proveedor coinciden. Pero hay modelos que pueden estar desplegados simultáneamente por muchas compañías diferentes.

Esto produce una situación curiosa: el mismo modelo puede sentirse diferente dependiendo de quién lo está sirviendo. La capacidad base del modelo sigue ahí, pero cambian variables como el hardware, la configuración, la velocidad, la disponibilidad, los límites, el soporte de determinadas características, el caching, la ubicación geográfica o el precio.

OpenRouter hace este fenómeno especialmente visible. Actualmente agrega cientos de modelos y decenas de proveedores detrás de una API común y publica para muchos endpoints métricas como time to first token, throughput y uptime. Su router puede además elegir proveedor teniendo en cuenta precio, velocidad o fiabilidad.

Esta es una de esas partes que parecen irrelevantes hasta que empiezas a utilizar APIs de forma intensiva. Dos endpoints que sirven el mismo modelo pueden ofrecer una experiencia bastante distinta.

El harness

Esta es probablemente la pieza a la que menos atención prestaba al principio y una de las que más valoro ahora.

Codex, Claude Code u OpenCode son ejemplos de harnesses.

El término harness se utiliza con cierta flexibilidad. La forma que me resulta más útil de pensarlo es sencilla: es el software que pone al modelo a trabajar.

El modelo por sí solo genera una salida. Para poder inspeccionar nuestro filesystem, ejecutar git diff, lanzar un comando, buscar un archivo o abrir una página, alguien debe proporcionarle esas capacidades.

El harness prepara el contexto que verá el modelo, describe qué herramientas existen, recibe una solicitud de uso de herramienta, ejecuta la acción correspondiente, incorpora el resultado de nuevo al contexto y continúa el loop.

Además puede encargarse de muchas otras cosas: permisos, historial de la sesión, compactación del contexto, instrucciones del proyecto, gestión de archivos, subagentes, MCPs, skills o interacción con Git.

Por eso utilizar el mismo modelo desde dos harnesses puede producir experiencias bastante distintas. Con el tiempo dejé de fijarme sólo en «¿qué modelo estás usando?» y empecé a preguntar también «¿dónde lo estás usando?».

Suscripción, API o local

Una vez separadas estas piezas, la siguiente decisión es cómo conseguir acceso al modelo. Hay muchas combinaciones, pero para empezar yo las reduciría a tres: suscripción, API o ejecución local. Para una primera experiencia normalmente recomendaría la suscripción.

Una suscripción es la forma fácil de experimentar

La idea es la misma que en muchos otros productos digitales: pagas una tarifa periódica y recibes una determinada cantidad de uso.

La implementación concreta cambia mucho entre servicios. Algunos tienen ventanas que se reinician cada determinadas horas, límites semanales, límites mensuales, créditos o combinaciones de varios mecanismos.

Para una primera prueba, el detalle de cada contador importa menos que una ventaja muy práctica: el coste es predecible.

Cuando estás experimentando es muy fácil ser tremendamente ineficiente.

Puedes pedir al agente una tarea mal definida y descubrir veinte minutos después que ha leído medio repositorio para nada. Puedes abrir varias sesiones. Puedes utilizar un modelo caro para una tarea trivial. Puedes hacer crecer el contexto mucho más de lo necesario o simplemente pasarte una tarde probando cómo responde el sistema.

Con una API cada una de esas decisiones tiene un precio real.

Con una suscripción tienes unos límites, pero dentro de ellos puedes equivocarte con mucha más tranquilidad.

Por eso creo que es una buena primera vía para descubrir si realmente te resulta útil esta forma de trabajar.

Actualmente ChatGPT Plus cuesta 20 dólares al mes y ofrece límites superiores y acceso a modelos y herramientas adicionales respecto al plan gratuito; el consumo de API continúa siendo independiente. Anthropic sigue una separación parecida: Claude Pro incluye Claude Code, mientras que el acceso mediante la API de Anthropic se factura aparte; además, el uso de Claude y Claude Code comparte los límites de la suscripción.

Esto último es importante porque una suscripción no equivale a una API plana infinita.

Normalmente estamos comprando acceso a unos productos concretos bajo unas condiciones concretas.

API: pagar exactamente por lo que consumes

La segunda vía es la API.

Aquí la experiencia cambia.

Creas una cuenta con un proveedor, obtienes una API key, configuras esa credencial en el software que vaya a utilizarla y el consumo se factura normalmente en función del uso.

La unidad que más vas a ver son los tokens.

Para entender la factura basta con una aproximación sencilla, sin entrar todavía en cómo se tokeniza exactamente cada palabra:

• hay tokens que enviamos al modelo;
• hay tokens que el modelo genera;
• procesar unos y otros tiene un coste.

Una conversación larga no envía necesariamente únicamente nuestra última frase. El sistema puede necesitar incluir instrucciones, historial, herramientas disponibles, resultados anteriores y otro contexto necesario para continuar trabajando.

Por eso un agente puede consumir bastante más que la frase que acabamos de escribir.

También aparecen otros mecanismos —prompt caching, reasoning tokens, precios distintos según tamaño de contexto, herramientas—, pero ya son un segundo nivel. La primera idea importante es simplemente que cada vuelta del loop consume inferencia.

La API encaja de forma natural en una cantidad enorme de casos.

Si estoy construyendo una aplicación que utilizarán otras personas, no tiene sentido autenticarla mediante mi suscripción personal de ChatGPT. Si quiero ejecutar un proceso automatizado en CI, utilizar modelos desde mi backend, seleccionar dinámicamente modelos diferentes o aplicar controles empresariales específicos, la API suele encajar mucho mejor.

También es donde empiezan a aparecer requisitos que al experimentar en casa probablemente ni nos planteamos: retención de datos, residencia regional, acuerdos contractuales, control de gasto o separación entre proyectos.

La diferencia conceptual que me quedaría es esta:

una suscripción está pensada principalmente para que tú utilices un producto; una API está pensada para que software consuma un servicio.

Es una simplificación útil como mapa inicial, aunque cada vez existan más productos híbridos que mezclan ambos modelos de acceso.

Probar muchos modelos

Aquí aparecen dos soluciones que me parecen especialmente cómodas.

La primera son suscripciones que ya agregan modelos diferentes.

OpenCode Go, por ejemplo, cuesta actualmente 10 dólares al mes y ofrece acceso a una selección de modelos mediante una API key propia. En su catálogo de octubre de 2026 aparecen modelos de GLM, Kimi, Qwen, DeepSeek, MiniMax y otros; la propia documentación avisa de que la lista cambia a medida que incorporan modelos nuevos. Además, esa key puede utilizarse con OpenCode o con otros agentes compatibles.

La segunda son los routers.

OpenRouter es probablemente el ejemplo más conocido. En lugar de abrir cuentas y configurar una integración diferente para cada proveedor, utilizas una única API y desde ella accedes a un catálogo enorme de modelos y proveedores.

A mí me parece especialmente útil para experimentar: puedo cargar unos créditos, cambiar una línea de configuración y probar otro modelo, mantener el mismo modelo y observar qué proveedor me da mejor latencia o throughput, o dejar que el router seleccione automáticamente entre varios endpoints. Como banco de pruebas es extremadamente cómodo, aunque una integración empresarial pueda acabar necesitando otra arquitectura.

Ejecutarlo tú mismo

La tercera opción es ejecutar el modelo en tu propio hardware. Puedes descargar pesos de un modelo compatible, utilizar un runtime como Ollama, LM Studio o llama.cpp y exponerlo incluso mediante una API local que otras herramientas consuman como si se tratase de un proveedor remoto.

Es una capa muy interesante si también quieres aprender cómo se sirve la inferencia: se aprende mucho, ganas control sobre el entorno y puedes mantener determinados datos localmente. A cambio aparecen problemas nuevos —VRAM, cuantización, GPU offload, KV cache, tamaño de contexto, runtimes o rendimiento— que son independientes de aprender a utilizar un agente.

En mi caso, por ejemplo, conseguir una experiencia que me convenciese con un Qwen de 27B y una RTX 5070 Ti de 16 GB terminó implicando probar distintas cuantizaciones, ajustar la KV cache, jugar con el contexto y comprobar cómo cambiaba el throughput antes siquiera de empezar la prueba agentic que quería hacer.

En mi caso esa fricción valió la pena porque quería aprender también la capa de inferencia. Para aprender a utilizar OpenCode, en cambio, podría haber utilizado un proveedor desde el primer minuto. La distinción que haría es sencilla: si quieres aprender inferencia local, monta un modelo local; si quieres aprender a trabajar con agentes, empieza por el camino que menos te distraiga de la tarea.

El harness importa bastante más de lo que parece

Una vez elegido cómo acceder al modelo todavía queda una decisión que al principio yo infravaloraría: desde qué herramienta voy a utilizarlo.

Hay una razón por la que OpenAI desarrolla Codex alrededor de sus modelos y Anthropic hace lo mismo con Claude Code.

Cuando un fabricante controla buena parte de la cadena puede optimizar la experiencia completa: modelos, prompts del sistema, formato de tool calling, mecanismos de contexto, compactación, permisos, interfaz y nuevas capacidades. Esa integración suele notarse en el uso diario, y al mismo tiempo los harnesses abiertos permiten cambiar de modelo o proveedor sin cambiar necesariamente de forma de trabajar. El harness forma parte del producto y condiciona de forma directa cómo se prepara el contexto, se ejecutan herramientas y se mantiene la sesión.

Para empezar utilizaría algo maduro y descubriría primero cómo quiero trabajar. Construir un harness propio o comparar veinte frameworks tiene mucho más sentido cuando ya sabes qué limitación concreta intentas resolver.

Si ya utilizas ChatGPT y tienes una suscripción compatible, Codex es una vía muy natural. Si estás en el ecosistema Claude, Claude Code hace exactamente el mismo papel. En ambos casos tienes una experiencia bastante integrada entre proveedor, modelos y agente.

OpenCode me parece especialmente interesante para el perfil que quiere experimentar.

Es un harness abierto donde puedes conectar proveedores muy diferentes. Hoy puedo utilizar un modelo mediante OpenCode Go, mañana conectar OpenRouter y después apuntarlo contra una instancia local. El workflow sigue siendo aproximadamente el mismo mientras cambio la capa de inferencia.

Eso permite descubrir algo que mirando benchmarks cuesta mucho ver: qué parte de la experiencia que me gusta viene realmente del modelo y qué parte viene del agente que lo rodea.

También hay una cuestión puramente de interfaz. A mí puede gustarme trabajar desde terminal; otra persona puede preferir una aplicación de escritorio con sesiones visibles, diffs claros y menos comandos que recordar. Para una primera experiencia escogería la herramienta con la que antes puedas olvidarte del setup y empezar a darle trabajo real.

Qué probaría como primera experiencia

Para una primera prueba escogería un proyecto prescindible y, sobre todo, una tarea que conozcas suficientemente bien como para evaluar el resultado. Así puedes observar cómo trabaja el agente sin empezar precisamente por el repositorio que más te importa, y Git o los permisos siguen estando ahí como red de seguridad.

La tarea debería ser suficientemente real como para obligarle a utilizar el entorno. En vez de pedirle simplemente que cree una calculadora, buscaría algo ligeramente incómodo: una carpeta que llevas meses queriendo ordenar, un pequeño proyecto personal al que quieres añadir una funcionalidad, un repositorio que conoces donde falla un test, una colección de Markdown con nombres inconsistentes o un script aburrido que siempre haces manualmente.

Para mucha gente la sorpresa llegará menos por ver al modelo escribir código —eso ya lo hacía el chat— que por verlo ejecutar ls, abrir varios archivos, encontrar por sí mismo el lugar correcto donde trabajar, modificar algo, comprobar el resultado y continuar sin que tengas que transportar manualmente cada fragmento de información entre tu ordenador y una conversación.

A partir de ahí empieza la parte más interesante: aprender qué delegar y qué no.

Una instrucción como «mejora este proyecto» sigue siendo mala aunque el modelo sea excelente.

Una tarea con intención, restricciones y una forma de comprobar si ha terminado suele funcionar mucho mejor:

Revisa cómo se están generando estas páginas. Quiero eliminar esta duplicidad sin cambiar las rutas públicas. Antes de modificar nada identifica dónde se produce, y después ejecuta los tests existentes y el build.

En la práctica me funciona mejor explicar bien el trabajo que buscar un prompt mágico. Alrededor de los agentes se ha creado toda una disciplina de prompts gigantescos que puede dar la sensación de que para utilizarlos correctamente hay que aprender una nueva lengua, pero mi experiencia ha ido en la dirección contraria: cuanto mejor se vuelven los modelos, más valor tiene proporcionarles buen contexto, objetivos claros y mecanismos para comprobar el resultado, y menos interesante me resulta redactar hechizos de veinte párrafos para cada tarea.

Del prompt al contexto

Aquí es donde el uso de agentes empieza a separarse bastante de utilizar un chatbot esporádicamente.

Un agente que lleva una hora trabajando no sólo tiene nuestro último mensaje.

Puede tener instrucciones generales, información del proyecto, definiciones de herramientas, archivos que ha leído, salidas de terminal, resultados de búsquedas, decisiones anteriores y una conversación que continúa creciendo.

Todo eso compite por espacio dentro del contexto que procesa el modelo.

Por eso se habla tanto de context engineering.

La idea no tiene por qué ser más complicada de lo que parece: qué información necesita el modelo, cuándo la necesita y de qué forma se la damos.

Un archivo de instrucciones en la raíz de un repositorio puede indicarle cómo se construye el proyecto y qué no debe tocar. Una skill puede encapsular un procedimiento que queremos reutilizar. Una herramienta puede permitirle obtener información bajo demanda en vez de insertar toda esa información permanentemente en el prompt.

En ese momento también empiezas a entender por qué llenar el contexto con documentación «por si acaso» puede ser contraproducente.

Más contexto no significa automáticamente más inteligencia.

Parte del trabajo consiste precisamente en que el modelo vea lo relevante en el momento adecuado.

Todo esto se entiende mucho mejor después de haber utilizado un agente y haber sufrido alguna vez una sesión que empieza muy bien y se degrada a medida que crece. Ahí conceptos como compaction, instrucciones o selección de contexto dejan de ser teoría y empiezan a resolver problemas que ya has visto.

Añadir MCP, skills y subagentes cuando hagan falta

Es muy fácil entrar en este ecosistema y pasar más tiempo preparando el agente que utilizándolo. MCP puede ser muy útil para exponer herramientas y datos externos mediante una interfaz estandarizada; las skills pueden encapsular conocimiento o procedimientos reutilizables; los subagentes permiten repartir determinados trabajos; y los plugins pueden empaquetar funcionalidades más completas dependiendo del ecosistema.

Todas esas piezas tienen aplicaciones reales, pero también introducen coste. Más herramientas significan más opciones entre las que el modelo debe escoger, más instrucciones ocupan más contexto y más agentes implican más inferencia, coordinación y lugares donde algo puede desviarse. Si todavía estás descubriendo cómo trabaja un agente sobre un repositorio, empezaría pequeño y añadiría cada pieza cuando aparezca un problema concreto que la justifique.

Por qué una sesión agentic puede gastar mucho más de lo que parece

Este fue otro cambio de mentalidad importante para mí cuando empecé a probar APIs. En un chat pensamos fácilmente en mensajes: yo pregunto una cosa y el modelo responde. En un agente, una sola petición nuestra puede convertirse internamente en muchas llamadas:

el modelo estudia el problema, decide leer un archivo, recibe el archivo, decide buscar otro símbolo, recibe el resultado, ejecuta un comando, interpreta el error, modifica código, ejecuta tests y analiza el resultado.

Para nosotros la petición sigue siendo:

«Arregla esto.»

Para el proveedor, en cambio, pueden haber sido muchas inferencias sobre un contexto que además va creciendo.

Si después añadimos varios subagentes trabajando en paralelo, la diferencia aumenta todavía más.

Esto explica parte de la diferencia entre dos formas de pagar por IA. Una suscripción de 20 dólares puede permitirte hacer una cantidad de experimentos difícil de reproducir pagando uno por uno determinados modelos frontier mediante API. La API, en cambio, te proporciona control, programabilidad y la posibilidad de incorporar esa inferencia a tus propios sistemas. Son dos formas de acceso pensadas para necesidades distintas.

Elegir modelos para tu propio workflow

Este artículo va a envejecer porque el mercado cambia a una velocidad absurda. A fecha de octubre de 2026 la situación ya es diferente a la de hace unos meses, y probablemente vuelva a cambiar varias veces antes de que termine el año.

Un mes aparece un nuevo Claude que lidera determinadas comparativas. Después OpenAI publica otra familia. Qwen actualiza su línea. DeepSeek saca algo mucho más barato. Algún proveedor empieza a servir un modelo a una velocidad que cambia por completo la experiencia.

Intentar comprar siempre «el mejor modelo» puede convertirse en un hobby por sí mismo.

Los benchmarks y los evals aportan información, pero una puntuación agregada no sabe cuál es tu trabajo ni qué parte de la experiencia valoras más.

Quizá necesitas que el modelo mantenga una sesión de programación durante horas. Quizá lo que más valoras es velocidad porque realizas decenas de iteraciones cortas. Quizá necesitas una ventana de contexto enorme. Quizá trabajas con herramientas y te importa mucho que las tool calls sean fiables. Quizá la diferencia que más notas no es de inteligencia, sino que un modelo interrumpe constantemente tu workflow por sus políticas de seguridad.

Incluso el precio puede cambiar completamente la comparación.

Un modelo ligeramente peor pero diez veces más barato puede ser muchísimo mejor para un subagente que sólo clasifica resultados.

Por eso mi recomendación es bastante sencilla: escoge dos o tres modelos que tengan sentido para tu caso y pruébalos con el mismo trabajo real. Después compara cuál te ha obligado a intervenir menos, cuál ha entendido mejor el objetivo, cuál ha sido suficientemente rápido y cuánto te ha costado. Ese pequeño eval personal probablemente te resulte más útil que una tabla donde tu tarea ni siquiera aparece.

Un caso especialmente incómodo: ciberseguridad

En mi caso hay además una variable que para la mayoría de usuarios probablemente sea irrelevante: trabajo en seguridad ofensiva. Los modelos más capaces pueden ayudar muchísimo revisando código, entendiendo vulnerabilidades, escribiendo pequeñas PoC, procesando documentación o acompañando un pentest, pero también operan con políticas de seguridad. Cuando tu trabajo consiste precisamente en explotar sistemas, analizar malware o ejecutar acciones que fuera de un entorno autorizado serían claramente abusivas, esa política puede convertirse en una parte muy visible de la experiencia.

OpenAI tiene actualmente Daybreak / Trusted Access for Cyber, un programa específico para profesionales y organizaciones de seguridad. Sus niveles Blue y Red permiten reducir determinados refusals en workflows autorizados; Red está orientado precisamente a actividades como pentesting, red teaming o validación de exploits y requiere una aprobación adicional. La propia documentación deja claro que esto no elimina todos los safeguards ni todos los rechazos.

Es una mejora importante, aunque en la práctica sigo encontrando sesiones donde parte de la fricción consiste en dejar claro al modelo que estoy trabajando en un entorno autorizado. En otras pruebas, modelos como GLM o DeepSeek han cumplido de sobra con la tarea y me han dado una experiencia más directa.

La conclusión que saco de ahí es bastante limitada pero útil: el mejor modelo depende del workflow, y en ciberseguridad las políticas forman parte de ese workflow. Para una revisión compleja puedo preferir el modelo que más razona aunque introduzca algo más de fricción; para otras tareas puedo preferir uno algo menos capaz que avance de forma rápida y consistente.

Lo que yo recomendaría ahora mismo

Esta es la sección que más rápido va a caducar del artículo, así que conviene leerla como lo que es: un snapshot de octubre de 2026. La tabla resume distintos puntos de entrada según lo que quieras probar.

Si quieres…	Yo empezaría con…	Por qué
La experiencia más integrada	ChatGPT + Codex	Una única suscripción cubre chat, razonamiento y el agente; buen punto de entrada para experimentar sin pensar desde el primer día en facturación por API.
Claude y un agente de terminal	Claude Pro + Claude Code	Experiencia muy integrada y directa si lo que realmente te interesa es utilizar Claude como agente.
Probar muchos modelos con poco coste	OpenCode + Go	Harness abierto y una suscripción barata con una selección cambiante de modelos.
Experimentar con APIs/providers	OpenRouter	Una API, cientos de modelos y posibilidad de comparar incluso distintos proveedores del mismo modelo.
Aprender inferencia local	Ollama / LM Studio + modelo local	Mucho más control y una buena forma de entender qué ocurre debajo, asumiendo la fricción adicional del hardware.

En mi caso particular, si alguien me preguntase qué escogería para una primera experiencia general, probablemente sería ChatGPT Plus por la combinación que ofrece. Puedo pasar bastante tiempo en el chat discutiendo una idea, investigando, refinando requisitos o simplemente intentando decidir qué quiero hacer; cuando la conversación deja de ser «pensar sobre el trabajo» y pasa a ser «haz el trabajo», Codex encaja de manera natural. Ese patrón se ha convertido prácticamente en mi forma de utilizar estas herramientas: debatir en el chat → implementar con el agente.

Plus cuesta actualmente 20 dólares al mes y da acceso a GPT-6 Sol y GPT-6.1 Sol que ya forman parte de la oferta para Work y Codex. Plus también incluye acceso limitado a GPT-6 Astra en Work y Codex.

Hay cuotas y pueden cambiar, pero para alguien que está aprendiendo el margen práctico permite hacer bastantes pruebas sin convertir cada sesión en una hoja de cálculo de costes.

Si lo único que me interesase fueran los modelos Claude y trabajar desde una terminal, miraría Claude Pro. Actualmente incluye Claude Code, aunque Claude y Claude Code comparten límites de uso y existe tanto una ventana de uso como límites semanales.

Si quisiera explorar el ecosistema que queda fuera de los grandes proveedores estadounidenses, OpenCode Go me parece actualmente una de las formas más sencillas de hacerlo. Por 10 dólares al mes ofrece una selección importante de modelos de Qwen, DeepSeek, GLM, Kimi, MiniMax y otros, y encaja directamente en OpenCode.

Ollama Pro ocupa ahora una posición parecida pero con un enfoque algo distinto. Su plan Pro cuesta actualmente 20 dólares al mes e incluye 60 dólares mensuales de créditos para modelos cloud, además de mantener su ecosistema de ejecución local. Ollama indica además soporte para agentes populares y una API propia.

Y si lo que quiero es abrir completamente la caja y empezar a comparar APIs, OpenRouter. Cargo algo de saldo y puedo cambiar modelos, comparar costes, probar providers, mirar latencias y decidir más adelante si alguno merece una integración directa. Para una primera sesión quizá añade demasiadas decisiones; una vez entiendes las piezas, funciona como un laboratorio muy cómodo.

Empezar con el mínimo setup útil

Creo que este es uno de los errores más fáciles de cometer ahora mismo. Hay tantas herramientas nuevas que puedes dedicar semanas a preparar la forma perfecta de utilizar IA antes de haberle dado una tarea suficientemente real. Empiezas buscando un agente, descubres MCP, añades skills, ves a alguien utilizando subagentes, encuentras otro harness más extensible y terminas cambiando de proveedor porque un modelo nuevo promete mejor tool calling. Es fácil acabar con una configuración espectacular sin haber comprobado todavía qué parte de todo eso necesitabas.

Para mí el punto de partida debería ser mucho más pequeño: un modelo, un harness, un proyecto que puedas romper y una tarea real. A partir de ahí, cada capa entra cuando resuelve un problema concreto. Si el modelo se queda corto, pruebas otro; si la suscripción se agota, comparas otro plan o una API; si quieres probar muchos modelos, añades un router; si necesitas acceder a una herramienta interna, entonces MCP empieza a tener sentido; si repites continuamente el mismo procedimiento, quizá merece convertirse en una skill; y si necesitas privacidad o quieres aprender inferencia, montas el modelo local.

Ese orden me parece mucho más útil que copiar de entrada una arquitectura compleja que todavía no responde a ninguna necesidad propia.

Del chatbot al sistema

La primera vez que utilizamos ChatGPT es fácil pensar que «la IA» es el modelo que responde dentro de esa página. Cuando empiezas a trabajar con agentes la imagen se hace más grande: siguen importando muchísimo las capacidades del modelo, pero también el proveedor que lo sirve, el harness que construye el loop, el contexto que recibe, las herramientas disponibles, el entorno en el que trabaja y la forma en que pagamos la inferencia.

Entender esas piezas sirve sobre todo para saber cuáles necesitas en cada momento y cuáles puedes ignorar. Para descubrir qué se siente al delegar una tarea a un agente basta con escoger Codex, Claude Code u OpenCode, darle acceso a algo que puedas romper y probar una tarea real. A partir de lo que ocurra en esa sesión resulta mucho más fácil decidir si necesitas otro modelo, otro proveedor o más tooling.

A mí me ha resultado bastante más útil aprender así que intentar decidir desde fuera cuál era la combinación perfecta de modelo, agente y proveedor. Dentro de unos meses esa combinación probablemente habrá cambiado otra vez; el mapa, en cambio, debería seguir siendo bastante parecido.