Lendo a temperatura real da CPU em Macs Intel e Apple Silicon

Não existe uma API da Apple que simplesmente entrega um número

Abra o Activity Monitor e procure uma coluna de temperatura da CPU — ela não existe. A Apple nunca lançou um indicador de temperatura nativo em nenhum lugar do macOS: nem no Activity Monitor, nem nas Configurações do Sistema, nem por meio de qualquer API pública de temperatura. Isso não é um esquecimento; a Apple trata os dados dos sensores como um detalhe interno do próprio gerenciamento térmico, não como algo que os apps devam ler diretamente.

Tudo que mostra um número, gratuito ou pago, contorna essa lacuna da mesma forma: conversando com o SMC, o pequeno controlador sempre ativo que fica entre o macOS e os sensores térmicos e as ventoinhas de fato. Não existe uma chamada de sistema "ler temperatura da CPU" — você pede ao SMC uma chave de sensor específica de quatro caracteres (como TC0D ou Tp01) e ele devolve um punhado de bytes brutos que não significam nada até você saber como decodificá-los.

Essa é a resposta real para "como eu leio a temperatura da CPU do meu Mac": escolher a chave certa para esse Mac específico e depois decodificar os bytes retornados usando o formato correto para esse chip específico. Erre qualquer uma das duas etapas e você tem um número errado, ou nenhum número — o que explica exatamente por que duas ferramentas de temperatura no mesmo Mac podem discordar, e por que alguns leitores não mostram nada em um chip recém-lançado.

Os dois decodificadores: sp78 na Intel, IEEE flt na Apple Silicon

O SMC não retorna um tipo numérico universal — cada chave carrega seu próprio tipo de dado, e o decodificador precisa corresponder a ele, ou o resultado vira lixo. As chaves de temperatura usam dois formatos diferentes dependendo da arquitetura do Mac.

Em Macs Intel, a temperatura volta como sp78: um número de ponto fixo 8.8 com sinal, um byte de graus inteiros e um byte de fração. Decodificar isso é aritmética simples — o primeiro byte lido como inteiro com sinal, mais o segundo byte dividido por 256. Os bytes 0x31 0x80, por exemplo, decodificam para 49 + 128/256 = 49,5°C.

Na Apple Silicon, a mesma família de sensores retorna como flt: um número de ponto flutuante IEEE-754 padrão de 4 bytes, só que armazenado em little-endian em vez da ordem de bytes que você normalmente esperaria. É o mesmo formato de float de 32 bits usado em praticamente todo o resto do software — a Apple só empacota os bytes ao contrário.

O RPM das ventoinhas também tem sua própria divisão de codificação — ponto fixo fpe2 em hardware Intel mais antigo, flt em Intel moderno e em todo Mac com Apple Silicon — então um leitor construído só para os formatos numéricos de uma geração de chip vai ler errado, ou simplesmente falhar ao ler, hardware do outro lado dessa transição. O LidRun verifica o tipo realmente reportado de cada chave antes de decodificar, em vez de assumir um único formato para o Mac inteiro.

Não existe uma única chave de "temperatura da CPU" — e ela muda a cada chip

Mesmo depois de saber decodificar uma chave, você ainda precisa saber qual chave pedir, e isso muda de acordo com o modelo do Mac e, na Apple Silicon, com a geração do chip.

Macs Intel são relativamente simples: os sensores da CPU vivem sob a família TC0x — TC0D (die), TC0P (proximidade), TC0E e TC0F (leituras filtradas/virtuais), TCAD (pacote) — e a maioria dos leitores para Intel simplesmente consulta essa lista curta.

A Apple Silicon é fragmentada de propósito, porque o chip tem muito mais zonas térmicas distintas do que um único "die". O M1 expõe chaves de núcleo de performance como Tp01, Tp05 e Tp0D, um cluster de CPU auxiliar sob Tc0a/Tc0b, e chaves de GPU sob Tg05/Tg0D. O M2 acrescenta chaves separadas para os núcleos de eficiência (Tp1h, Tp1t) ao lado dos núcleos de performance. Já o M3 muda a convenção de nomes por completo: as chaves de núcleo de performance e de GPU passam para um novo prefixo Tf (Tf04, Tf09…) e os núcleos de eficiência ganham seu próprio prefixo Te — a geração que abandonou o Tp para núcleos de CPU por completo. O M4 traz o Tp de volta para os núcleos de performance enquanto mantém o Te para eficiência. O M5 acrescenta ainda um nível de "super núcleo" com seus próprios sufixos Tp.

Essa é a razão real pela qual um leitor de temperatura pode passar de funcionar perfeitamente a não mostrar nada no próximo Mac que você comprar: uma ferramenta com uma lista de chaves M1/M2 fixa no código não lê nada em um M3, porque as chaves que ela procura não existem mais ali — elas mudaram de letra. Não é um defeito do seu Mac; é uma lista de chaves que não foi atualizada para o novo chip.

O LidRun lida com isso em duas etapas: primeiro tenta uma lista estática de chaves conhecidas (rápido, sem necessidade de sondagem em Macs que ele já conhece) e, se nenhuma delas retornar uma leitura, enumera a tabela completa de chaves do SMC uma única vez — de algumas centenas a cerca de mil chaves, dependendo do Mac — e mantém tudo que decodifica para uma temperatura plausível sob os prefixos de sensor de die (Tp, Te, Tf, Tg, Tc), descartando sensores de pele, ambiente e bateria que subestimariam o quanto o chip está realmente quente. O resultado fica em cache, então consultas posteriores custam quase nada.

As formas gratuitas e nativas de conferir você mesmo

Você não precisa do LidRun, nem de nenhum app pago, para ver um número real. Existem algumas opções gratuitas, cada uma com uma limitação real que vale a pena conhecer antes de confiar nela.

O pmset -g therm nativo do Terminal é a coisa mais próxima de um comando de temperatura que o macOS traz de fábrica — mas leia a saída com atenção: a linha CPU_Speed_Limit que ele imprime não é uma temperatura, é uma porcentagem de limitação (throttle). 100 significa que o chip não está sendo limitado; um número menor significa que o macOS está ativamente reduzindo a velocidade da CPU para controlar o calor. É um sinal genuinamente útil de "meu Mac está sofrendo agora", e é gratuito e nativo, mas nunca vai te mostrar uma leitura em graus.

Para um número de fato, existem leitores de SMC gratuitos e open-source que fazem exatamente o trabalho de chave-e-decodificação descrito acima. O Stats (exelban/stats) é um app de menu bar gratuito e open-source que acompanha a mudança dos nomes de chave da Apple Silicon a cada versão. Ferramentas de linha de comando como smctemp e osx-cpu-temp fazem a mesma decodificação direto do Terminal, sem precisar de interface gráfica (o osx-cpu-temp é anterior à Apple Silicon e cobre só Intel).

Ferramentas pagas ou freemium — iStat Menus, TG Pro, Macs Fan Control — leem as mesmas chaves do SMC e acrescentam refinamento: gráficos de histórico, alertas e, no caso do TG Pro e do Macs Fan Control, controle de ventoinha em cima da leitura. Nenhuma delas tem acesso a um número que a Apple esconde de todo o resto; elas fazem exatamente o mesmo handshake com o SMC, só com mais manutenção por trás da lista de chaves e uma interface mais bonita ao redor.

Por que dois apps mostram números diferentes

Se uma ferramenta diz 68°C e outra diz 74°C no mesmo Mac, no mesmo instante, nenhuma das duas está necessariamente errada. Elas quase certamente estão lendo um sensor diferente, ou transformando vários sensores em um único número de um jeito diferente.

Digamos que um Mac tenha oito sensores de núcleo lendo entre 65°C e 75°C naquele instante. Uma ferramenta que faz a média dos núcleos (a abordagem que Stats e smctemp usam, para uma "temperatura atual da CPU" mais amigável) pode mostrar 70°C. Uma ferramenta que reporta um sensor de pacote específico pode mostrar 72°C. Uma ferramenta que reporta o sensor ativo mais quente que encontrou — a abordagem do LidRun — mostra 75°C. Os três números são leituras reais e honestas do mesmo silício; elas só respondem a perguntas ligeiramente diferentes.

A média dá um número mais suave e mais representativo do dia a dia. Reportar o máximo é a escolha mais conservadora para qualquer coisa relacionada à segurança, porque a limitação (throttling) é disparada pelo único sensor de die mais quente ultrapassando seu limite, não pela média — então um monitor que está decidindo se recua, e não só exibindo um número, tem um motivo real para preferir o pico à média.

A lição prática: trate qualquer temperatura de CPU isolada como a leitura de um sensor e de um método escolhidos por aquela ferramenta específica, não como o valor único e verdadeiro do seu Mac. O que importa para julgar se algo está realmente errado é a tendência nos últimos minutos e o quanto ela está subindo — não se o seu número bate, grau a grau, com a ferramenta de um amigo.

O risco de confiar em um único leitor

O problema de geração de chip descrito acima não é hipotético — ele já causou falhas reais e documentadas. O btop, o popular monitor de sistema open-source, lançou um leitor de temperatura que só implementava o decodificador sp78; como nunca tratou o flt, ele simplesmente não mostrava a temperatura da CPU em nenhum Mac com Apple Silicon (um bug que o projeto rastreou como issue #1653) até ser corrigido. Nada travava e nenhum erro aparecia — o número simplesmente sumia, o que parece "meu Mac não tem sensor de temperatura" em vez de "o decodificador dessa ferramenta está incompleto".

O mesmo tipo de falha se aplica a listas de chaves desatualizadas, não só a decodificadores ausentes: um leitor construído antes do lançamento do M3 e nunca atualizado não lê nada em um M3, porque as chaves de núcleo de performance que ele procura (Tp01, Tp05…) não existem mais ali — agora são Tf04, Tf09. Uma lista de chaves desatualizada e um decodificador ausente produzem o mesmo sintoma: uma leitura em branco ou zerada, que parece um problema de hardware sem ser.

Existe um risco separado, menor, com ferramentas que vão além de apenas ler. Macs Fan Control, TG Pro e smcFanControl instalam todos um daemon auxiliar privilegiado para conseguirem escrever no SMC — o mecanismo legítimo que o controle de ventoinha de fato exige, já que a Apple requer um helper assinado com Developer ID e rodando como root para isso, e não existe caminho mais leve. Mas isso significa que um segundo processo em segundo plano passa a ter a capacidade de manter suas ventoinhas em um alvo manual. Se você fechar o app sem devolvê-lo ao modo automático, esse daemon pode continuar rodando com a última configuração manual em vez de devolver o controle para a própria curva de firmware do macOS.

Nada disso significa que essas ferramentas não sejam confiáveis — Stats, TG Pro e Macs Fan Control são todos ativamente mantidos e continuam correndo atrás de cada nova geração da Apple Silicon conforme ela é lançada, mesmo que o suporte completo às vezes fique uma ou duas versões atrás do lançamento de um chip. Significa que um número de temperatura só é tão atual quanto a lista de chaves e o decodificador por trás dele, e essa lista mudou com consequências reais a cada ano em que a Apple lançou um chip novo.

O que realmente conta como "quente demais"

Depois que você tem um número real, a pergunta mais difícil é o que fazer com ele — e não existe um limite seguro único que funcione para todo Mac, porque a Apple deliberadamente opera seus chips perto do teto térmico sob carga sustentada. Isso é operação normal, não um sinal de alerta.

Chips M1 são projetados para rodar a cerca de 100°C sob carga pesada e sustentada sem se degradar — isso é o design do SoC funcionando como planejado, não um defeito. O M2 roda ainda mais quente nas mesmas condições, comumente passando dos 100°C. Macs Intel costumam ficar na faixa de 90–100°C sob carga, o que é simplesmente como essa arquitetura se comporta. O MacBook Air, sem ventoinha, não tem para onde recorrer além do throttling — ele gerencia o calor puramente reduzindo a velocidade, então uma leitura sustentada de 90–100°C em um Air é o seu envelope normal de operação, não evidência de que algo está errado.

O próprio throttling — o chip limitando a própria velocidade para controlar o calor — costuma começar em algum ponto perto de 95–100°C na maioria dos Macs recentes, o que é a proteção do próprio hardware fazendo o seu trabalho, não um sinal de que sua carga de trabalho quebrou alguma coisa.

Como um único número "seguro" em graus não se sustenta entre os modelos, o sinal mais útil é o qualitativo que a própria Apple construiu para isso: ProcessInfo.thermalState, uma avaliação de quatro níveis (nominal, fair, serious, critical) descrita pelo que o seu Mac precisa fazer, não por uma temperatura. É o sinal ao qual todo app bem-comportado deve responder, e é em torno dele que a própria resposta de segurança do LidRun é construída, em vez de um limite fixo em graus que dispararia falsamente em um Mac normal e saudável sob carga real.

Onde o LidRun entra

Ler a temperatura não é um recurso pago no LidRun — toda instalação tem acesso a isso, tanto em Intel quanto em Apple Silicon, usando a mesma abordagem de chave-e-decodificação descrita acima: a chave válida mais quente da lista ativa, sp78 ou flt combinado com o que o SMC de fato reporta para aquela chave.

O motivo de o LidRun ler isso não é te mostrar um medidor mais bonito do que as ferramentas gratuitas já mostram. Ele está lá para que a própria resposta de segurança do LidRun tenha um sinal real enquanto mantém seu Mac acordado durante a execução de um agente. A promessa central do LidRun é simples: agente rodando → fica acordado; agente terminou ou está inseguro → libera, ou dorme. Isso não é um bloqueio de suspensão cego que mantém o Mac acordado não importa o quê — o lado "inseguro" se apoia principalmente no thermalState, o sinal oficialmente documentado, reforçado pela temperatura numérica e pela porcentagem de throttle da CPU como verificação secundária. Em calor crítico, o LidRun sempre libera imediatamente sua retenção de keep-awake, em qualquer Mac, com a tampa aberta ou fechada. Se o modo Closed-Lid está ativo e a tampa está de fato fechada — o caso em que o calor não tem para onde ventilar — o calor crítico sustentado escala de uma liberação para uma suspensão de fato, já que a própria prevenção de suspensão do Closed-Lid, de outra forma, manteria o Mac acordado mesmo com a liberação. Com a tampa aberta, ele só libera e nunca força a suspensão de um Mac que você está usando ativamente.

Controle de ventoinha é o único ponto em que o LidRun se mantém deliberadamente modesto sobre o que promete, especialmente na Apple Silicon. Ali, o RPM da ventoinha é uma escrita protegida pelo firmware — o próprio controlador térmico do SoC gerencia a curva ativamente e pode simplesmente rejeitar uma sobrescrita manual, e em vários chips Apple Silicon Pro/Max o firmware não gira as ventoinhas abaixo de aproximadamente 70 e poucos graus Celsius, não importa o que qualquer app peça. Isso é um teto real de hardware, não uma lacuna na engenharia de nenhuma ferramenta em particular. Então trate a leitura de temperatura como a camada confiável e sempre ativa, e mantenha o Mac ventilado sobre uma superfície firme e aberta durante execuções longas — isso ainda faz mais pela folga térmica do que qualquer curva de ventoinha pode prometer sozinha.