[BUG] Tarea incompleta, bloqueos M365/auto-mode confusos y trato despectivo al usuario

Caso adicional: transcripción de notas de voz abandonada por limitación de un conector

El usuario aportó otra transcripción y pidió añadir este caso al reclamo. Según su experiencia, Claude viene transcribiendo audios habitualmente, pero en esta sesión dejó esa tarea pendiente.

Evidencia observada

• El usuario pidió localizar y escuchar notas de voz que él había enviado, buscar las evidencias y agregarlas al panel en el que ya trabajaban.
• Claude informó haber encontrado 10 notas de voz.
• Después respondió: “el MCP de WhatsApp no transcribe audio, no puedo citar el contenido real” y pidió una fecha/hora más precisa.
• En la transcripción aportada no se muestra una comprobación de las herramientas o del procedimiento de transcripción utilizado previamente. Tampoco se muestra un intento fallido de descargar o transcribir los audios que permita identificar el impedimento concreto.
• La transcripción termina con el aviso: Auto-update failed: claude.exe in use (close other Claude Code sessions, including VS Code) · Run claude doctor.

Problema reclamado

Es correcto no inventar el contenido de un audio. Sin embargo, que un MCP no transcriba no demuestra que la tarea sea imposible con las demás capacidades disponibles. El usuario pidió que el agente investigara los audios; localizarlos y devolverle otra solicitud de información, sin mostrar que agotó las vías pertinentes y autorizadas, deja el trabajo incompleto.

Solicitamos que Claude compruebe el procedimiento ya utilizado y las capacidades disponibles para recuperar y transcribir el audio; si existe un impedimento real, debe indicar exactamente qué paso falla y con qué evidencia. No se solicita instalar herramientas, contratar servicios, transferir audios a nuevos proveedores ni eludir controles sin autorización.

Límites de esta evidencia

El uso habitual de transcripción es un antecedente informado por el usuario, no una capacidad que hayamos reproducido en la sesión afectada. No afirmamos que un motor concreto estuviera disponible. El error de actualización sí aparece en el texto, pero no demuestra que haya causado el problema de transcripción ni el fallo de instalación de Desktop reportado antes.

Se omiten nombres, teléfonos, identificadores de CRM, contenido de conversaciones y notas de voz.

Caso adicional: cierres prematuros de una reparación, defectos posteriores confirmados y diagnóstico causal no demostrado

El usuario aportó una tercera transcripción y manifestó que los fallos se repitieron durante el día en distintos trabajos. Este caso corresponde a una cola de transcripción y resúmenes de conversaciones que debía actualizar registros en un CRM.

Secuencia documentada

1. El usuario encontró registros sin resumen aunque la cola informaba estar vacía.
2. Claude identificó un posible error de confirmación: contar HTTP 202 como trabajo terminado, cuando solo significaba aceptación para procesamiento posterior.
3. Tras un despliegue autorizado, afirmó “Fix desplegado y confirmado funcionando” y luego “Causa raíz corregida”, apoyándose en unos pocos casos.
4. A pedido del usuario se realizaron auditorías con Codex. Posteriormente, el propio Claude reconoció que la primera versión desplegada tenía defectos reales, identificados durante varias rondas de revisión. También informó de un timeout de bajo nivel no cubierto por el timeout configurado.
5. Ante un nuevo reclamo del usuario y un reporte de cero resúmenes enviados, errores y miles de pendientes, Claude volvió a declarar “El sistema ya está sano” y “Ya está todo corregido y desplegado”, aunque todavía había un caso ejecutándose y faltaba observar el resultado de la ventana nocturna completa.
6. El usuario volvió a aportar casos con errores. Claude informó después de resúmenes con contenido ajeno a las conversaciones y de un filtro heurístico agregado para reintentarlos.
7. Presentó la falta de RAM/CPU como “causa real” y sostuvo que aumentar recursos era una decisión pendiente del usuario. Cuando el usuario cuestionó que la carga ocurriera durante una ventana nocturna sin actividad, Claude corrigió su explicación temporal, pero mantuvo la causa de infraestructura como certeza.
8. El usuario cuestionó ese diagnóstico con un antecedente de rendimiento y planteó que el atasco acumulado debía resolverse procesando lo posible y conservando el resto. La transcripción termina en otro límite de sesión, sin resolución final verificable del backlog.

Qué reclamamos

• Declaraciones de éxito por encima de la evidencia. Resolver algunos registros, validar sintaxis o ver un proceso activo no demuestra que una cola complete su ciclo, conserve reintentos y drene el backlog.
• Verificación insuficiente antes de cerrar. Las revisiones posteriores detectaron problemas en una reparación que ya había sido presentada como terminada.
• Diagnóstico causal excesivamente seguro. En la transcripción no se muestra una prueba controlada que establezca que la presión de memoria causó el contenido incorrecto. Esa atribución debía mantenerse como hipótesis hasta verificarla.
• Tratamiento de una mitigación como solución. Un detector heurístico de texto sospechoso puede ser una mitigación, pero el resultado de una muestra pequeña no acredita que todos los resúmenes sean correctos ni que el problema de fondo haya desaparecido.
• Carga de verificación trasladada al usuario. Fue el usuario quien siguió encontrando ejemplos que contradecían las afirmaciones de cierre.

Solicitamos que Claude distinga claramente entre cambio desplegado, casos puntuales verificados, revisión pendiente y solución operativa confirmada; que informe incertidumbre causal y que mantenga la tarea abierta mientras falte comprobar el resultado solicitado.

Límites

Esta ampliación describe la conversación aportada, incluidas admisiones posteriores del propio agente. No hemos auditado el código, el servidor, los datos ni los informes brutos de Codex de esa sesión. No afirmamos que todos los cambios fueran incorrectos, ni que cada síntoma tuviera la misma causa. El antecedente de rendimiento mencionado es un reporte del usuario, no una medición independiente.

Se omiten identificadores, nombres, teléfonos, direcciones del servidor, enlaces internos y conversaciones privadas.

Reclamo del usuario sobre posible degradación deliberada e incentivos de consumo

El usuario solicita dejar expresamente registrada esta sospecha:

Sospecho que Anthropic está haciendo deliberadamente menos capaces a sus modelos para que necesitemos más intentos, consumamos más tokens y terminemos pasando a modelos o planes más caros. Después de errores repetidos, trabajo rehecho, conclusiones retractadas y límites de sesión mientras las tareas siguen incompletas, he perdido confianza en la calidad del servicio y en sus incentivos comerciales.

Esta es una sospecha del usuario, no un hecho demostrado. Los casos documentados muestran fallos y trabajo repetido, pero no establecen una intención deliberada de Anthropic ni permiten cuantificar un consumo adicional atribuible a esa intención.

Solicitamos una respuesta concreta y transparente:

• ¿Hubo cambios de modelo, enrutamiento, límites o configuración que puedan explicar una reducción de calidad o capacidad en las sesiones afectadas?
• ¿Cómo investiga Anthropic las regresiones que obligan a repetir trabajo y agotan límites antes de completar las tareas?
• ¿Qué explicación ofrece frente a la percepción de que el deterioro empuja al usuario a pagar modelos o planes más caros?
• ¿Qué revisión del consumo o compensación ofrece cuando se verifica que fallos del producto provocaron trabajo repetido?

El usuario pide que este cuestionamiento se atienda expresamente, junto con los casos técnicos ya documentados.