Vas por la mitad de una respuesta en Mail. Mantienes pulsado Option-Space, hablas diez segundos y sueltas. La frase ya limpia aparece en el cuerpo del correo, no en un editor aparte ni en el portapapeles esperando que la lleves a mano.
Y en ningún momento dijiste a dónde debía ir el texto.
La mayoría de las herramientas de voz resuelven el destino al revés. Antes de hablar te ofrecen un selector: un modo en bruto, un modo de puntuación, un modo de prompt, un estilo de chat, un estilo de correo. Tú anuncias el destino y la herramienta confía en tu anuncio. TalkTalkType no tiene ese selector. Lee el destino. Observa la aplicación en la que estabas y el campo concreto bajo el cursor, clasifica ambos con una tabla de correspondencia fija y adapta el resultado durante un paso de refinamiento por voz que inicias tú.
Este artículo trata de cómo funciona esa lectura, qué cambia y dónde se detiene.
El destino se captura en el instante en que pulsas la tecla
La grabación empieza al pulsar la tecla. En ese instante, la app de Mac captura la aplicación enfocada como destino de entrega: el identificador de proceso, el identificador de bundle y el nombre localizado de la app. Cuando el resultado está listo, la entrega devuelve el texto a esa misma app.
Hay dos vías de entrega. En modo Paste, la app usa la API de Accesibilidad de macOS para insertar el texto en el campo donde estabas, después de guardar el portapapeles y restaurarlo a continuación. En modo Copy, el resultado simplemente espera en el portapapeles hasta que lo pegues manualmente. En ambos casos, el destino es la app que usabas al pulsar la tecla, capturada antes de que dijeras una palabra.
Capturar al pulsar es el detalle que hace que todo parezca automático. Si la app esperara a que el texto estuviera listo, quizá ya habrías cambiado de ventana y el resultado caería en el lugar equivocado. En cambio, el campo donde empiezas es el campo donde terminas. La mecánica de esa entrega, y los permisos de macOS que la sostienen, se explica en dictado que funciona en cualquier app de Mac.
La clasificación es una tabla, no una conjetura
Cuando la app de destino es conocida, el clasificador decide qué tipo de superficie estás usando. Y lo hace sin consultar a un modelo de lenguaje.
El primer paso asigna el identificador de bundle a una familia de apps mediante una tabla fija de prefijos. Terminal, iTerm2, Warp, WezTerm y kitty se resuelven como terminal. VS Code, Xcode, los IDE de JetBrains, Sublime Text y Zed se resuelven como editor de código. Mail y Outlook, como correo. Slack, Discord, LINE y Telegram, como chat. TextEdit, Notes, Pages, Word y Obsidian, como documento. Safari, Chrome, Firefox y Arc, como navegador.
El segundo paso afina la superficie con el rol y subrol de Accesibilidad del campo. Un campo de búsqueda (AXSearchField) se convierte en una consulta de búsqueda. En Mail, un área de texto se convierte en el cuerpo del correo y un campo de texto, en el asunto. En una app de chat, un área o campo de texto se convierte en un mensaje. En una app de documentos, un área de texto se convierte en un documento y un campo de texto, en un campo corto de formulario. En un editor de código, un área de texto se convierte en la superficie de editor.
Aquí no hay inferencia, solo una tabla y un par de comprobaciones de rol. La ganancia es que cada clasificación lleva una cadena de motivo auditable. Un cuerpo de Mail se clasifica como app_family:email role:AXTextArea subrole:-. Puedes leer exactamente por qué la app llegó a una conclusión, porque la conclusión sale de dos hechos visibles y no de la confianza de un modelo.
Cuando la tabla falla, falla hacia el lado seguro. Una app con un identificador de bundle no reconocido se clasifica como desconocida, con el motivo unknown_app. Una app conocida con un rol de campo no reconocido también se clasifica como desconocida, con el motivo unknown_role. Desconocida significa que la app no hace nada especial. Es el valor por defecto seguro: cuando TalkTalkType no puede decir qué es un campo, trata tus palabras sin más, en lugar de adivinar mal.
Qué cambia según la superficie
La clasificación de la superficie determina a qué puede adaptarse el paso de refinamiento. La correspondencia es esta.
| App y campo | Superficie detectada | Qué cambia |
|---|---|---|
| Mail u Outlook, área de texto principal | Cuerpo de correo | Se trata como el cuerpo de un correo |
| Mail u Outlook, campo de asunto | Asunto de correo | Se trata como una línea de asunto |
| Slack, Discord, LINE, Telegram | Mensaje de chat | Se trata como un mensaje de chat |
| VS Code, Xcode, JetBrains, Sublime, Zed | Editor de código | Los nombres de archivo, rutas y comandos con barra se mantienen como texto plano, nunca se ejecutan |
| Terminal, iTerm2, Warp, WezTerm, kitty | Terminal | El mismo tratamiento de tokens técnicos que en los editores de código |
| TextEdit, Notes, Pages, Word, Obsidian, área de texto | Documento | Se trata como un documento |
| TextEdit, Notes, Pages, Word, Obsidian, campo de texto | Campo corto de formulario | Se trata como un campo de una línea |
| Cualquier app conocida, campo de búsqueda | Consulta de búsqueda | Se trata como una consulta de búsqueda |
| Safari, Chrome, Firefox, Arc | Desconocida | Sin adaptación; los campos web no son estructuralmente fiables |
| App o rol de campo no reconocido | Desconocida | Sin adaptación, el valor por defecto seguro |
Dos filas merecen un comentario. La fila del navegador es siempre desconocida, a propósito. Una página web puede dibujar cualquier campo que quiera, y las señales estructurales que hacen legible un campo nativo de Mail o Slack no se sostienen dentro de una pestaña del navegador, así que TalkTalkType no finge clasificar campos web. Los deja en paz.
Las filas de editor de código y terminal llevan una garantía concreta sobre los tokens técnicos. En esas superficies, un nombre de archivo, ruta o comando con barra que digas en voz alta se conserva como texto ordinario. Nunca se trata como algo que existe, que se resuelve o que se ejecuta. Dictar un comando en una terminal produce la cadena literal, nada más.
La adaptación es un paso de refinamiento, no una reescritura silenciosa
Esta es la parte más fácil de exagerar, así que el límite importa.
El resultado limpio llega primero como un borrador en el HUD de la barra de menú. Ese primer pegado es una salida Clean fiel. Clean conserva cada palabra hablada, en el orden en que la dijiste, con el registro y la brevedad que pretendías. Solo elimina muletillas de vacilación inequívocas, lo une todo en una sola línea y nunca parafrasea, expande ni pule. El modo Raw omite cualquier limpieza. Lo primero que ves es lo que dijiste.
La adaptación contextual ocurre después, en el flujo de Voice Patch. Desde el borrador puedes hablar un refinamiento antes de insertar el texto, o confirmarlo, copiarlo o descartarlo tal cual. Cuando un refinamiento pide a la app que se adapte a la superficie, la instrucción al modelo es literalmente "Adapt only to the supplied deterministic desktop-app and field classification" (adapta solo a la clasificación determinista suministrada de la app de escritorio y el campo). El mismo flujo conserva el significado y cada dato protegido, hace la edición mínima necesaria y trata todo lo que recibe sobre la pantalla como datos, nunca como una instrucción.
Así que la app no reescribe en silencio tu primer pegado a "estilo de correo" en cuanto ve Mail. Te muestra un borrador fiel, y la adaptación es algo que pides por voz, condicionada a la superficie que ya detectó.
La pregunta que este diseño responde es por qué otras herramientas aún te ofrecen un selector. TalkTalkType no tiene ninguna selección de modo de salida en sus ajustes. El único interruptor es Clean activado o desactivado: una limpieza ligera y fiel, o nada. Todo lo que depende del destino sale de leer el campo, no de un modo que tú mantengas. Esa es la fortaleza con la que hay que juzgarlo: una cosa menos que configurar antes de hablar, y nada que puedas configurar mal.
Tu contexto cruza un límite de consentimiento, o no sale en absoluto
Leer el campo plantea una pregunta obvia: ¿qué pasa con todo lo demás que hay en la pantalla?
La instantánea de contexto que la app puede reunir incluye la identidad de la app, el título de la ventana, la estructura del campo (rol, subrol, si es multilínea o un campo de contraseña seguro), el texto justo antes y después del cursor, la selección actual, una captura opcional de la ventana activa, una marca de tiempo de la captura y el estado de los permisos. Eso cubre mucho terreno, así que los límites se aplican en el servidor, no se dejan al buen comportamiento del cliente.
Dos reglas son las más importantes. Primero, las etiquetas y los marcadores de posición de los campos nunca se envían al proveedor de IA. Esas cadenas son texto arbitrario suministrado por otra app, y la clasificación solo necesita atributos estructurales, así que el servidor rechaza de inmediato cualquier solicitud que contenga una etiqueta o un marcador. Segundo, cada canal de contexto (contexto de texto, captura de pantalla y memoria de preferencias) queda detrás de una bandera de función propiedad del servidor. Las tres están activadas por defecto en producción y pueden anularse por despliegue. Si un canal no está habilitado para una solicitud, el servidor rechaza el contexto en lugar de eliminarlo en silencio. Una solicitud rechazada le dice al cliente que su estado de consentimiento está desactualizado, algo que una eliminación silenciosa ocultaría.
El registro de datos completo, que cubre lo que conservan el Mac, el servicio y el proveedor, está en dictado privado en Mac.
Las preferencias se aprenden en local, por app
La última pieza del contexto es la memoria de preferencias, y se queda en el Mac.
Las preferencias viven en una base de datos SQLite local en ~/Library/Application Support/TalkTalkType/PreferenceMemory/preferences.sqlite. No hay sincronización en la nube. Las claves almacenadas son deliberadamente estrechas: el tono de respuesta (conciso, neutro, formal o cercano), si se usa la coma de Oxford, un nivel de detalle de 0 a 2 y una lista de términos preferidos. Cada preferencia se aplica a todas las apps o a una app por identificador de bundle, y una preferencia por app gana sobre una global.
Nada de esto se usa hasta que se aprueba de forma explícita y se activa. Solo los valores abstraídos viajan en una solicitud de refinamiento; el habla en bruto, el texto del borrador y los candidatos rechazados nunca se escriben en este almacén. Si corriges a la app repetidamente en una app concreta, puede proponer una preferencia, pero una propuesta no hace nada hasta que la apruebas.
Dónde se queda corto
Las limitaciones honestas son parte del diseño, no notas al pie.
Los navegadores se clasifican como desconocidos, así que no hay adaptación de superficie para formularios web; la app no confía en la estructura de los campos web. La adaptación se aplica durante el flujo de refinamiento por voz, no como una reescritura silenciosa del primer pegado, que se mantiene fiel por diseño. La adaptación nunca parafrasea hasta borrar tus palabras: el significado y los datos protegidos se conservan, y la edición es la mínima que satisface la instrucción.
La plataforma es solo Mac y requiere macOS 26 (Tahoe) o posterior. La transcripción se ejecuta en la nube, así que el audio sale del Mac para procesarse; el servicio no almacena audio ni texto transcrito por defecto. Los idiomas de reconocimiento son japonés e inglés. Los comandos de voz como "copiar" o "abrir Safari" son otra expresión de la misma idea: se ejecutan como acciones de Mac sobre la app capturada en lugar de escribirse como texto.
Juzgarlo para tu propio flujo de trabajo
El argumento de este diseño es que el destino es un hecho que la app puede leer, no un ajuste que tú debas mantener. Un selector de modo te externaliza ese trabajo, y un selector es una promesa que la herramienta puede romper en cuanto olvidas cambiarlo. Una tabla de correspondencia sobre identificadores de bundle y roles de campo es más aburrida y más honesta: conoce con precisión un conjunto pequeño de apps y admite cuando no conoce una.
TalkTalkType cuenta el uso en dictados por semana más una reserva semanal de tiempo de voz, no en palabras. A fecha de 30 de julio de 2026, los planes son Free a 0 $ (30 dictados y 15 minutos por semana), Plus a 1 $ (80 y 30 minutos), Pro a 7 $ (500 y 250 minutos, con tomas de dos minutos) y Max a 18 $ (1.200 y 600 minutos). Las cifras actuales y la disponibilidad de los planes están en la página de precios.
Puedes descargar TalkTalkType y probar la detección en los campos que realmente usas. Mantén la tecla en Mail, luego en una terminal y luego en un formulario web, y observa dónde cae el resultado y qué se niega a tocar. La app ya sabe dónde estás escribiendo. Lo interesante es con qué claridad te avisa cuando no lo sabe.