¡Hola! Soy Oscar 👋, y por aquí estoy de nuevo!!!
El año pasado ejecutamos para uno de nuestros clientes un Bootcamp de aceleración de ideas con inteligencia artificial.
Los resultados fueron muy muy interesantes, 3 de las 5 ideas que probamos entraron al roadmap de desarrollo de producto.
También con mis estudiantes de un curso de creatividad creamos video juegos para niños, la idea era crear juegos que ayudaran a desarrollar habilidades en los niños.
Todas esas ideas tuvieron algo en común, crearon prototipos de manera local que pudieron probar con usuarios reales y sintéticos, en un formato que para la mayoría era medio enredado y no entendían bien: HTML.
Si aún no te has suscrito a Xtrategia, te invito a hacerlo dando click aquí
TL;DR
HTML tiene 35 años y acaba de convertirse en el formato más importante para trabajar con IA. Los usuarios de Claude generaron 500 millones de artefactos HTML en menos de doce meses.
El debate Markdown vs HTML es el debate equivocado. Markdown y HTML nunca resolvieron el mismo problema — y confundirlos tiene un costo medible.
Lo que está emergiendo es un workflow de tres capas: Markdown para que las máquinas piensen, HTML para que los humanos lean, video para que los humanos aprendan. Cada capa tiene su formato, su receptor, y su función.
Andrej Karpathy trazó la progresión completa en mayo de este año. Thariq Shihipar — Engineering Lead de Claude Code en Anthropic — declaró que ya abandonaron Markdown internamente. La neurociencia explica por qué. Los datos de tokens lo cuantifican.
La tercera capa no es especulación. Gemini ya tokeniza video de forma nativa. La infraestructura existe. Solo falta el criterio editorial para usarla.
El 12 de marzo de 1989, un ingeniero de software llamado Tim Berners-Lee entregó a su jefe un documento de 11 páginas.
El título era medio aburrido: “Information Management: A Proposal.”
Su jefe, Mike Sendall, lo leyó. Tomó un lapicero. Y escribió tres palabras en la portada:
“Vague but exciting.” - Vago, pero interesante.
Eso fue todo. Sin reunión de seguimiento. Sin presupuesto aprobado. Solo cuatro palabras escritas a mano sobre un documento que, sin que nadie lo supiera aún, contenía la arquitectura completa de la World Wide Web.
Treinta y cinco años después, esas mismas cuatro palabras describen con exactitud lo que sentimos la mayoría frente a la IA.
Vaga pero emocionante.
Lo que no sabemos todavía, igual que Sendall en 1989, es lo que tenemos en frente.
El debate equivocado.
Estas últimas semanas, en foros de product managers y comunidades de IA, el debate más activo era este:
¿Markdown o HTML?
Un lado argumentaba eficiencia de tokens. El otro argumentaba densidad visual. Ambos tenían razón en sus datos.
Y ambos estaban haciendo la pregunta equivocada.
En una de mis últimas entradas, escribí sobre por qué Markdown se convirtió en el formato nativo de la IA. Sostenía que era el lenguaje que los modelos entienden mejor, el más eficiente, el más durable.
Y lo sigo creyendo.
Pero tenía un contexto implícito que no articulé: era válido cuando los humanos eran los editores.
Cuando el output de la IA era un borrador que tú ibas a tomar, abrir en un editor de texto, modificar y depurar.
Cuando el flujo era: modelo genera → humano edita → humano usa.
Ese flujo ya no es el único que existe.
Y entender por qué requiere volver a 1989.
📌 Si llegaste hasta aquí, es porque te interesa ir más allá de la teoría, así que te invito a Xtrategas, mi comunidad para profesionales que lideran en producto, operaciones, tech, innovación y transformación digital.
¿Te unes?
Primero, el problema original
El CERN (Organización Europea para la Investigación Nuclear, en francés: Conseil Européen pour la Recherche Nucléaire) no era solo un laboratorio.
Era el experimento más ambicioso de colaboración científica de su época: más de 17.000 físicos, ingenieros y matemáticos de más de 100 países trabajando en el mismo proyecto, usando computadoras distintas, hablando idiomas distintos, con culturas de documentación distintas.
Cada vez que alguien se iba, el conocimiento que tenía sobre el sistema se perdía.
Las personas llegaban, aprendían cómo funcionaba todo, construían contexto durante meses. Y cuando se iban, ese contexto desaparecía.
No había forma de preservarlo ni de transferirlo de manera que alguien pudiera encontrarlo sin saber de antemano que existía.
Su solución fue elegante en su simplicidad, fusionar tres tecnologías que ya existían:
las redes de computadoras,
el almacenamiento de texto estructurado,
y el hipertexto
Crearon tres protocolos nuevos: HTML para estructurar el contenido, HTTP para transferirlo, y URL para direccionarlo.
Para fin de 1990, Berners-Lee y el ingeniero belga Robert Cailliau habían construido el primer servidor web y el primer navegador, corriendo en una computadora NeXT en el CERN.
La primera versión de HTML tenía apenas 18 etiquetas. El primer sitio web describía el proyecto mismo.
En mayo de 1994 se celebró la Primera Conferencia Internacional World Wide Web con 400 asistentes, apodada el “Woodstock de la Web.”
Para fin de ese año: 10.000 servidores. 10 millones de usuarios.
Pero la decisión que realmente lo cambió todo fue anterior: el 30 de abril de 1993, el CERN liberó el código fuente de la web como software de dominio público.
Sin licencias. Sin patentes. Sin costos.
Esa decisión es la razón por la que hoy HTML está en el 97.5% de todos los sitios web del planeta.
¿Y si no la hubieran tomado?
La web podría haber sido un producto comercial con licencias, como tantas otras tecnologías de la época que no sobrevivieron. HTML sería hoy una nota al pie.
En cambio, es infraestructura global.
Si aún no te has suscrito a Xtrategia, te invito a hacerlo dando click aquí:
Por qué Markdown era la respuesta correcta
Cuando escribí sobre Markdown, el argumento tenía tres pilares sólidos:
Eficiencia: Un artículo de 900 palabras en HTML crudo consume 21.400 tokens. El mismo artículo en Markdown limpio: 1.820 tokens. Reducción del 87.5%. A escala de 100.000 páginas al mes, la diferencia entre procesar HTML crudo vs Markdown optimizado es de $61.800 dólares al año solo en costos de tokens.
Comprensión: En el benchmark más riguroso que encontré, 11 formatos comparados, 1.000 registros, modelo GPT-4.1-nano, publicado por improvingagents.com en 2025, Markdown-KV alcanzó 60.7% de accuracy, el mejor de todos los formatos probados. JSON logró 52.3%. XML 56%. CSV, el más eficiente en tokens, apenas 44.3%.
Durabilidad: Los archivos Markdown son texto plano. Funcionan en cualquier editor. No dependen de ninguna plataforma. Sobrevivirán a cualquier cambio tecnológico porque no hay nada que romper.
Esos tres argumentos siguen siendo verdad.
El problema es el contexto implícito que asumí: que los humanos iban a editar esos archivos manualmente.
Ese contexto cambió. Y lo hizo en tres dimensiones al mismo tiempo.
Tres cosas que cambiaron.
Primera: las ventanas de contexto se volvieron absurdas.
Claude Opus 4.7 tiene una ventana de contexto de 1.000.000 de tokens. Eso es 122 veces más que la ventana de 8.000 tokens que hacía de Markdown el default obvio. Un artefacto HTML completo, con CSS, JavaScript, secciones colapsables, gráficos inline, navegación interna, consume aproximadamente 5.480 tokens. Eso es el 0.55% de la ventana de contexto de Opus 4.7, por ejemplo.
El costo total de generar ese artefacto: aproximadamente 8 centavos de dólar.
En ese universo, el argumento de “Markdown usa 87.5% menos tokens” sigue siendo matemáticamente correcto, pero operacionalmente irrelevante para la mayoría de casos de uso.
Segunda: los agentes se convirtieron en los editores.
Estimaciones han identificado que aproximadamente 70% del código que se genera con IA es efímero.
Se usa una vez para tomar una decisión, y se le descarta. Nunca se abre en un editor de texto. Nunca se modifica manualmente.
Para ese 70% de casos, la “editabilidad humana” de Markdown es una ventaja que no se usa. Es como valorar que un auto sea fácil de desensamblar cuando nunca lo vas a desensamblar.
Tercera: la sobrecarga de información se volvió un problema medido.
Un estudio de 2025 encontró que trabajadores con alta supervisión de IA reportan 19% más sobrecarga de información y 33% más fatiga de decisión que quienes tienen supervisión moderada.
Los documentos de más de 100 líneas en Markdown, texto plano sin jerarquía visual, sin navegación, sin diferenciación tipográfica, rara vez se leen completos.
Los tres cambios apuntan en la misma dirección.
No es que HTML haya “ganado.” Es que el contexto en el que Markdown era la respuesta obvia desapareció para una clase específica de outputs.
La arquitectura que está emergiendo
En mayo de 2026, Thariq Shihipar, Engineering Lead del equipo de Claude Code en Anthropic, publicó algo que resumía lo que muchos estaban descubriendo en producción.
Había dejado de usar Markdown internamente para outputs de agentes. Planes de trabajo. Revisiones de código. Sistemas de diseño. Reportes.
Todo HTML.
Su argumento tenía implícitas cinco razones concretas:
Densidad de información. HTML puede integrar tablas, SVGs, CSS, JavaScript e imágenes en un solo archivo. Markdown puede describir que algo existe, HTML puede mostrarlo.
Legibilidad a escala. Un documento de 200 líneas en Markdown es difícil de navegar. El mismo contenido en HTML con secciones colapsables y navegación interna se convierte en algo que un humano puede explorar, no solo leer linealmente.
Eficiencia de compartir. Un archivo HTML se abre nativamente en cualquier browser del mundo. Súbelo a un CDN (Content Delivery Network o Red de Entrega de Contenido) y tienes un link clickeable que cualquier persona puede ver sin instalar nada. Markdown requiere un renderer.
Interactividad de dos vías. Sliders, knobs, botones, filtros. Un artefacto HTML no es un documento estático, es una herramienta que el receptor puede operar. Eso transforma un reporte en una experiencia exploratoria.
Costo de tokens manejable. Los ~5.480 tokens de un HTML completo representan el 0.55% de la ventana de contexto de Opus 4.7. La discusión de eficiencia es real pero no decisiva en ese universo.
“There’s almost no set of information that Claude can read that you cannot fairly efficiently represent with HTML.”
— Thariq Shihipar, Anthropic, mayo 2026
El equipo de BeamAI lo sintetizó con una frase que vale la pena guardar:
“Esto no es una batalla entre HTML y Markdown. Es un workflow que se está dividiendo en dos capas: HTML se está convirtiendo en la capa de revisión humana, y Markdown se queda como la capa de memoria de la máquina.”
No hay un ganador.
Hay una nueva arquitectura de trabajo.
Capa 1 — Máquina habla a máquina: Markdown. El agente razona, recuerda, procesa internamente. Los prompts de sistema, el contexto de la conversación, la comunicación entre agentes, los pipelines RAG, todo en Markdown. El agente no necesita jerarquía visual para pensar.
Capa 2 — Máquina habla a humano: HTML. Cuando el output cruza la frontera y llega a un lector de carne y hueso, cambia el formato. No por estética. Por entendimiento y capacidad de decisión.
El argumento de Karpathy
Andrej Karpathy cofundó OpenAI y fue el director de IA de Tesla por cinco años.
En mayo de 2026 publicó esto:
“…This works really well btw, at the end of your query ask your LLM to ‘structure your response as HTML’, then view the generated file in your browser.”
El post tuvo millones de vistas. Pero lo más importante no fue el tip. Fue el razonamiento detrás:
El 30% del córtex cerebral humano procesa información visual.
El audio ocupa el 3%.
El texto plano activa una fracción de ese potencial.
Cuando un agente te entrega Markdown, te está pidiendo que proceses información por el canal más estrecho disponible, el de leer texto sin ninguna ayuda visual adicional.
Cuando te entrega HTML, con jerarquía visual, diferenciación tipográfica, colores, tablas estructuradas, secciones navegables, activa una superficie cognitiva exponencialmente más grande.
No se trata solo de estética. Se trata también de como nuestro cerebro puede procesar mejor.
Karpathy fue más lejos. Trazó una progresión que nadie había articulado con esa claridad:
texto plano → Markdown → HTML → interactive neural video
Las primeras tres capas ya las tenemos activas. La cuarta está llegando.
Lo que los números dicen sobre HTML en producción
Quiero ser específico aquí porque los datos son más contundentes de lo que la mayoría intuye.
Simon Willison, creador de Django, uno de los bloggers técnicos más influyentes del mundo en IA, documentó en octubre de 2024 todo lo que construyó con los Artifacts (Artefactos) de Claude en una sola semana.
El resultado: 14 herramientas HTML funcionales. Tiempo promedio de desarrollo por herramienta: 12 a 21 minutos.
Una herramienta de conversión de URLs con integración Jina Reader. Un demo de SQLite en el browser. Un convertidor YAML a JSON. Un decodificador de códigos QR. Un explorador de API de audio con grabación desde el micrófono.
Todo en HTML, CSS y JavaScript. Todo en un solo archivo.
Su patrón, documentado en diciembre de 2025: “Single-file architecture: inline JavaScript and CSS in a single HTML file means the least hassle in hosting or distributing them.” - incrustar JavaScript y CSS directamente en un solo archivo HTML significa el menor esfuerzo posible al momento de alojar o distribuir las herramientas.
Sin npm. Sin webpack. Sin build steps. Sin configuración de servidor.
Una URL y listo.
A escala global, los usuarios de Claude crearon más de 500 millones de artefactos HTML desde el lanzamiento en junio de 2024 hasta mediados de 2025. No fue un hype. Fue una respuesta a una necesidad real que existía y no tenía solución obvia.
Anthropic fue tan lejos que en abril de 2026 lanzó los Live Artifacts: artefactos HTML conectados a fuentes de datos externas vía MCP, Google Calendar, Gmail, Slack, Asana, que se actualizan automáticamente cada vez que los abres. No son reportes estáticos. Son paneles vivos.
La tercera capa
Aquí es donde la mayoría de personas aún no está mirando.
Markdown resuelve la comunicación máquina-a-máquina. HTML resuelve la comunicación agente-a-humano para lectura y revisión. Pero hay una tercera función que ninguno de los dos resuelve bien: la apropiación profunda de conocimiento.
¿Qué diferencia hay entre leer que algo funciona de cierta manera y verlo funcionar?
La diferencia entre información y comprensión. Entre saber y poder hacer.
Hay conceptos que no se instalan con solo leerlos.
Requieren demostración, narración, ejemplo en movimiento. Requieren ver cómo funciona algo, no solo leer que funciona.
El video activa simultáneamente el canal visual, el auditivo, y cuando hay demostración de movimiento, el motor. Es el formato de mayor ancho de banda cognitivo que existe para transferir conocimiento complejo.
Y la infraestructura para que los agentes produzcan y procesen video ya existe.
Google Gemini, por ejemplo, tokeniza video de forma nativa con una fórmula específica:
Tokens/minuto = (60 frames × 258 tokens/frame) + (60 segundos × 32 tokens/s)
= 15.480 (canal visual) + 1.920 (canal de audio)
= 17.400 tokens por minuto de video
Para un video de 10 minutos: aproximadamente 174.000 tokens. Costo en Gemini 2.5 Flash: $0.052 dólares. Cinco centavos para procesar diez minutos de video.
La capacidad máxima de Gemini para audio en un solo prompt es 9.5 horas. Esto no es una proyección futura está en la documentación oficial de Google de 2025.
El video no es el siguiente paso especulativo. Es el paso para el que la infraestructura ya está construida.
Lo que falta es el criterio editorial: saber cuándo un entregable debería ser video y no documento.
La misma pregunta, 35 años después
¿Recuerdas el problema original de Berners-Lee?
17.000 científicos. Conocimiento que se pierde cuando la gente se va. La necesidad de transferir comprensión de una mente a otra sin que se pierda en el camino.
Ese sigue siendo el problema. Solo cambió la escala.
En 2026, el “conocimiento que se pierde” no es el de un físico de partículas que se va del CERN, es el razonamiento de un agente que procesa cientos de documentos y necesita entregarle algo útil a un humano.
El “canal de transferencia” no es una red universitaria de la era pre-web, es la interfaz entre modelos de lenguaje y tomadores de decisiones que tienen 15 minutos para revisar un análisis.
La respuesta de Berners-Lee en 1989 fue HTML porque entendió que el canal importa tanto como el contenido. Un documento perfectamente estructurado que nadie puede abrir es conocimiento que probablemente no existe.
La respuesta emergente en 2026 es la misma: Markdown donde la máquina necesita pensar, HTML donde el humano necesita revisar, video donde el humano necesita aprender. Cada capa diseñada para el receptor que la va a recibir.
Cómo se ve esto en la práctica
Antes de los accionables, una advertencia honesta: esta arquitectura de tres capas no es algo que la mayoría de equipos esté implementando de forma deliberada todavía.
La mayoría usa DOC, PDF, PPT, XLS, en el mejor de los casos Markdown, o HTML, sin pensar en la función de cada capa.
Escribí antes sobre cómo los tokens son la forma en que el lenguaje se vuelve computable para un LLM y por qué su gestión es una decisión de producto, no solo técnica.
Lo que sigue aplica esa lógica: no solo cuántos tokens usas, sino en qué formato viven y para quién.
Nivel 1 — Dos experimentos que puedes hacer esta semana, sin cambiar nada en tu stack:
Experimento A: Toma cualquier prompt que uses regularmente con Claude. Al final, agrega: “estructura tu respuesta como HTML con secciones colapsables y una tabla de contenidos.” Abre el archivo en tu browser. Compara esa experiencia con recibir el mismo contenido en Markdown. Haz eso una vez. La conversación interna que genera vale más que cualquier explicación.
Experimento B: Si tienes PDFs, DOCX o páginas HTML que usas como contexto para tus prompts, convierte uno a Markdown primero con markitdown (Microsoft, open source, un comando). Compara la calidad de respuesta del modelo antes y después. La reducción de tokens es del 50 al 90% dependiendo del tipo de documento, y la señal-ruido que el modelo recibe mejora notablemente.
Nivel 2 — Diseña tu workflow con las dos capas activas:
La pregunta que debería guiar cada entregable de IA es una sola: ¿quién recibe este output?
Si el receptor es otro agente, un pipeline, código que va a parsear la respuesta, o un sistema RAG, Markdown. Eficiente, compacto, sin overhead visual que nadie va a usar.
Si el receptor es un humano que tiene que leer, decidir, o compartir con alguien más: HTML. Un plan de trabajo, un análisis de producto, una revisión de código con color-coding, un reporte de benchmark, un documento de estrategia. El modelo lo genera todo en HTML en un solo paso, y el resultado es abrirlo en el browser, compartir el link, y que cualquier persona lo vea sin instalar nada.
El cambio mental no es técnico. Es reconocer que la frontera entre capa de máquina y capa humana existe, y que cruzarla sin cambiar formato es como entregar una reunión en audio cuando podría ser en video.
Nivel 3 — Empieza a mapear qué debería ser video:
Hay un ejercicio que encuentro útil: revisar los últimos 10 entregables que generaste con IA y preguntarte cuáles habrían tenido más impacto si alguien los hubiera visto en lugar de leído.
No todos. La mayoría funciona perfectamente como documento HTML.
Pero hay una categoría específica donde el video gana siempre: cuando el objetivo no es informar, sino cambiar comportamiento.
Un tutorial de onboarding. Una demostración de producto para un cliente. Un argumento estratégico que necesita ser mostrado en acción, no solo descrito en texto. Una formación donde la retención importa más que la velocidad de consumo.
La infraestructura técnica ya está. El criterio editorial es tu responsabilidad.
Para terminar…
Mike Sendall nunca supo lo que había tocado con esas tres palabras.
Cuando escribió “Vague but exciting” sobre la propuesta de Berners-Lee, estaba describiendo la experiencia de tener algo importante en frente sin poder ver sus contornos completos todavía. Era la honestidad de alguien que reconoce la magnitud de algo antes de poder explicarla.
Lo que Berners-Lee había inventado no era un protocolo técnico. Era una respuesta al problema más persistente de la cognición humana colectiva: cómo el conocimiento viaja de una mente a otra sin perderse en el camino.
La respuesta en 2026 es la misma lógica llevada tres pasos más lejos.
Markdown donde la máquina necesita pensar, eficiente, compacto, sin fricción para el modelo.
HTML donde el humano necesita revisar, rico, navegable, diseñado para el córtex visual.
Video donde el humano necesita aprender, el canal de mayor ancho de banda cognitivo que existe.
La próxima vez que alguien te pregunte “¿Markdown o HTML?”, ya sabes que esa pregunta asume que hay que elegir uno. La respuesta correcta es más simple y más interesante al mismo tiempo:
Depende de quién lo recibe.
Y esa pregunta — ¿para quién es esto? — siempre fue la más importante. Solo que en 2026, por fin tenemos la infraestructura para responderla de forma diferente en cada capa.
Herramienta de la Semana
Nombre: v0 by Vercel
Qué hace: Genera componentes HTML y React desde descripciones en lenguaje natural. Describes lo que necesitas — una tabla de comparación, un dashboard de métricas, una landing de producto, un formulario de diagnóstico — y v0 produce el HTML listo para usar. Sin configuración. Sin npm. Sin build steps. Sin necesidad de saber CSS.
Por qué la recomiendo: Es la demostración más directa del argumento de este artículo. No explica cómo hacer algo — produce la capa HTML lista para consumo humano. Lo uso para prototipar entregables visuales antes de invertir tiempo en diseño: describo la estructura del reporte o herramienta que necesito, v0 genera el HTML, lo abro en el browser, y en 10 minutos tengo algo que puedo mostrar a un cliente o equipo sin que requiera ninguna instalación de su parte. La transición de Markdown — donde el agente razona — a HTML — donde el humano revisa — nunca es más obvia que cuando usas v0.
Link: v0.dev
En Mi Radar
Anthropic — Live Artifacts (abril 2026): Dashboards HTML conectados a fuentes de datos reales vía MCP — Google Calendar, Slack, Asana, Gmail — que se actualizan automáticamente. La diferencia entre un reporte que describes y un panel que vive. Este es el HTML de segunda generación: no solo rico visualmente, sino dinámico en tiempo real. → anthropic.com/news/build-artifacts
HtmlRAG — WWW 2025: El primer paper académico que demostró formalmente que HTML preserva información estructural y semántica que se pierde al convertir a texto plano. Superó a sistemas basados en texto plano en 6 benchmarks de QA. La investigación que convierte la intuición de los practitioners en evidencia verificable. → arxiv.org/abs/2411.02959
¿Ya tienes un workflow con las dos capas activas? ¿Hay alguien en tu equipo que use HTML para outputs y Markdown para el razonamiento interno? Cuéntame cómo te va implementando esto — me interesa mucho saber dónde estamos.
Gracias por leerme.
Si esta newsletter te resultó útil, compártela con un líder de tu red que siga usando IA sin muchos resultados. Nos ayuda a crecer y a ellos les puede cambiar la perspectiva.
Nos leemos la próxima semana.
Oscar Durán - @duranoscarf en instagram y Linkedin
Comparte Xtrategia Newsletter con alguien que creas le puede agregar valor.
Fuentes citadas
1. Thariq Shihipar — *”HTML is the new Markdown”* — Anthropic, mayo 2026. [shihipar.com/html-is-the-new-markdown](https://shihipar.com/html-is-the-new-markdown)
2. Andrej Karpathy — Post sobre HTML como formato de output de LLMs — X/Twitter, mayo 2026.
3. Simon Willison — *”Building tools with Claude Artifacts”* — simonwillison.net, octubre 2024. [simonwillison.net](https://simonwillison.net)
4. BeamAI — *”HTML becoming the human review layer and Markdown staying the machine memory layer”* — análisis interno publicado, 2025.
5. ImprovingAgents — *Benchmark de 11 formatos para extracción de datos estructurados* — improvingagents.com, 2024–2025.
6. Tong Chen, Hongyu Li, Junbo Zhao et al. — *”HtmlRAG: HTML is Better Than Plain Text for Modeling Retrieved Knowledge in RAG Systems”* — arXiv:2411.02959, noviembre 2024. Aceptado en WWW 2025. [arxiv.org/abs/2411.02959](https://arxiv.org/abs/2411.02959)
7. Microsoft Research — *”SpreadsheetLLM: Encoding Spreadsheets for Large Language Models”* — arXiv:2407.09025, julio 2024. [arxiv.org/abs/2407.09025](https://arxiv.org/abs/2407.09025)
8. H. Chen et al. — *”Tokenization efficiency across languages”* — Frontiers in Artificial Intelligence, 2025. [doi.org/10.3389/frai.2025.1538165](https://doi.org/10.3389/frai.2025.1538165)
9. H. Shi et al. — *”LLMLingua: Compressing Prompts for Accelerated Inference of Large Language Models”* — arXiv:2310.05736, Microsoft Research, 2023.
10. W3Techs — *Web Technology Surveys: Usage statistics of markup languages for websites* — w3techs.com, 2026. [w3techs.com/technologies/overview/markup_language](https://w3techs.com/technologies/overview/markup_language)
11. Anthropic — *Anuncio: Claude Artifacts supera 500 millones de creaciones* — anthropic.com, mid-2025. [anthropic.com/news](https://www.anthropic.com/news)
12. web2md.org — *Benchmark de conversión HTML → Markdown: reducción del 87.5% en tokens para 6 tipos de página* — 2024.
13. ikriv.com — *Experimento comparativo de tokens por idioma (GPT-4, cl100k_base)* — ikriv.com/blog/?p=5322, 2024.
14. Anthropic — *Claude pricing and token documentation* — platform.claude.com/docs/en/about-claude/pricing, 2026.
15. Anthropic — *Claude Vision: image token calculation* — platform.claude.com/docs/en/build-with-claude/vision, 2026.
16. Google — *Gemini API: audio and video tokenization* — ai.google.dev/gemini-api/docs/audio, 2025.
17. OpenAI — *Tokenizer and pricing documentation* — platform.openai.com/tokenizer, 2024–2025.
18. CERN — *The birth of the Web* — home.cern/science/computing/birth-web, 2024. [home.cern/science/computing/birth-web](https://home.cern/science/computing/birth-web)
19. Tim Berners-Lee — *”Information Management: A Proposal”* — CERN, 12 de marzo de 1989. [cern.ch/info/Press/HiPressrel/1991/proposal.html](https://info.cern.ch)
20. WHATWG — *HTML Living Standard* — html.spec.whatwg.org, actualizado continuamente. [html.spec.whatwg.org](https://html.spec.whatwg.org)
21. John Gruber — *Markdown* — daringfireball.net, marzo 2004. [daringfireball.net/projects/markdown](https://daringfireball.net/projects/markdown)
Comprendí totalmente.