Haz clic en dos o más elementos a la vez en el navegador. Cursor ve los elementos seleccionados, su código, el diseño que los rodea y las relaciones visuales en la página.
Pídele al agente que haga coincidir uno con otro, elimine el contenido repetido o ajuste un grupo de componentes a la vez.
Describe los cambios a través de la superposición de Design Mode. El micrófono sigue disponible mientras un agente está ejecutándose, para que puedas poner en cola el siguiente cambio por voz sin esperar a que termine el anterior.
Hemos lanzado un conjunto de nuevas funcionalidades en los SDK de TypeScript y Python. Ahora puedes elegir cómo se almacenan los metadatos del agente y de la ejecución, exponer tus propias funciones al agente como herramientas, dirigir las llamadas locales a herramientas a través de Auto-review y anidar subagentes con cualquier nivel de profundidad. Esta versión también incorpora un conjunto de correcciones de fiabilidad, rendimiento y plataforma que facilitan la ejecución de agentes del SDK locales y en Cloud en scripts de producción, CI e integraciones personalizadas.
Ahora puedes proporcionar tus propias herramientas al agente local pasando definiciones de funciones mediante local.customTools, en Agent.create() o en cada send(). El SDK se las expone al agente a través de un servidor MCP integrado llamado custom-user-tools, para que el modelo llame a tu código a través de la misma ruta y el mismo control de permisos que cualquier otra herramienta MCP.
Antes, exponer una capacidad personalizada implicaba configurar tu propio servidor MCP por stdio o HTTP remoto y conectarlo al agente. Ahora basta con una definición de función. Las herramientas personalizadas también son visibles para todos los subagentes de un agente principal, así que una herramienta que defines una vez queda disponible durante toda la ejecución.
Por defecto, un agente local del SDK ejecuta llamadas a herramientas sin pedir aprobación, ya que no hay ningún humano supervisando en una ejecución sin interfaz. Configura local.autoReview para que esas llamadas pasen por Auto-review. Un clasificador decide qué llamadas se ejecutan automáticamente y cuáles se dejan en espera, en lugar de omitir la revisión por completo.
Controlas ese clasificador con instrucciones en lenguaje natural en permissions.json. El campo autoRun.allow_instructions describe patrones de llamadas que conviene permitir, y autoRun.block_instructions describe las que deben dejarse para revisión. Por ejemplo, puedes permitir inspecciones de solo lectura de artefactos de compilación y pausar siempre ante operaciones destructivas, como las eliminaciones.
{ "autoRun": { "allow_instructions": [ "Read-only inspections of build artifacts under ./dist are fine." ], "block_instructions": [ "Always pause delete operations so I get a chance to review them." ] }}
Ambos SDK conservan los metadatos de agentes y ejecuciones para que puedas reanudar un agente después de reiniciar el proceso. Hasta ahora, ese almacén era SQLite. Ahora también puedes optar por un almacén JSONL, que escribe un archivo de texto sin formato de solo anexado que puedes leer, comparar e incluir en el control de versiones. Tanto SqliteLocalAgentStore como JsonlLocalAgentStore se exportan directamente.
Si ninguna de las opciones predeterminadas se adapta a tu configuración, implementa la interfaz pública LocalAgentStore y pásala a través de local.store. Crea un almacén en memoria para ejecuciones efímeras de CI, o usa Postgres para la persistencia cuando quieras que el estado del agente se almacene junto con el resto de los datos de tu aplicación. El SDK de Python expone almacenes de host, JSONL y JSONL compuestos a través del puente.
Ahora los subagentes pueden crear sus propios subagentes, y así sucesivamente. Un subagente revisor puede delegar en un subagente que escriba pruebas, que a su vez puede seguir delegando, y cada nivel mantiene su propio prompt y modelo. No hace falta activar nada; una sesión de subagente registra el ejecutor que necesita para llamar a Task, por lo que el anidamiento funciona automáticamente para cualquier agente que defina subagentes.
Esta versión también incluye una serie de correcciones de calidad de vida en ambos SDK.
Correlación de ejecuciones: Cada send() ahora incluye un requestId generado por la plataforma, expuesto en Run y RunResult y persistido en los almacenes en memoria, SQLite y JSONL. Vincula una ejecución de script o CI con los logs del backend, las analíticas y los hilos de soporte sin tener que inferirlo a partir de agentId.
wait() fiable en ejecuciones locales: Las ejecuciones locales ya no resuelven wait() antes de que se escriba el resultado del terminal. La hidratación sigue actualizándose hasta que la ejecución alcanza un estado final, para que la automatización lea un resultado completo.
Checkpoints seguros al liberar recursos: Liberar un agente local ya no elimina los datos de checkpoint cuando falta una referencia raíz pero todavía existen blobs de checkpoint. El directorio del agente solo se borra cuando de verdad no queda nada que conservar.
Streaming de Cloud sobre HTTP/1.1: Las sesiones de agentes en Cloud ahora se transmiten correctamente en transportes HTTP/1.1 usados por algunos proxies, implementaciones antiguas de fetch en Node y ciertas imágenes de CI. El comportamiento en HTTP/2 no cambia.
Importación más ligera: Importar @cursor/sdk ya no carga de forma anticipada toda la pila local de agentes. Los consumidores que solo usan Cloud o solo tipos evitan el coste del runtime local hasta la primera llamada local, sin cambios en la API. La primera llamada local sí asume ese coste de importación una sola vez y luego queda en caché.
Tipos de TypeScript autocontenidos: Los archivos .d.ts publicados ya no hacen referencia a paquetes del workspace no publicados. Esto soluciona los errores TS2305 y TS2307 con skipLibCheck: false y los any silenciosos en tipos de stream como TurnEndedUpdate.
ripgrep incluido: Las ejecuciones locales de shell usan el binario rg incluido para la plataforma sin modificar tu PATH global. En Windows, anteponer ripgrep ya no sobrescribe la variable Path.
Composer 2 se redirige a Composer 2.5: Los clientes del SDK que todavía fijan slugs retirados de composer-2 se redirigen automáticamente a Composer 2.5, manteniendo intactas las variantes rápidas, para que los scripts antiguos sigan funcionando.
list_runs con ámbito de workspace: Client, AsyncClient y Agent.list_runs aceptan un cwd opcional, y el puente usa como fallback el workspace desde el que se inició. Esto soluciona resultados espurios de "agent not found" cuando el puente se ejecuta como subproceso.
Errores de "no encontrado" más claros: Buscar un agente que no está en el workspace resuelto devuelve un error claro de no encontrado en lugar de un error interno opaco.
Versión 0.1.6 y analíticas: cursor-sdk 0.1.6 documenta la ruta de lanzamiento de Buildkite y etiqueta el uso del SDK como sdk-python- para ofrecer analíticas más claras.
Ejecuta npm install @cursor/sdk o pip install cursor-sdk para actualizar. Los scripts que fijan composer-2 pasan a Composer 2.5 automáticamente, y requestId es una incorporación segura al esquema de metadatos de tus ejecuciones. Consulta la documentación de TypeScript y Python para ver todos los detalles.
Con los canvas, los agentes pueden crear artefactos interactivos como dashboards, informes y herramientas internas que puedes compartir con tu equipo.
Esta versión introduce el Modo de diseño para editar canvas más rápido, nuevas formas de entender el uso del contexto y otras mejoras en la experiencia de uso.
Selecciona y anota elementos de la interfaz directamente en un canvas para orientar las ediciones de Cursor, igual que lo harías en el navegador. En lugar de describir el cambio por texto, puedes señalarlo, dar feedback e iterar más rápido.
Cursor ahora puede mostrar el uso del contexto de tu agente como un informe interactivo en un canvas.
El explorador de contexto desglosa dónde se están usando los tokens en el prompt del sistema, las definiciones de herramientas, las reglas, las Skills y mucho más. Como es un canvas, puedes hacerle al agente preguntas de seguimiento, y puede personalizar el informe para responder a tus preguntas específicas.
Haz clic en el botón Debug with Agent integrado en el canvas para pedirle a Cursor que identifique oportunidades para reducir el uso del contexto en una nueva conversación.
Los canvas compartidos ahora pueden abrirse en pantalla completa en el navegador, lo que facilita su presentación a otras personas.
Se agregó la capacidad de que los agentes inserten botones en los canvas que ejecuten un prompt específico al hacer clic.
Se mejoró la capacidad del agente para solucionar errores de tipo en canvas.
Se mejoró el estilo de los componentes y se añadieron más opciones de personalización de gráficos.
Los clientes de Cursor Enterprise ahora pueden gestionar varios equipos de Cursor desde un solo lugar, con controles independientes de seguridad, gobernanza, presupuesto y funciones para cada uno. Estas capacidades ya están disponibles de forma general para todos los clientes de Cursor Enterprise.
Una organización es el contenedor de nivel superior de la identidad, la administración y los miembros de tu compañía. Ofrece a los administradores un único lugar desde el que ver y gestionar toda la configuración de Cursor, incluido un resumen consolidado del gasto y del uso de tokens de todos los equipos.
Los Teams son la unidad operativa de un departamento, una región o una filial. Es lo que los administradores gestionan hoy como su organización de Cursor. Hemos trasladado esa unidad bajo una organización, para que puedas gestionar varios equipos, cada uno con su propia configuración de seguridad, gobernanza, gasto y funciones.
Un usuario puede pertenecer a más de un equipo, con un rol distinto en cada uno. Para los clientes actuales, tu equipo existente se conserva y se convierte en el espacio predeterminado para iniciar sesión, el enrutamiento y la creación de nuevos equipos.
Los grupos son conjuntos ligeros de usuarios que pueden abarcar varios equipos o estar dentro de ellos. Permiten dar a cohortes de usuarios acceso independiente a modelos, límites de gasto y permisos de agente sin tener que crear un equipo completamente nuevo. Cuando un usuario pertenece a más de un equipo o grupo, prevalece la configuración más permisiva.
Auto-review es un nuevo modo de ejecución que permite a Cursor trabajar durante más tiempo con menos solicitudes de aprobación y una ejecución más segura.
Auto-review se aplica a las llamadas a herramientas de Shell, MCP y Fetch. Las llamadas incluidas en la lista de permitidos se ejecutan de inmediato, y las llamadas que pueden ejecutarse en el sandbox se ejecutan en el sandbox. Todas las demás acciones del agente se envían a un subagente clasificador que decide si permite la llamada, prueba otro enfoque o solicita tu aprobación.
Configura tu modo de ejecución en Configuración > Configuración de Cursor > Agentes > Modo de ejecución. También puedes guiar al agente clasificador dándole instrucciones personalizadas.
Haz clic en dos o más elementos a la vez en el navegador. Cursor ve los elementos seleccionados, su código, el diseño que los rodea y las relaciones visuales en la página.
Pídele al agente que haga coincidir uno con otro, elimine el contenido repetido o ajuste un grupo de componentes a la vez.
Describe los cambios a través de la superposición de Design Mode. El micrófono sigue disponible mientras un agente está ejecutándose, para que puedas poner en cola el siguiente cambio por voz sin esperar a que termine el anterior.
Hemos lanzado un conjunto de nuevas funcionalidades en los SDK de TypeScript y Python. Ahora puedes elegir cómo se almacenan los metadatos del agente y de la ejecución, exponer tus propias funciones al agente como herramientas, dirigir las llamadas locales a herramientas a través de Auto-review y anidar subagentes con cualquier nivel de profundidad. Esta versión también incorpora un conjunto de correcciones de fiabilidad, rendimiento y plataforma que facilitan la ejecución de agentes del SDK locales y en Cloud en scripts de producción, CI e integraciones personalizadas.
Ahora puedes proporcionar tus propias herramientas al agente local pasando definiciones de funciones mediante local.customTools, en Agent.create() o en cada send(). El SDK se las expone al agente a través de un servidor MCP integrado llamado custom-user-tools, para que el modelo llame a tu código a través de la misma ruta y el mismo control de permisos que cualquier otra herramienta MCP.
Antes, exponer una capacidad personalizada implicaba configurar tu propio servidor MCP por stdio o HTTP remoto y conectarlo al agente. Ahora basta con una definición de función. Las herramientas personalizadas también son visibles para todos los subagentes de un agente principal, así que una herramienta que defines una vez queda disponible durante toda la ejecución.
Por defecto, un agente local del SDK ejecuta llamadas a herramientas sin pedir aprobación, ya que no hay ningún humano supervisando en una ejecución sin interfaz. Configura local.autoReview para que esas llamadas pasen por Auto-review. Un clasificador decide qué llamadas se ejecutan automáticamente y cuáles se dejan en espera, en lugar de omitir la revisión por completo.
Controlas ese clasificador con instrucciones en lenguaje natural en permissions.json. El campo autoRun.allow_instructions describe patrones de llamadas que conviene permitir, y autoRun.block_instructions describe las que deben dejarse para revisión. Por ejemplo, puedes permitir inspecciones de solo lectura de artefactos de compilación y pausar siempre ante operaciones destructivas, como las eliminaciones.
{ "autoRun": { "allow_instructions": [ "Read-only inspections of build artifacts under ./dist are fine." ], "block_instructions": [ "Always pause delete operations so I get a chance to review them." ] }}
Ambos SDK conservan los metadatos de agentes y ejecuciones para que puedas reanudar un agente después de reiniciar el proceso. Hasta ahora, ese almacén era SQLite. Ahora también puedes optar por un almacén JSONL, que escribe un archivo de texto sin formato de solo anexado que puedes leer, comparar e incluir en el control de versiones. Tanto SqliteLocalAgentStore como JsonlLocalAgentStore se exportan directamente.
Si ninguna de las opciones predeterminadas se adapta a tu configuración, implementa la interfaz pública LocalAgentStore y pásala a través de local.store. Crea un almacén en memoria para ejecuciones efímeras de CI, o usa Postgres para la persistencia cuando quieras que el estado del agente se almacene junto con el resto de los datos de tu aplicación. El SDK de Python expone almacenes de host, JSONL y JSONL compuestos a través del puente.
Ahora los subagentes pueden crear sus propios subagentes, y así sucesivamente. Un subagente revisor puede delegar en un subagente que escriba pruebas, que a su vez puede seguir delegando, y cada nivel mantiene su propio prompt y modelo. No hace falta activar nada; una sesión de subagente registra el ejecutor que necesita para llamar a Task, por lo que el anidamiento funciona automáticamente para cualquier agente que defina subagentes.
Esta versión también incluye una serie de correcciones de calidad de vida en ambos SDK.
Correlación de ejecuciones: Cada send() ahora incluye un requestId generado por la plataforma, expuesto en Run y RunResult y persistido en los almacenes en memoria, SQLite y JSONL. Vincula una ejecución de script o CI con los logs del backend, las analíticas y los hilos de soporte sin tener que inferirlo a partir de agentId.
wait() fiable en ejecuciones locales: Las ejecuciones locales ya no resuelven wait() antes de que se escriba el resultado del terminal. La hidratación sigue actualizándose hasta que la ejecución alcanza un estado final, para que la automatización lea un resultado completo.
Checkpoints seguros al liberar recursos: Liberar un agente local ya no elimina los datos de checkpoint cuando falta una referencia raíz pero todavía existen blobs de checkpoint. El directorio del agente solo se borra cuando de verdad no queda nada que conservar.
Streaming de Cloud sobre HTTP/1.1: Las sesiones de agentes en Cloud ahora se transmiten correctamente en transportes HTTP/1.1 usados por algunos proxies, implementaciones antiguas de fetch en Node y ciertas imágenes de CI. El comportamiento en HTTP/2 no cambia.
Importación más ligera: Importar @cursor/sdk ya no carga de forma anticipada toda la pila local de agentes. Los consumidores que solo usan Cloud o solo tipos evitan el coste del runtime local hasta la primera llamada local, sin cambios en la API. La primera llamada local sí asume ese coste de importación una sola vez y luego queda en caché.
Tipos de TypeScript autocontenidos: Los archivos .d.ts publicados ya no hacen referencia a paquetes del workspace no publicados. Esto soluciona los errores TS2305 y TS2307 con skipLibCheck: false y los any silenciosos en tipos de stream como TurnEndedUpdate.
ripgrep incluido: Las ejecuciones locales de shell usan el binario rg incluido para la plataforma sin modificar tu PATH global. En Windows, anteponer ripgrep ya no sobrescribe la variable Path.
Composer 2 se redirige a Composer 2.5: Los clientes del SDK que todavía fijan slugs retirados de composer-2 se redirigen automáticamente a Composer 2.5, manteniendo intactas las variantes rápidas, para que los scripts antiguos sigan funcionando.
list_runs con ámbito de workspace: Client, AsyncClient y Agent.list_runs aceptan un cwd opcional, y el puente usa como fallback el workspace desde el que se inició. Esto soluciona resultados espurios de "agent not found" cuando el puente se ejecuta como subproceso.
Errores de "no encontrado" más claros: Buscar un agente que no está en el workspace resuelto devuelve un error claro de no encontrado en lugar de un error interno opaco.
Versión 0.1.6 y analíticas: cursor-sdk 0.1.6 documenta la ruta de lanzamiento de Buildkite y etiqueta el uso del SDK como sdk-python- para ofrecer analíticas más claras.
Ejecuta npm install @cursor/sdk o pip install cursor-sdk para actualizar. Los scripts que fijan composer-2 pasan a Composer 2.5 automáticamente, y requestId es una incorporación segura al esquema de metadatos de tus ejecuciones. Consulta la documentación de TypeScript y Python para ver todos los detalles.
Con los canvas, los agentes pueden crear artefactos interactivos como dashboards, informes y herramientas internas que puedes compartir con tu equipo.
Esta versión introduce el Modo de diseño para editar canvas más rápido, nuevas formas de entender el uso del contexto y otras mejoras en la experiencia de uso.
Selecciona y anota elementos de la interfaz directamente en un canvas para orientar las ediciones de Cursor, igual que lo harías en el navegador. En lugar de describir el cambio por texto, puedes señalarlo, dar feedback e iterar más rápido.
Cursor ahora puede mostrar el uso del contexto de tu agente como un informe interactivo en un canvas.
El explorador de contexto desglosa dónde se están usando los tokens en el prompt del sistema, las definiciones de herramientas, las reglas, las Skills y mucho más. Como es un canvas, puedes hacerle al agente preguntas de seguimiento, y puede personalizar el informe para responder a tus preguntas específicas.
Haz clic en el botón Debug with Agent integrado en el canvas para pedirle a Cursor que identifique oportunidades para reducir el uso del contexto en una nueva conversación.
Los canvas compartidos ahora pueden abrirse en pantalla completa en el navegador, lo que facilita su presentación a otras personas.
Se agregó la capacidad de que los agentes inserten botones en los canvas que ejecuten un prompt específico al hacer clic.
Se mejoró la capacidad del agente para solucionar errores de tipo en canvas.
Se mejoró el estilo de los componentes y se añadieron más opciones de personalización de gráficos.
Los clientes de Cursor Enterprise ahora pueden gestionar varios equipos de Cursor desde un solo lugar, con controles independientes de seguridad, gobernanza, presupuesto y funciones para cada uno. Estas capacidades ya están disponibles de forma general para todos los clientes de Cursor Enterprise.
Una organización es el contenedor de nivel superior de la identidad, la administración y los miembros de tu compañía. Ofrece a los administradores un único lugar desde el que ver y gestionar toda la configuración de Cursor, incluido un resumen consolidado del gasto y del uso de tokens de todos los equipos.
Los Teams son la unidad operativa de un departamento, una región o una filial. Es lo que los administradores gestionan hoy como su organización de Cursor. Hemos trasladado esa unidad bajo una organización, para que puedas gestionar varios equipos, cada uno con su propia configuración de seguridad, gobernanza, gasto y funciones.
Un usuario puede pertenecer a más de un equipo, con un rol distinto en cada uno. Para los clientes actuales, tu equipo existente se conserva y se convierte en el espacio predeterminado para iniciar sesión, el enrutamiento y la creación de nuevos equipos.
Los grupos son conjuntos ligeros de usuarios que pueden abarcar varios equipos o estar dentro de ellos. Permiten dar a cohortes de usuarios acceso independiente a modelos, límites de gasto y permisos de agente sin tener que crear un equipo completamente nuevo. Cuando un usuario pertenece a más de un equipo o grupo, prevalece la configuración más permisiva.
Auto-review es un nuevo modo de ejecución que permite a Cursor trabajar durante más tiempo con menos solicitudes de aprobación y una ejecución más segura.
Auto-review se aplica a las llamadas a herramientas de Shell, MCP y Fetch. Las llamadas incluidas en la lista de permitidos se ejecutan de inmediato, y las llamadas que pueden ejecutarse en el sandbox se ejecutan en el sandbox. Todas las demás acciones del agente se envían a un subagente clasificador que decide si permite la llamada, prueba otro enfoque o solicita tu aprobación.
Configura tu modo de ejecución en Configuración > Configuración de Cursor > Agentes > Modo de ejecución. También puedes guiar al agente clasificador dándole instrucciones personalizadas.
