# Qué pueden hacer por el SEO Jev y Kev, los modelos que solo deciden
*Jev, de TypeSafe, y Kev, una alternativa abierta, responden preguntas cerradas con probabilidades para clasificar y priorizar trabajo. Sus pruebas orientan sobre usos en SEO, pero cada versión y tarea necesita validación propia antes de automatizar decisiones.*
Por Índigo Claudio (IA), revisado por Carlos Sánchez
Publicado el 14 de octubre de 2026, 12:45 · Revisado el 14 de octubre de 2026, 23:26
Jev es un modelo de IA que responde preguntas cerradas: elegir una opción, puntuar o estimar si un enunciado es cierto. Recibe un texto o un JSON y devuelve resultados estructurados con probabilidades; Kev es una alternativa abierta que reproduce esa interfaz. En una auditoría SEO pueden ayudar a clasificar y priorizar tareas repetitivas, después de resolver con reglas lo que no necesita interpretar el texto.
TypeSafe AI lanzó Jev en septiembre de 2026 y lo llama «modelo System One», por el pensamiento rápido de Kahneman. Jared Palmer publicó Kev días después. Para quien trabaja en SEO, la pregunta útil es qué decisiones puede delegar y cómo comprobar que el modelo las toma bien.
## Cómo funcionan y en qué se diferencian
Según [la documentación de TypeSafe](https://docs.typesafe.ai/introduction), cada petición combina un estado con preguntas de tres tipos: `choice`, para elegir entre opciones; `score`, para puntuar con una rúbrica; y `noul`, para estimar entre 0 y 1 si un enunciado es cierto. Se evalúan en paralelo, de forma independiente, sobre el mismo estado. Choice y Score devuelven además una confianza. El «0 % de alucinaciones» del [anuncio de Jev](https://typesafe.ai/blog/introducing-system-one-models-and-jev) se refiere a respetar el formato y las opciones definidos, no a acertar siempre: una respuesta válida puede ser incorrecta.
TypeSafe anuncia 0,042 dólares por millón de tokens de entrada, sin cobrar la salida, y una latencia de 70 a 500 milisegundos. Sus cifras de hasta 193,6 veces más velocidad y 444,6 veces menos coste proceden de pruebas propias de flujos de trabajo. La empresa usa la media de GPT-6 Astra y Fable 5.1 como referencia de respuesta, mide desde la costa oeste estadounidense y advierte de que las ganancias anunciadas están en el extremo alto de lo esperable. Jev es un servicio alojado: los datos enviados a su API se procesan fuera de la máquina del usuario.
[Kev](https://github.com/jaredpalmer/kev) se puede ejecutar en una máquina propia. La familia Kev 1.0 reúne cuatro tamaños con licencia Apache 2.0: los de 0,8, 4 y 9 mil millones de parámetros adaptan Qwen3.5; el de 27 mil millones ajusta todos los pesos de Qwen3.8. Los 51 GB del mayor son el tamaño de sus pesos, no una medida de la memoria necesaria para ejecutarlo: el proyecto recomienda una GPU de 80 GB. El pequeño admite una GPU de 4 GB o un Mac con Apple Silicon. Su API es compatible con el cliente de TypeSafe.
La comparativa de Jose Sabater en [Opper](https://opper.ai/blog/jev-vs-kev-open-decision-model), del 25 de septiembre, enfrentó a Jev 1.13 y al Kev 4B de entonces. Usó 362 elementos posteriores al 20 de septiembre: 160 artículos de arXiv, 120 preguntas de Stack Exchange y 82 incidencias de GitHub, etiquetados según sus fuentes. Opper ofrece ambos modelos en su servicio. PAWS es una comprobación aparte con datos antiguos: Kev no se entrenó con ellos, pero sus autores los usaron para elegir entre entrenamientos.
| Tarea | Jev | Kev 4B |
| --- | --- | --- |
| Categoría de un artículo de arXiv (8 opciones) | 96,9 % | 95,0 % |
| Sitio de Stack Exchange al que pertenece una pregunta (6) | 97,5 % | 98,3 % |
| Una incidencia de GitHub, ¿es un fallo o una petición? (sí/no) | 95,1 % | 93,9 % |
| Detección de paráfrasis (PAWS, conjunto antiguo) | 87,0 % | 74,5 % |
En las tres tareas nuevas, Opper considera las diferencias de acierto compatibles con el ruido de la muestra. El error de calibración fue menor en Jev (0,027–0,049) que en Kev (0,044–0,137): importa al fijar umbrales para automatizar o pedir revisión. Opper también midió unos 257 tokens adicionales por petición en Jev, que encarecían especialmente las entradas cortas.
Estos resultados describen las versiones probadas en septiembre. La advertencia de Opper sobre entrenar con estados de hasta 384 tokens no describe toda la familia actual: la documentación de Kev 1.0 recoge 7.552 para los tres modelos pequeños y 32.768 para el de 27B. Distingue además el contexto admitido del validado sin una caída importante de precisión. Conviene evaluar la versión concreta con documentos propios.
## Hasta dónde llegan
- **Solo texto.** Capturas, PDF y vídeo hay que pasarlos antes a texto. La [Decisions API](https://developers.openai.com/api/docs/guides/decisions) que OpenAI abrió en beta el 6 de octubre, con GPT-6 Luna y las mismas tres preguntas, sí admite imágenes, a 0,10 dólares por millón de tokens de entrada.
- **El estado debe contener la información necesaria.** Los conocimientos aprendidos por el modelo no sustituyen los datos del caso. Para juzgar una página o contrastarla con una fuente, hay que proporcionarle ese material; una respuesta con confianza alta no demuestra por sí sola que sea cierta.
- **Hay que preguntar de otra manera.** Un desarrollador citado por [Fortune](https://fortune.com/2026/10/08/jev-an-ai-for-making-quick-decisions-has-been-a-viral-hit-in-silicon-valley-but-openai-is-hot-on-its-heels/) cuenta que Jev dejaba pasar correos importantes hasta que afinó las preguntas: no valen los prompts de un modelo conversacional.
- **Los datos viajan.** Con Jev, cada petición llega a servidores de TypeSafe en Estados Unidos; la retención de datos cero es para clientes de empresa que la piden. Si los datos no pueden salir, la opción es Kev en una máquina propia.
- **Las cifras son de los fabricantes.** Salvo la prueba de Opper y una medición de latencia de OpenRouter, los números de acierto y velocidad los han publicado TypeSafe y el autor de Kev. Fortune recoge que, en sus primeras 24 horas en Vercel AI Gateway, casi el 13 % de los equipos de pago probaron Jev: mide curiosidad, no resultados.
## Casos de uso en SEO, con un proyecto que ya los ha medido
El ejemplo más trabajado es [jev-seo](https://github.com/AgriciDaniel/jev-seo), una herramienta abierta de Daniel Agrici (licencia MIT) que rastrea un sitio, le pasa 52 reglas ligadas a la documentación de Google, mide Core Web Vitals y pregunta a Jev por cada página. Su registro de preguntas enseña dónde encaja un modelo de decisión en una auditoría:
| Decisión | Cómo se pregunta | Para qué sirve |
| --- | --- | --- |
| Tipo de página | Elección entre 11 opciones (portada, producto, listado, artículo, soporte, legal…) | Filtrar la auditoría y no pedir calidad de contenido a una página de aviso legal |
| Intención de búsqueda | Elección entre informacional, comercial, transaccional, navegacional, local y «no está claro» | Comprobar un siguiente paso claro solo en las comerciales |
| Calidad del contenido | Puntuaciones de 4 niveles de utilidad, concreción y confianza | Señalar qué reescribir, ponderado por la importancia de la página |
| Preparación para respuestas de IA | Puntuación de «citabilidad» y sí/no a «el texto tras el H1 va al grano» | Lo que hoy se llama GEO, convertido en preguntas comprobables |
| Canibalización | Sí/no sobre pares de páginas con títulos parecidos: «¿un buscador las tomaría por sustitutas?» | Detectar dos URL que compiten por lo mismo |
| Título y meta | Puntuación de si describen la página e invitan al clic | Lista de etiquetas que revisar, no etiquetas nuevas |
Lo que lo hace útil no es la lista, sino cómo trata las respuestas. Cada elección se da por buena solo con confianza de 0,80 o más, cada puntuación solo si el 80 % de la probabilidad cae a un lado del umbral, y lo demás sale marcado como «por verificar» en el informe. El autor midió el 22 de septiembre que, en 59 páginas juzgadas dos veces, las puntuaciones se movieron 0,03 de media y los tipos de página seguros coincidieron 44 de 44; frente a un segundo juez ciego, utilidad y concreción coincidieron en 28 de 29 respuestas seguras, y la relevancia de palabras clave en 27 de 30. El segundo juez es otro modelo, no una persona: prueba que Jev es constante y razonable, no que acierte. Y el coste: unos 3.400 tokens por página, 0,00015 dólares; un sitio entero, un céntimo.
Otros usos publicados en [el directorio de proyectos](https://madewithjev.com/jev-for-seo) siguen la misma lógica de filtro: descartar consultas poco naturales y competidores que solo comparten una palabra en una herramienta de palabras clave para la App Store; elegir, entre miles de hilos de Reddit, los que un asistente de IA podría citar; y los detectores de texto generado por IA, que hacen 35 preguntas de sí/no sobre el diseño y el texto de una página por 0,00015 dólares.
De ahí salen usos que nadie ha publicado todavía y que son lectura nuestra: clasificar la intención de miles de palabras clave de Search Console en lotes, triar una bandeja de fuentes («¿esto es SEO o es marketing general?», «¿es una nota de prensa reescrita?»), puntuar los textos alternativos de las imágenes contra una rúbrica, o decidir el destino de un enlace interno entre un puñado de candidatas. En todos, el patrón es el mismo: una decisión cerrada, repetida muchas veces, con opciones que se pueden enumerar.
## No escriben, no consultan datos y no predicen posiciones
No escriben: ni títulos, ni metas, ni un párrafo; para eso hace falta un modelo de texto, y [el propio directorio](https://madewithjev.com/jev-for-seo) lo recuerda. No tienen índice, ni volúmenes de búsqueda, ni grafo de enlaces, así que no sustituyen a una herramienta de datos. Y no predicen posiciones: la auditoría de Agrici lo dice en su primera página, «scores rank work; they never predict rankings or traffic». Un modelo que solo ve el texto de una página no sabe nada de los enlaces que recibe ni de lo que hacen sus competidoras.
## Si una regla lo decide, un condicional gana en velocidad, coste y exactitud
El propio [anuncio de TypeSafe](https://typesafe.ai/blog/introducing-system-one-models-and-jev) sitúa a Jev en las reglas difusas: clasificar, puntuar, extraer o bifurcar allí donde escribir la lógica a mano resultaría demasiado frágil. Esa frontera tiene un reverso, y es lectura nuestra: donde la lógica no es frágil, el modelo sobra.
Si la respuesta está en algo que el código puede leer, como una cabecera, una etiqueta o un atributo, un condicional da siempre la misma respuesta, al instante, sin coste y sin sacar datos de tu máquina, y se puede auditar línea a línea.
Un modelo da una probabilidad, tarda lo que tarda una llamada a un servicio externo, se paga por poco que sea y puede equivocarse con confianza alta. Gastar eso en algo que resuelve un `if` es pagar para tener menos certeza.
La frontera, según nuestra lectura:
| Decisión | Se resuelve mejor con | Por qué |
| --- | --- | --- |
| ¿La URL devuelve 200, redirige o da 404? | Código | Lo dice la cabecera de la respuesta |
| ¿Hay noindex, un canonical distinto de la URL o un bloqueo en robots.txt? | Código | Son etiquetas y directivas que se leen tal cual |
| ¿Faltan el H1, el título o la meta description, o están duplicados letra por letra? | Código | Es contar y comparar texto |
| ¿El título pasa de cierta longitud, el alt está vacío o un enlace interno apunta a una URL que da 404? | Código | Un umbral o una comparación |
| ¿La URL está en el sitemap, o la página no recibe ningún enlace interno? | Código | Es cruzar dos listas |
| ¿Es una página de producto o de blog, cuando las URL siguen un patrón? | Código | Una expresión regular basta; el modelo entra cuando no hay patrón |
| ¿El título describe lo que hay en la página? | Modelo | Depende de lo que significa el texto |
| ¿Dos páginas son sustitutas para un buscador? | Modelo, tras preseleccionar con código | El código encuentra los pares parecidos; decidir si compiten exige entender el texto |
| ¿La intención de una consulta es comercial o informativa? | Modelo | La misma consulta admite lecturas distintas |
Una prueba que sirve de guía, también nuestra: si la regla cabe en una línea y no hace falta decir «depende», es código. Si cada intento de escribirla trae excepciones, o la respuesta depende de lo que quiere decir un texto, es un caso para un modelo.
Tampoco conviene forzar el condicional donde no cabe: una lista de palabras como «comprar» o «precio» para adivinar la intención acierta con las consultas obvias y falla con el resto, que es justo la lógica frágil para la que existen estos modelos.
Los proyectos que publican cómo reparten el trabajo hacen esa división. [jev-seo](https://github.com/AgriciDaniel/jev-seo) rastrea y aplica sus reglas con código, en local y sin coste, y su [registro de preguntas](https://github.com/AgriciDaniel/jev-seo/blob/main/references/judgments.md) fija como norma que el código no le pregunte al modelo lo que puede ver: sin meta description no hay pregunta sobre si encaja, y sin H1 tampoco sobre el H1.
Con las páginas que se canibalizan, jev-seo hace lo mismo: el código preselecciona los pares con títulos parecidos y solo esos llegan al modelo. En [el directorio de proyectos](https://madewithjev.com/jev-for-seo) está el mismo reparto en Sniff Test, un linter de textos escritos con IA que usa expresiones regulares para lo evidente y Jev para el juicio.
Filtrar antes con código también recorta la factura: cada página que una regla descarta es una llamada menos al modelo.
## Cuatro actualizaciones antispam en un año y una guía de IA que pide revisar a mano
El contexto en el que llegan estos modelos lo ha puesto Google. En 2026 lleva cuatro actualizaciones antispam (marzo, junio, agosto y [la de septiembre](https://seomanal.es/posicionamiento/google-da-por-terminada-la-actualizacion-antispam-de-septiembre-tras-casi-dos-semanas/), que empezó el 24 y tardó catorce días en cerrarse), frente a una en todo 2025. En el Search Central Live de Barcelona, el 2 de octubre, Duy Nguyen atribuyó la frecuencia a que se publica mucho más contenido nuevo, y Gary Illyes avisó de que [el contenido generado a escala empieza a ser un problema mayor que el spam de enlaces](https://seomanal.es/posicionamiento/google-lanza-mas-actualizaciones-antispam-porque-hay-mas-contenido/). La política de abuso de contenido a gran escala persigue las páginas hechas en masa para posicionar y no para ayudar, «independientemente de cómo se haya creado» el contenido, y desde mayo vale también para quien intente manipular las respuestas generativas de la Búsqueda.
El 1 de octubre, Google cambió además dos páginas de su documentación. [La guía de contenido útil](https://seomanal.es/posicionamiento/google-llama-engano-a-los-autores-inventados-en-su-guia-de-contenido/) dice ahora que sus evaluadores juzgan el contenido principal por esfuerzo, originalidad, habilidad y exactitud, y pone como ejemplo de poco o ningún esfuerzo generar páginas a partir de feeds o de texto masivo con IA sin supervisión; inventar autores con fotos y credenciales generadas es, en sus palabras, un engaño. Y la guía sobre contenido generado con IA recuerda que los modelos no recuperan datos sino que predicen palabras, y califica de «crítico» comprobar y revisar a mano todo lo que generen antes de publicarlo, también los títulos, las descripciones, los datos estructurados y los textos alternativos. John Mueller añadió en septiembre el coste de ignorarlo: un directorio que cruzaba dominios y tecnologías [perdió la confianza de Google para todo el dominio](https://seomanal.es/tecnico/indexacion/google-puede-perder-la-confianza-en-una-web-por-su-seo-programatico/), y recuperarla se mide en meses.
## Dónde ahorran tiempo sin que el contenido sea perezoso
Un modelo de decisión no puede escribir una página de relleno, porque no escribe. Ese límite, que parece un defecto, es lo que lo hace compatible con lo que pide Google: el tiempo que ahorra es el de clasificar, triar y comprobar, no el de redactar. Lo que sigue es nuestra lectura de cómo usarlos sin caer en lo que las actualizaciones antispam castigan.
- **Decidir qué páginas no deberían existir.** La pregunta «mantener, reescribir o fusionar» de jev-seo, pasada por todo un catálogo generado a partir de datos, es una forma barata de hacer lo que Mueller pedía al directorio: contar cuántas URL aportan algo propio y quedarse solo con ellas. El modelo decide dónde mirar; borrar o fusionar sigue siendo decisión humana.
- **Convertir la revisión obligatoria en una lista de comprobaciones.** Google pide revisar a mano lo que genera una IA. Un modelo de decisión no sustituye esa revisión, pero la ordena: «¿la meta describe lo que entrega la página?», «¿el texto tras el H1 va al grano?», «¿este párrafo afirma algo que no está en la fuente?», con su probabilidad, y la persona revisa primero lo que sale con confianza baja o con respuesta negativa.
- **Repartir el esfuerzo humano.** Si Google va a juzgar el esfuerzo y la originalidad, las puntuaciones de utilidad, concreción y confianza sirven para decidir en qué páginas invertir horas de alguien que sabe del tema, y en cuáles no merece la pena. Es lo contrario de usar la IA para producir más: es usarla para producir menos y mejor.
- **Clasificar lo que antes se hacía a mano o no se hacía.** Intención de miles de consultas, tipo de página, pares que se canibalizan, textos alternativos que no describen la imagen. Son tareas que nadie va a hacer a mano en un sitio de 20.000 URL y que, hechas con un modelo de decisión, cuestan céntimos y dejan un registro con su probabilidad.
La trampa está en la otra dirección: usar el modelo para dar por buena en masa la calidad de páginas generadas en masa. Un «útil, 0,91» de Jev no es el juicio de un evaluador de Google ni de un lector, y nada en estas pruebas dice que correlacione con el posicionamiento. Si una página se publica porque un modelo de decisión la aprobó y nadie la leyó, el flujo es exactamente el que la guía de Google describe como poco esfuerzo, solo que con un paso más.
## Qué hacer antes de meterlos en un flujo
1. Separar lo que decide una regla de lo que decide el modelo: comprobar con código todo lo que se pueda leer en la página (estado, etiquetas, longitudes, duplicados exactos) y preguntar al modelo solo por lo que depende del significado.
2. Reunir un centenar de casos etiquetados a mano (intenciones, tipos de página, lo que sea) y medir el acierto del modelo y su calibración antes de automatizar nada. Las diferencias de pocos puntos entre Jev y Kev están dentro del ruido; la diferencia con un etiquetado propio no.
3. Dar siempre una opción de escape («otra», «no está claro») y fijar un umbral de confianza por debajo del cual la decisión va a una persona.
4. Enviar solo los campos que la pregunta necesita, recortar el texto (jev-seo lo corta a 6.000 caracteres) y quitar datos personales que no influyan en la decisión.
5. Probar dos redacciones de cada pregunta sobre los mismos casos: en jev-seo, reformular «tipo de página» con opciones estructuradas subió la coincidencia de 20 a 27 sobre 30.
6. Si los textos no pueden salir de la empresa, valorar Kev en una máquina propia. Si el flujo depende de umbrales finos, medir la calibración con ejemplos propios: la ventaja de Jev en la prueba de Opper corresponde a aquellas versiones y tareas.
*Actualización del 14 de octubre de 2026: aclaramos las versiones evaluadas por Opper y corregimos la generalización sobre el entrenamiento de Kev con entradas cortas. También distinguimos el tamaño de los pesos de la memoria necesaria para ejecutar el modelo.*
## Referencias
1. Agrici, D. (2026, 22 de septiembre). *How far to trust it (jev-seo)*. GitHub. (Repetibilidad (59 páginas dos veces) y coincidencia con un segundo juez ciego, que es otro modelo.)
2. Agrici, D. (2026, 22 de septiembre). *Jev judgment registry (jev-seo)*. GitHub. (Cada pregunta que la auditoría hace a Jev, con sus opciones y umbrales; de aquí sale la tabla de casos de uso.)
3. Agrici, D. (2026, 22 de septiembre). *jev-seo: live SEO audit judged by Jev*. GitHub. (La auditoría abierta (MIT, 588 estrellas el 13-10-2026): reglas, preguntas a Jev, umbrales de «por verificar» y coste por página.)
4. Almeida, D. (2026, 15 de septiembre). *Introducing System One Models & Jev*. TypeSafe AI. (fuente principal)
5. developers.openai.com (s. f.). *Decisions (OpenAI developer docs)*. (Beta pública con gpt-6-luna, predicate/choice/score, imágenes en base64, 0,10 dólares por millón de tokens de entrada.)
6. docs.typesafe.ai (s. f.). *Introduction (TypeSafe docs)*. (Los tres tipos de pregunta (choice, score, noul), el estado y la confianza.)
7. docs.typesafe.ai (s. f.). *Quickstart (TypeSafe docs)*. (Endpoint POST /v1/systemone, modelo jev-latest (jev-1.13.0 en la respuesta) y SDKs.)
8. madewithjev.com (s. f.). *Jev for SEO and GEO: 16 builds, and what they cost*. (Directorio de proyectos; lista lo que Jev no hace (no escribe, no tiene índice ni backlinks, solo texto).)
9. news.ycombinator.com (s. f.). *Kev: Tiny Jev-like family of decision models built on top of Qwen3.5 (Hacker News)*. (Hilo de 210 comentarios: la crítica de que un esquema garantizado no evita una respuesta válida pero equivocada.)
10. Palmer, J. (s. f.). *Kev: small decision models built on Qwen*. GitHub. (README consultado por Gema el 14-10-2026: familia Kev 1.0, pesos y hardware, estados de entrenamiento de 7.552/32.768 tokens y contexto validado. Las capacidades actuales no deben confundirse con el Kev 4B evaluado por Opper en septiembre.)
11. Sabater, J. (2026, 25 de septiembre). *Jev vs. Kev: an open-source Jev alternative, tested side by side*. opper.ai. (Prueba original de Opper, proveedor que ofrece ambos modelos, revisada el 14-10-2026: Jev 1.13 y Kev 4B de septiembre; 362 elementos nuevos y PAWS aparte. La observación sobre 384 tokens corresponde a la versión de entonces.)
12. Shao, W. (2026, 8 de octubre). *Jev, an AI for making quick decisions, has been a viral hit. But OpenAI is hot on its heels*. fortune.com. (Fundadores y ronda de 40 millones, el 13 % de equipos de pago en Vercel AI Gateway, la Decisions API de OpenAI y la cita del desarrollador sobre cómo preguntar.)
13. Spector, I. (2026, 8 de octubre). *The Jev Hype, Tested: What TypeSafe's Decision Model Gets Right (and Wrong) in a Real Repo*. medium.com. (Prueba en un repositorio real: dónde van los datos (sin versión local de Jev, ZDR solo para empresas), la medición de latencia de OpenRouter y el matiz del 0 % de alucinaciones.)
14. Taneja, R. (2026, 21 de septiembre). *AI Gateway now supports TypeSafe clients and an HTTP API for Jev*. vercel.com. (Las tres vías para llamar a Jev desde AI Gateway. (Autoría: Rohan Taneja y Jerilyn Zheng.))
15. typesafe.ai (s. f.). *TypeSafe AI*. (Precio (42 dólares por mil millones de tokens de entrada) y la afirmación de velocidad de la propia empresa.)