Volver a las guías
Configuración·21 de septiembre de 2026·Actualizado el 24 de septiembre de 2026·10 min de lectura

Los modelos de Hermes Ollama no aparecen: comprobaciones del catálogo y del proveedor

El modelo está en Ollama pero no aparece en el selector. Algunas causas están corregidas, otras siguen abiertas y otras no son defectos; cada una deja una señal distinta.

Última revisión: .

Si tus modelos de Ollama han desaparecido del selector de Hermes, comprueba primero la versión antes de tocar la configuración: el error de caché del catálogo nativo que produce exactamente este síntoma se cerró como completado el 17 de septiembre de 2026, y su solución está incluida en la etiqueta v2026.9.21 (hermes-agent 0.21.4), pero no en v2026.9.14. Sin embargo, ese informe cerrado no cuenta toda la historia. El 21 de septiembre de 2026 seguían abiertos otros dos informes sobre modelos de Ollama ausentes de un selector; un tercer issue abierto describe un mecanismo de Hermes Desktop que produce el mismo síntoma en cualquier proveedor cuya lista de modelos visibles se haya personalizado alguna vez, y al leer el código distribuido en esa misma etiqueta observé que el comportamiento seguía presente. Una cuarta causa común no es un defecto en absoluto. Cada causa deja una señal distinta, y esta página sirve para identificarlas.

Primero, dos aclaraciones, porque ambas se mezclan en los resultados de búsqueda. Hermes Agent es el agente de Python de Nous Research (MIT, no archivado, con el último push el 21 de septiembre de 2026 según la API de GitHub). Hermes 3 y Hermes 4 son la familia de LLM de pesos abiertos del mismo laboratorio, un producto completamente distinto; además, existe un motor de JavaScript no relacionado llamado Hermes: ninguno de sus números de versión se aplica aquí. Y Ollama local no es Ollama Cloud: Hermes accede al entorno de ejecución local gratuito en el puerto 11434 mediante su flujo Custom Endpoint, mientras que Ollama Cloud es un producto de pago independiente, implementado como un slug de proveedor propio con su propio archivo de caché. Que falte un modelo en uno no dice nada sobre el otro.

Deben coincidir tres capas, y solo una de ellas es Ollama

«El modelo no está en el selector» es una afirmación sobre la última de tres capas, y el diagnóstico consiste en encontrar la primera que no coincide.

CapaQué comprobarCómo se manifiesta el fallo
El propio catálogo de Ollama/api/tags de forma nativa y /v1/models en la interfaz compatible con OpenAIEl modelo realmente no está disponible o se eliminó después del listado que estás consultando
Descubrimiento y caché de HermesQué ruta de consulta cumple el endpoint y qué contiene provider_models_cache.jsonEl endpoint está operativo y el selector sigue mostrando cero modelos para él
La interfaz del selectorCLI hermes model frente al menú de modelos del escritorioLa CLI es correcta y el menú del escritorio no, o el grupo del proveedor desaparece por completo
Dos listados, dos rutas de código
# 1. Does Ollama itself list the model? This is the native catalog
#    Hermes reads when the endpoint qualifies for the /api/tags branch.
curl -s http://127.0.0.1:11434/api/tags | jq '.models[].name'

# 2. Does the OpenAI-compatible surface list it too? This is what a
#    generic custom endpoint is probed on.
curl -s http://127.0.0.1:11434/v1/models | jq '.data[].id'

Un aspecto que conviene descartar en la primera capa: ollama list incluye modelos de embeddings, y un modelo de embeddings no es un modelo de chat que un agente de programación pueda seleccionar. Kunavo tampoco ofrece modelos de embeddings, de texto a voz ni de voz a texto, por lo que una ruta alojada no soluciona aquí esa carencia.

Comprueba primero tu versión y léela con atención

El issue #112898 —«la lista de modelos locales de Ollama parpadea en el selector»— está cerrado como completado; se abrió el 16 de septiembre de 2026 y se cerró el 17 de septiembre de 2026. El pull request #113129 fusionó la solución como el commit d6d6565, y una comparación de GitHub sitúa ese commit dentro de la etiqueta v2026.9.21 y fuera de v2026.9.14: comparar v2026.9.21…d6d6565 devuelve el estado behind con cero commits por delante, por lo que el commit es un ancestro de esa etiqueta, mientras que v2026.9.14…d6d6565 devuelve el estado ahead con cero commits por detrás, por lo que la etiqueta es un ancestro del commit, y no al revés. El #112900 propio del colaborador sigue abierto, lo que no indica que falte la solución en main: su contenido se incorporó mediante cherry-pick, conservando la autoría, en el pull request fusionado. Todos los estados se consultaron en la API de GitHub el 21 de septiembre de 2026.

Aquí está la trampa. Dentro de esa misma etiqueta se distribuyen dos números de versión distintos: en v2026.9.21, pyproject.toml indica version = "0.21.4", mientras que apps/desktop/package.json indica "version": "0.17.6". Por tanto, un informe de errores titulado «Hermes Desktop 0.17.6» describe una compilación actual, no una antigua; descartar ese informe por obsoleto haría que la fecha de tus propias pruebas fuera incorrecta. Observa también el límite de esta comprobación de versión: se trata de la inclusión de un commit en una etiqueta de git. Aquí no se verificó si la versión de pip, la fórmula de Homebrew, la imagen del contenedor o el canal de actualización automática del escritorio que instalaste incluyen ese commit.

Cinco causas y la señal que las distingue

CausaLa señal distintivaEstado el 21 de septiembre de 2026
El catálogo nativo de Ollama nunca se escribió en la caché compartida del selectorLa lista parpadea: es correcta justo después de una consulta, pero está vacía en la siguiente apertura normalSolucionado: #112898, en 0.21.4, en la etiqueta v2026.9.21
Instantánea de hermes.desktop.visible-models del escritorio congelada en localStorage, en un proveedor cuya lista se personalizó una vezLa búsqueda sigue encontrando el modelo y la selección activa sigue mostrándose; solo el menú lo omiteAbierto: #107391, presentado sobre Copilot y la segunda de sus dos causas; comportamiento observado en el código distribuido v2026.9.21
Varias filas de proveedores que comparten una URL base con claves distintasAlgunos proveedores configurados se muestran y otros desaparecen del selectorSolucionado: #106184, cerrado el 9 de septiembre de 2026, incluido desde 0.21.2
El endpoint no cumple los requisitos de la rama nativa /api/tagsCero modelos en una entrada custom con un nombre explícito que no está en el puerto 11434 y no coincide con la URL base de Ollama configuradaComportamiento documentado, no un defecto
Ventana de contexto local inferior al mínimo de HermesUn rechazo durante el inicio que indica la ventana servida; no se trata de un selector vacíoComportamiento documentado; no lo combines con lo anterior

Dos de esas causas merecen su propia explicación. El bloqueo del escritorio es el que más fácilmente se interpreta erróneamente como un problema de caché: al leer apps/desktop/src/store/model-visibility.ts en la etiqueta v2026.9.21, una vez que un proveedor tiene claves almacenadas, el renderizador deja de fusionar por completo los valores predeterminados del proveedor, por lo que los modelos descubiertos posteriormente nunca entran en el menú. El issue #114369 reprodujo exactamente eso en un proveedor personalizado con discover_models: true y se cerró como duplicado, no como solucionado; su reproducción utilizó un endpoint de vLLM, así que considera el mecanismo independiente del proveedor, no una reproducción de Ollama. Otros dos issues siguen abiertos y sin resolver: #89874 (cero modelos para un proveedor personalizado de Ollama, con la etiqueta needs-repro, por lo que es un informe no confirmado y no un defecto establecido) y #71169 (modelos presentes en la API de Ollama, ausentes del menú desplegable del escritorio). No se ha establecido si alguno comparte una causa raíz con #112898.

El síntoma del escritorio también es más específico de lo que se suele esperar. En model-catalog-menu.tsx en esa etiqueta, se omite directamente un proveedor cuya lista de familias contraída está vacía; por eso la queja suele ser «mi proveedor desapareció» en lugar de «mi proveedor muestra una lista vacía».

Por qué una apertura normal del selector muestra una lista obsoleta

Este es el mecanismo subyacente a toda esta clase de fallos, y merece la pena entenderlo una vez. En una apertura normal del selector, solo se consulta en directo el endpoint personalizado actual; todos los demás endpoints configurados se responden desde la caché de disco en $HERMES_HOME/provider_models_cache.json. HERMES_HOME tiene ~/.hermes como valor predeterminado, pero se puede sobrescribir, así que no des por supuesta la ruta. En hermes_cli, en la etiqueta v2026.9.21, tres ventanas regulan las nuevas consultas:

VentanaValorQué regula
TTL genérico del catálogoUna horaDurante cuánto tiempo se considera reciente el listado almacenado en caché de cualquier proveedor
TTL del catálogo nativo de Ollama300 segundosEspecíficamente, el listado de /api/tags
Ventana de servicio de datos obsoletosSiete díasDurante cuánto tiempo puede seguir mostrándose un listado caducado en lugar de descartarse

Son constantes internas del código fuente, no configuraciones documentadas; en esta comprobación no apareció ningún control visible para el usuario sobre estas tres. Conviene conocer una excepción deliberada de ese código: un catálogo nativo vacío solo se considera autorizado dentro del TTL corto y nunca se sirve como obsoleto, precisamente para que un Ollama que no tenía modelos en la primera apertura no oculte uno recién descargado durante toda la ventana de siete días. Además, las filas de caché se indexan mediante la URL normalizada más una huella de la credencial, el modo de API y las cabeceras adicionales, porque varias filas de proveedores pueden compartir legítimamente una URL de proxy con claves distintas. La consecuencia práctica es que rotar una clave, cambiar el transporte o editar extra_headers invalida la entrada de caché de esa fila, y la siguiente apertura sin consulta muestra una lista vacía hasta que algo la actualiza.

Las comprobaciones, en orden

  1. Confirma que Ollama lo tiene. Ejecuta los dos curls anteriores. Si /api/tags no muestra el modelo, nada posterior puede hacerlo.
  2. Confirma la versión. Si usas una compilación anterior a la etiqueta v2026.9.21 y el síntoma es una lista que alterna entre correcta y vacía, estás ante un error que ya se ha corregido: actualiza antes de depurar.
  3. Fuerza una actualización. El indicador --refresh de hermes model declara en su propia ayuda que borra la caché del selector en disco y vuelve a obtener la lista activa de cada proveedor; ten en cuenta que borra la de todos los proveedores, no la de uno solo. En la sesión, la referencia de comandos de barra documenta /model --refresh como la acción que vuelve a obtener la lista de modelos del proveedor, y la aplicación de escritorio tiene un control explícito «Refresh Models» que solicita un catálogo nuevo, mientras que las aperturas normales mantienen la caché de una hora.
  4. Comprueba qué ruta de sondeo recibe tu endpoint. La rama nativa /api/tags se toma cuando el proveedor se llama ollama, cuando el nombre es custom:ollama o termina en -ollama, cuando la URL coincide con la URL base de Ollama configurada, o cuando una URL personalizada ambigua en el puerto 11434 responde realmente a /api/tags. Un Ollama servido en otro puerto con un nombre simple custom pasa en cambio al sondeo genérico /v1/models; eso es lo que indica que hace la ruta del código, y aquí no se ejecutó para confirmar que la alternativa funcione en la práctica.
  5. Si el problema está en el descubrimiento, deja de descubrir. discover_models tiene el valor predeterminado true; establecerlo en false hace que el selector muestre la lista que configuraste en lugar de realizar un sondeo activo.
  6. Si solo está equivocado el menú de escritorio, lo más probable es que estés ante el caso #107391, que ninguna actualización puede solucionar: el backend devuelve el modelo y la capa de curación del renderizador lo descarta.
~/.hermes/config.yaml — estructura obtenida de la documentación propia de Hermes, 21 de septiembre de 2026
providers:
  # The published reference documents `api` for a providers entry.
  local-ollama:
    api: http://127.0.0.1:11434/v1
    # No key for local Ollama. Discovery is on by default; turn it off and
    # hand-write the list when the probe is the thing that is failing.
    discover_models: false
    models:
      - qwen3-coder:30b

model:
  default: qwen3-coder:30b
  provider: custom:local-ollama

Hay un detalle de configuración que confunde repetidamente a la gente y conviene dejar resuelto. La referencia documenta api como la clave de URL base para una entrada providers:, y la lista de campos de esa entrada nombra base_url y url como alias aceptados para ella; base_url es, por separado, la clave dentro del mapeo de nivel superior model:. También registra que las configuraciones antiguas usaban una lista custom_providers: de nivel superior con base_url en lugar de api, que sigue funcionando y se migra automáticamente mediante hermes update en la versión de configuración v12. Los informes de errores del rastreador están escritos de ambas formas, justo lo esperable cuando ambas se leen. Por tanto, es improbable que una entrada providers: que no surte efecto esté fallando por el nombre de esta clave; revisa el endpoint y los demás campos de la entrada.

Vale la pena mencionar otro detalle: la página de Hermes de Ollama explica el aviso de configuración como «Context length in tokens [leave blank for auto-detect]», mientras que la documentación de proveedores de Hermes exige al menos 64,000 tokens para el uso por parte de agentes y dice que un endpoint local que sirva menos se rechaza al iniciar. Ambas se comprobaron el 21 de septiembre de 2026. Dejar el campo en blanco no es incorrecto por sí mismo, pero no soluciona nada si el servidor solo sirve una ventana pequeña; por eso, aumenta la ventana en el servidor (o fíjala en la configuración de Hermes) al número de Hermes, y recuerda que este fallo produce un rechazo durante el inicio que menciona la ventana servida, no una fila ausente en el selector.

Verifícalo y decide si lo local merece la pena

Después de un cambio, haz tres cosas en orden: vuelve a abrir el selector sin --refresh y confirma que el modelo aparece en una apertura en frío, selecciónalo y envía una solicitud acotada que devuelva una finalización. El paso intermedio importa porque una lista que solo es correcta inmediatamente después de un sondeo es la señal del error de caché, no una solución. Estas son instrucciones para que las ejecutes tú; al redactar esta página no se probó ninguna instalación de Hermes, instancia de Ollama ni selector.

Si la respuesta es que lo local no compensa el esfuerzo para esta tarea, la cuestión económica se divide claramente en dos: cuánto cuesta el software y cuánto cuesta el uso del modelo.

PartidaCostoFuente, comprobado el 21 de septiembre de 2026
El propio Hermes Agent$0, MITPreguntas frecuentes del proyecto y el campo de licencia del repositorio
Modelos de Ollama en tu propio hardware$0, ilimitadoPrecios de Ollama: nivel gratuito
Ollama Cloud Pro / Max / Team$20 / $100 / $500 al mesPrecios de Ollama: un proveedor separado en Hermes, no esta configuración local
Nous Portal Plus / Super / Ultra$20 / $100 / $200 al mesPlanes de Portal; opcional, no necesario para ejecutar el agente
KunavoSin suscripción; crédito prepagoRecarga mínima de $10, cobrada por token

El nivel Pro de Ollama Cloud también aparece con un precio de $200 al año, facturado anualmente, y sus planes incluyen créditos de uso mensuales: $60 en Pro, $300 en Max y $1,000 compartidos en Team. Estos corresponden al producto en la nube, no al endpoint local que estás reparando.

Para la ruta con cobro por uso, aquí tienes una aritmética ilustrativa de tokens, no el coste medido de una tarea ni un límite de facturación. Supón una sesión que envía 200,000 tokens de entrada sin caché y recibe 12,000 tokens de salida, sin lecturas de caché ni cargos por herramientas externas. Las tarifas son los precios actuales del catálogo de Kunavo por millón de tokens.

ModeloEntrada/salida por 1MEstimación para esa sesión
Claude Haiku 4.5$0.70 / $3.50$0.182
Claude Sonnet 5$1.40 / $7.00$0.364

Multiplica por tus propias sesiones diarias antes de considerar esa cifra un presupuesto, y ten en cuenta que la tarifa más barata de la lista y el menor coste para terminar la tarea son afirmaciones distintas: un modelo barato que necesita tres intentos puede costar más que uno que necesita uno. El importe del catálogo de Kunavo es un mínimo de facturación, no un límite máximo: cuando el proveedor ascendente comunica su cargo, la factura es el mayor de entre el coste del catálogo y el coste del proveedor ascendente multiplicado por el margen aplicable. Consulta los detalles de facturación.

La ruta ganadora depende del trabajo. Ollama local gana para tareas pequeñas, privadas o sin conexión, sin cargo por solicitud, con el hardware y el mínimo de 64,000 tokens como limitaciones reales. Una API directa del proveedor gana cuando trabajas con el modelo insignia de un proveedor y quieres sus propias condiciones de caché y lotes. Una pasarela gana cuando cambias de modelo según la tarea y quieres una sola clave y un solo saldo. Una suscripción gana cuando el uso intensivo diario a tarifa fija te conviene más que pagar tokens según el consumo.

Dirigir Hermes a otro lugar

Si decides añadir un endpoint alojado junto al local, los mecanismos son los mismos del flujo de proveedor personalizado, y conviene conocer un límite antes de intentarlo: añadir un proveedor se hace mediante hermes model y se ejecuta fuera de una sesión, porque /model dentro de la sesión cambia entre proveedores ya configurados y no puede añadir uno ni aceptar una clave. La API personalizada de Hermes Agent explica detalladamente la estructura de la entrada, los transportes y la reversión; los precios de Hermes Agent cubren las cuatro facturas separadas. Kunavo publica referencias de configuración, no pruebas de compatibilidad: Hermes nunca se probó en tiempo de ejecución contra el endpoint de Kunavo en este trabajo, así que nada de lo anterior demuestra que el descubrimiento de Hermes funcione contra él. Mantén operativa tu ruta actual mientras lo pruebas. La API compatible con OpenAI de Ollama explica por qué el mismo código cliente llega a ambos, y crea una cuenta de Kunavo cuando quieras cargar fondos en una clave.

¿Sigues eligiendo un cliente en lugar de depurar uno? Alternativas a Hermes Agent y la API compatible con OpenAI cubren el panorama más amplio.

Preguntas frecuentes

¿Por qué no aparecen mis modelos de Ollama en Hermes?

Varias causas distintas producen este síntoma, y se distinguen por el síntoma, no por la configuración; esta página separa las siguientes. Una ya está solucionada: un catálogo nativo de Ollama que nunca se escribió en la caché compartida del selector, registrado como el issue #112898 de hermes-agent, cerrado como completado el 17 de septiembre de 2026, cuya solución está incluida en la etiqueta v2026.9.21 (hermes-agent 0.21.4), pero no en v2026.9.14. Seguían abiertas el 21 de septiembre de 2026: la instantánea de modelos visibles de Hermes Desktop que congela el conjunto de modelos de un proveedor en localStorage (#107391 — un informe sobre modelos de GitHub Copilot y la segunda de las dos causas que menciona; el mecanismo en sí no está vinculado a un único proveedor), un proveedor personalizado de Ollama cuyo selector /model muestra cero modelos (#89874, con la etiqueta needs-repro) y modelos presentes en la API de Ollama pero ausentes del menú desplegable del escritorio (#71169). Hay otra causa que no es un error en absoluto: una entrada personalizada con un nombre explícito que no está en el puerto 11434 y cuya URL no coincide con la configuración providers.ollama.base_url no utiliza la rama nativa /api/tags de Hermes, por lo que se consulta en /v1/models; en cambio, una entrada llamada custom:ollama, o cuyo nombre termina en -ollama, utiliza la rama nativa independientemente del puerto.

¿Se solucionó el error del selector de Ollama de Hermes y en qué versión?

Sí, para el informe específico. El issue #112898 describía un endpoint local de Ollama configurado cuyo catálogo nativo nunca se incorporaba a provider_models_cache.json, por lo que cualquier apertura del selector que no lo consultara en directo lo mostraba vacío. El pull request #113129 se fusionó el 17 de septiembre de 2026 como el commit d6d6565, y una comparación de GitHub muestra que dicho commit está incluido en la etiqueta v2026.9.21 y ausente de v2026.9.14. El pull request propio del colaborador, #112900, sigue abierto, lo que no demuestra que falte la solución: su contenido se incorporó mediante cherry-pick, conservando la autoría, en el pull request fusionado. Esto demuestra la inclusión del commit en una etiqueta de git; aquí no se comprobó si el paquete pip, la fórmula de Homebrew, la imagen de Docker o el canal de actualización automática del escritorio que instalaste lo incluyen.

¿Por qué hermes model --refresh muestra mis modelos, pero /model no?

Porque una apertura normal del selector no consulta todos los endpoints. Solo se obtiene en directo el endpoint personalizado actual; todos los demás endpoints configurados se responden desde la caché de disco en $HERMES_HOME/provider_models_cache.json. Por tanto, una fila de caché vacía o cuyo identificador de credencial ya no coincide muestra cero modelos aunque el endpoint esté operativo. El texto de ayuda propio de la opción hermes model --refresh indica que borra la caché de disco del selector de modelos y vuelve a obtener el listado activo de todos los proveedores, por lo que la ejecución actualizada se ve correctamente y la siguiente apertura normal no. Esa opción aparece en el analizador de argumentos del comando; no se encontró en la página publicada de referencia de comandos de la CLI, así que considera el texto de ayuda su fuente.

Mi modelo aparece en Ollama, pero no en el menú de Hermes Desktop. ¿Es el mismo error?

Probablemente no, y hay una señal distintiva. El issue #107391 se presentó sobre modelos de GitHub Copilot y menciona dos causas acumulativas; la relevante aquí es la segunda: un conjunto de modelos visibles almacenado en el localStorage del renderizador de escritorio, bajo la clave hermes.desktop.visible-models. Una vez que un proveedor tiene claves almacenadas, ese conjunto se respeta exactamente y los modelos recién descubiertos nunca se fusionan con él. Al leer apps/desktop/src/store/model-visibility.ts en la etiqueta v2026.9.21, el 21 de septiembre de 2026, ese comportamiento seguía presente en el código fuente distribuido y el issue seguía abierto. La señal distintiva es que la búsqueda sigue encontrando el modelo y la selección activa sigue mostrándose, mientras que el menú no lo incluye. El issue #114369 reprodujo el mismo mecanismo en un proveedor personalizado con discover_models true y se cerró como duplicado, no como solucionado; además, utilizó un endpoint de vLLM en lugar de Ollama, por lo que el mecanismo es independiente del proveedor, pero esa reproducción concreta no corresponde a Ollama.

¿Una entrada de proveedor de Hermes utiliza api o base_url para la URL del endpoint?

Cualquiera de las dos. La referencia de configuración publicada documenta api como la URL base del endpoint para una entrada bajo providers:, y la lista de campos de esa entrada denomina base_url y url como alias aceptados para ella. base_url es, por separado, la clave del mapeo model: de nivel superior. La misma documentación indica que las configuraciones antiguas utilizaban una lista custom_providers: de nivel superior con base_url en lugar de api, y que sigue funcionando y se migra automáticamente al diccionario providers: al ejecutar hermes update en la configuración v12. Los informes de errores del tracker están redactados de ambas formas, lo que coincide con que se lean las dos. Por tanto, la ortografía de esta clave es una explicación poco probable para que una entrada de providers no surta efecto; revisa el endpoint y los demás campos de la entrada.

¿Solucionar esto cuesta algo?

No. Hermes Agent es gratuito y tiene licencia MIT: sus preguntas frecuentes indican que solo pagas por el uso de la API de LLM del proveedor elegido y que los modelos locales son completamente gratuitos de ejecutar; ejecutar modelos de Ollama en tu propio hardware es gratuito según la propia página de precios de Ollama, comprobada el 21 de septiembre de 2026. Cada cifra en dólares que pudiera asociarse a este problema corresponde a otra cosa a la que podrías cambiarte: los planes de Ollama Cloud, que Hermes trata como un identificador de proveedor independiente de primera clase, una suscripción a Nous Portal o una clave de API con medición. Kunavo no vende nada de eso como suscripción; ofrece crédito prepagado con una recarga mínima de $10.

Lo que se comprobó el 21 de septiembre de 2026 y cómo: los estados de incidencias y solicitudes de extracción, la inclusión de las etiquetas para ambas correcciones, la etiqueta de la versión más reciente y el estado de licencia y archivo del repositorio procedían de la API de GitHub; las constantes de caché, el control del descubrimiento, el almacén de visibilidad del escritorio, la cadena de ayuda --refresh y las citas de la documentación se leyeron del código fuente en la etiqueta v2026.9.21; la página de precios de Ollama, la propia página de integración de Hermes de Ollama y la lista de planes de Nous Portal se consultaron ese mismo día. No se comprobó si el artefacto de actualización automática de pip, Homebrew, el contenedor o la aplicación de escritorio que instalaste incluye alguna de las dos correcciones. Nada de esto se probó en tiempo de ejecución: no se ejecutó una instalación de Hermes, no se inició Ollama ni se abrió un selector. Las tarifas de tokens de Kunavo proceden del catálogo actual, y el ejemplo en dólares es una aritmética ilustrativa de tokens, no el coste medido de una tarea.