Capital de Tokens
Un video que volvió a circular recientemente bajo el título “How to connect ChatGPT to Jupyter Notebooks for free” parece describir una integración moderna entre ChatGPT y Jupyter.
Pero hay un detalle importante: el material original fue publicado por Alex The Analyst el 25 de abril de 2023.
Eso cambia bastante la lectura técnica.
En 2023, ChatGPT todavía era un producto mucho más aislado del ecosistema de desarrollo. La extensión mostrada en el tutorial resolvía un problema real de una forma bastante ingeniosa: reutilizaba la sesión autenticada de ChatGPT dentro del navegador y permitía enviar prompts desde un notebook.
La idea sigue siendo excelente.
La implementación, no tanto.
Tres años después, el ecosistema alrededor de notebooks, APIs y agentes evolucionó lo suficiente como para que hoy existan varias arquitecturas más limpias y potentes.
Y lo más interesante no es simplemente “tener ChatGPT dentro de Jupyter”.
La idea realmente poderosa es otra:
un modelo que puede observar un notebook, generar código, ejecutarlo, inspeccionar el resultado y continuar razonando se convierte en un agente de análisis.
Ese patrón es mucho más importante que la extensión concreta del video.
Lo que hacía realmente la extensión de 2023
El proyecto utilizado en aquel tutorial se llama ChatGPT for Jupyter.
Su arquitectura era aproximadamente ésta:
Jupyter Notebook
↓
Browser extension
↓
reutiliza la sesión de ChatGPT
↓
servicio web de ChatGPT
↓
respuesta
↓
la extensión crea celdas en el notebookEl usuario escribía un prompt dentro de una celda Markdown con una marca especial:
##### chat
Escribe una función de Python que calcule números primos.Al ejecutar la celda, la extensión enviaba el texto a ChatGPT.
Cuando el modelo devolvía código, la extensión podía extraer ese bloque y colocarlo automáticamente en una nueva celda ejecutable.
Para 2023 era una experiencia sorprendentemente avanzada.
Pero la parte técnica más importante aparece en el propio README del proyecto: la extensión reutilizaba el bearer token obtenido al iniciar sesión en ChatGPT y actuaba como una especie de proxy privilegiado desde el navegador.
Eso tenía sentido en aquel momento porque la API oficial de ChatGPT todavía no ofrecía el camino que hoy damos por sentado.
La extensión además estaba diseñada principalmente para la interfaz clásica de Jupyter Notebook, no para la arquitectura moderna de JupyterLab.
Por qué aquel método era “gratis”
La palabra gratis del título tiene una explicación concreta.
La extensión no estaba haciendo llamadas normales a una API de OpenAI con facturación por consumo.
En vez de eso utilizaba la sesión web que el usuario ya tenía abierta en ChatGPT.
Conceptualmente:
Usuario paga o usa ChatGPT
↓
inicia sesión en chatgpt.com
↓
browser obtiene credenciales de sesión
↓
extensión reutiliza esa sesión
↓
Jupyter puede conversar con ChatGPTEso evitaba tener que configurar una API key y pagar llamadas por separado.
Ingenioso, sí.
Pero también frágil.
El código depende de detalles internos del producto web: autenticación, endpoints, tokens, restricciones del navegador y mecanismos que pueden cambiar sin que exista un contrato público de compatibilidad.
No es la clase de dependencia sobre la cual construiríamos hoy una plataforma seria.
El patrón sigue siendo correcto; la integración cambió
Lo que sí sobrevivió perfectamente fue la idea de colocar un LLM cerca del entorno de ejecución.
Un notebook es un lugar particularmente bueno para hacerlo porque combina tres cosas:
código
+
datos
+
estado de ejecuciónUn documento de texto tradicional sólo contiene información estática.
Un notebook contiene además un entorno vivo.
Por ejemplo:
import pandas as pd
df = pd.read_csv("ventas.csv")
df.describe()El valor importante no es únicamente el código.
También están disponibles:
- las columnas reales del DataFrame;
- los tipos de datos;
- los errores producidos por Python;
- las variables actualmente cargadas;
- los resultados de las celdas anteriores;
- los gráficos generados;
- el estado acumulado del kernel.
Para un modelo de IA eso es muchísimo más rico que recibir simplemente un archivo .py.
Opción 1: ChatGPT ya tiene un notebook detrás
Hay una ironía interesante en todo esto.
Mientras aquel tutorial intentaba llevar ChatGPT hacia Jupyter, actualmente ChatGPT ya utiliza un entorno Jupyter para determinadas tareas de análisis de datos.
Cuando el usuario carga un CSV, Excel, JSON u otros archivos compatibles y pide un análisis, ChatGPT puede escribir y ejecutar Python dentro de un entorno de notebook con estado.
La arquitectura conceptual se parece a esto:
Usuario
↓
ChatGPT
↓
modelo
↓
Python / Jupyter
↓
archivo + pandas + cálculos
↓
resultado
↓
modelo interpreta el resultadoEsto es importante porque elimina buena parte de la fricción del tutorial original.
Para muchos análisis exploratorios ya no hace falta instalar una extensión para que el modelo pueda ejecutar Python.
El propio producto puede hacerlo.
Pero esta solución tiene una limitación importante: el notebook ejecutado por ChatGPT es un entorno administrado, no necesariamente tu notebook local con todas tus dependencias, archivos privados, servicios internos y kernels personalizados.
Ahí es donde vuelven a ser interesantes las integraciones locales.
Opción 2: Jupyter AI
Una de las soluciones más naturales actualmente es Jupyter AI, un proyecto del propio ecosistema Jupyter.
Jupyter AI integra modelos generativos directamente en JupyterLab y soporta múltiples proveedores.
La experiencia puede incluir:
JupyterLab
├── notebook
├── chat de IA
├── acceso a archivos
├── contexto del notebook
└── modelos externos o localesLa versión moderna de Jupyter AI dispone incluso de conceptos como personas, herramientas del notebook y servidores MCP personalizados.
Esto ya está bastante lejos de aquella sencilla extensión de navegador de 2023.
Ahora estamos entrando en territorio de agentic notebooks.
Magic commands
Jupyter AI también permite trabajar directamente desde las celdas mediante comandos mágicos de IPython.
La extensión correspondiente puede instalarse con:
pip install jupyter-ai-magic-commandsDespués:
%load_ext jupyter_ai_magic_commandsY podemos descubrir modelos disponibles con:
%ai listO filtrar proveedores:
%ai list openaiUna celda puede entonces convertirse en un prompt:
%%ai <provider>/<model>
Explícame por qué esta distribución tiene una cola tan larga.El detalle importante es que ya no estamos atados a una sola interfaz de ChatGPT.
Jupyter se convierte en la capa de interacción y el proveedor del modelo puede cambiar.
Opción 3: llamar directamente a la API de OpenAI
Para una integración controlada por nosotros, muchas veces ni siquiera necesitamos una extensión.
Podemos utilizar el SDK oficial de OpenAI desde el propio notebook.
Primero instalamos el paquete:
pip install openaiLa API key debería configurarse como variable de entorno, no escribirse directamente en el notebook:
export OPENAI_API_KEY="..."Después, desde Python:
from openai import OpenAI
client = OpenAI()
response = client.responses.create(
model="gpt-5.6-sol",
input="Explica qué hace una regresión logística en términos intuitivos."
)
print(response.output_text)Esta arquitectura es mucho más estable que reutilizar la sesión del navegador:
Notebook
↓
SDK oficial
↓
Responses API
↓
modeloAdemás nos permite controlar exactamente qué información enviamos al modelo.
Pero aquí hay que corregir otra posible interpretación del viejo tutorial:
la API no debe asumirse como gratuita.
OpenAI mantiene la API como un producto separado con su propio consumo y facturación. Puede haber créditos promocionales o condiciones específicas para ciertas cuentas, pero una aplicación real debe diseñarse suponiendo que las llamadas tienen coste.
Opción 4: realmente gratis con modelos locales
Si el objetivo es evitar por completo el coste por llamada, existe una alternativa mucho más limpia que secuestrar la sesión del navegador:
ejecutar el modelo localmente.
Jupyter AI soporta proveedores locales como Ollama.
La arquitectura pasa a ser:
JupyterLab
↓
Jupyter AI
↓
Ollama
↓
modelo local
↓
CPU / GPU del usuarioEn este caso no existe un proveedor externo cobrando tokens por cada llamada.
El coste se desplaza al hardware, electricidad, memoria y tiempo de cómputo.
Para experimentación, educación, análisis de datos privados o trabajo desconectado puede ser una opción muy atractiva.
También tiene otra ventaja: algunos datasets nunca tienen que abandonar la máquina.
De asistente de código a agente de notebook
Hasta ahora hemos descrito un chatbot dentro de Jupyter.
Pero eso es sólo el primer nivel.
Imaginemos este flujo:
Usuario
↓
"encuentra por qué bajaron las ventas"
↓
LLM
↓
genera Python
↓
Jupyter ejecuta
↓
resultado
↓
LLM inspecciona resultado
↓
genera nueva consulta
↓
Jupyter ejecuta otra vezAhora tenemos un loop:
razonar
↓
actuar
↓
observar
↓
razonar otra vezÉsa es básicamente la anatomía de un agente.
El notebook deja de ser únicamente una libreta interactiva para humanos.
Se convierte también en un runtime de herramientas para el modelo.
Un ejemplo sencillo
Supongamos que tenemos:
import pandas as pd
df = pd.read_csv("ventas.csv")Un asistente convencional podría recibir algo como:
Tengo un DataFrame con ventas. ¿Qué análisis debería hacer?El modelo responde con recomendaciones.
Un agente real puede hacer algo más interesante.
Primero inspecciona:
df.columnsObtiene:
fecha
producto
region
unidades
precioDespués calcula:
df.groupby("region")["unidades"].sum()Observa una anomalía.
Entonces genera otra consulta:
miami = df[df["region"] == "Miami"]
miami.groupby(miami["fecha"].str[:7])["unidades"].sum()Finalmente puede concluir algo como:
La caída global proviene principalmente de Miami y comenzó en junio.
El producto X explica aproximadamente dos tercios de esa reducción.La diferencia es enorme.
En el primer caso el modelo habla sobre los datos.
En el segundo opera sobre ellos.
El notebook como tool
Podemos abstraer todavía más la idea.
Desde la perspectiva del modelo, un kernel de Python puede verse como una herramienta:
python_execute(code)Por ejemplo:
{
"code": "df.groupby('region')['ventas'].sum()"
}La herramienta devuelve:
Miami 125000
Orlando 82000
Tampa 67000El modelo usa ese resultado para decidir el siguiente paso.
En una implementación más avanzada podríamos exponer varias tools:
run_python(code)
read_dataframe(name)
inspect_variables()
render_chart(spec)
read_file(path)
query_database(sql)El notebook deja de ser simplemente una interfaz gráfica.
Pasa a ser un environment para agentes.
MCP lleva esta idea todavía más lejos
Las versiones recientes de Jupyter AI ya contemplan integración con servidores MCP personalizados.
Eso significa que el notebook puede convertirse en un punto donde convergen:
modelo
↓
Jupyter AI
├── kernel Python
├── archivos
├── notebook
├── bases de datos
└── MCP servers
├── GitHub
├── servicios internos
├── APIs
└── herramientas empresarialesEstamos pasando de:
"ChatGPT dentro de Jupyter"a:
"Jupyter como workspace operativo para agentes"Ésta es una evolución conceptual mucho más importante.
El problema del código generado
Dar acceso de ejecución a un modelo también introduce riesgos.
Un LLM puede generar:
import shutil
shutil.rmtree("/datos")O instalar dependencias inesperadas:
pip install paquete-desconocidoO intentar enviar información a servicios externos.
Por eso un notebook agéntico serio debería pensar en aislamiento.
Una arquitectura razonable puede incluir:
LLM
↓
policy / approval gate
↓
sandbox
↓
Python kernel
↓
filesystem restringidoEntre las protecciones útiles están:
- kernels efímeros;
- contenedores;
- filesystem limitado;
- bloqueo de red cuando no sea necesaria;
- límites de CPU y memoria;
- aprobación humana para acciones sensibles;
- registro completo de código ejecutado;
- snapshots del entorno;
- separación entre análisis y producción.
El mismo poder que convierte al notebook en un agente también aumenta el impacto de un error.
Un detalle interesante de ChatGPT Data Analysis
La documentación actual de OpenAI explica que el entorno Python utilizado por ChatGPT para análisis de datos no puede realizar solicitudes externas arbitrarias a Internet.
Eso puede parecer una limitación, pero también ilustra una decisión arquitectónica importante.
El runtime de código está separado del acceso abierto a la red.
Conceptualmente:
modelo
↓
notebook sandbox
├── archivos disponibles
├── pandas
├── Python
└── sin acceso web arbitrarioSeparar razonamiento, herramientas y privilegios es exactamente el tipo de diseño que necesitamos cuando los agentes empiezan a ejecutar código real.
Entonces, ¿qué utilizaría hoy?
Depende del objetivo.
Quiero analizar un archivo rápidamente
Usaría directamente las capacidades de análisis de datos de ChatGPT.
archivo → ChatGPT → Python → análisisEs la ruta con menos infraestructura.
Quiero IA integrada en mi JupyterLab
Utilizaría Jupyter AI.
JupyterLab → Jupyter AI → proveedor de modeloEs una integración nativa del ecosistema Jupyter y permite cambiar proveedores.
Quiero construir mi propio workflow
Usaría el SDK oficial y la Responses API.
notebook → Python SDK → modeloEso nos da control total sobre prompts, herramientas, estado y políticas.
Quiero evitar coste por token
Usaría un modelo local compatible, por ejemplo mediante Ollama.
Jupyter → Jupyter AI → Ollama → modelo localQuiero construir un agente de datos
No pensaría únicamente en “integrar un chatbot”.
Diseñaría explícitamente el loop:
objetivo
↓
modelo
↓
genera acción
↓
notebook ejecuta
↓
resultado
↓
modelo evalúa
↓
siguiente acciónY colocaría un sandbox alrededor del runtime.
La lección del tutorial de 2023
El video sigue siendo interesante porque captura un momento concreto de la evolución de los LLM.
En aquel momento, conectar ChatGPT con Jupyter requería ingeniería lateral:
browser extension
+
sesión web
+
JavaScript inyectadoHoy tenemos piezas mucho más formales:
APIs oficiales
Jupyter AI
model providers
local LLMs
MCP
notebook tools
sandboxes
agent loopsPero el tutorial acertó en algo fundamental antes de que toda esta infraestructura madurara:
el lugar natural de una IA para programación y análisis no es necesariamente una ventana de chat separada.
Puede ser el mismo entorno donde viven el código, los datos y los resultados.
La evolución completa puede resumirse así:
2023
ChatGPT como chatbot
↓
extensión conecta Jupyter
2026
Jupyter como entorno agéntico
↓
LLM + tools + código + datos + ejecuciónY probablemente ésa sea la parte del viejo tutorial que más vale la pena conservar.
No la técnica para reutilizar una sesión del navegador.
Sino la intuición de colocar al modelo dentro del ciclo de ejecución.
Fuentes
- MSN, video republicado: How to connect ChatGPT to Jupyter Notebooks for free
- Alex The Analyst, YouTube: How to Integrate ChatGPT in Jupyter Notebooks for Free!
- GitHub: jflam/chat-gpt-jupyter-extension
- OpenAI Help Center: Data analysis with ChatGPT
- OpenAI Platform: Developer quickstart
- Jupyter AI: User Guide
- Jupyter AI: Magic commands