Read your Mac's full hardware profile in 0.29 seconds

About This Mac gives you a model name, a chip name, a memory figure and a version number. That is enough to identify the machine and not enough to describe it. Four commands give you the full picture in 0.29 seconds, and none of them need sudo.

0.29 s

The four commands

system_profiler SPHardwareDataType
sw_vers
sysctl -a | grep -E "hw\.(nperflevels|physicalcpu|logicalcpu|memsize|pagesize|perflevel[01]\.)"
diskutil info disk0 | grep -iE "disk size|solid state|device block size"

What each gives you

The identity

system_profiler SPHardwareDataType

Model Name: MacBook Pro
Model Identifier: Mac16,8
Chip: Apple M4 Pro
Total Number of Cores: 14 (10 performance and 4 efficiency)
Memory: 24 GB
System Firmware Version: 13822.81.10

The model identifier is the field to quote when asking anyone anything. Mac16,8 is unambiguous in a way that “MacBook Pro” has not been for a decade.

This output also contains your serial number, hardware UUID and provisioning UDID. Strip those before pasting anywhere public.

The exact OS

sw_vers

ProductName:		macOS
ProductVersion:		26.3.1
ProductVersionExtra:	(a)
BuildVersion:		25D771280a

The build string is the part that matters. Apple ships multiple builds under one marketing version, including hardware-specific ones, and a bug present in one build of 26.3.1 may be absent in another. Reporting “26.3.1” is reporting less than you have.

The topology no GUI shows

sysctl -a | grep -E "hw\.(nperflevels|physicalcpu|logicalcpu|memsize|pagesize|perflevel[01]\.)"

hw.physicalcpu: 14
hw.logicalcpu: 14
hw.memsize: 25769803776
hw.pagesize: 16384
hw.nperflevels: 2
hw.perflevel0.name: Performance
hw.perflevel0.physicalcpu: 10
hw.perflevel0.l1dcachesize: 131072
hw.perflevel0.l2cachesize: 16777216
hw.perflevel0.cpusperl2: 5
hw.perflevel1.name: Efficiency
hw.perflevel1.physicalcpu: 4
hw.perflevel1.l1dcachesize: 65536
hw.perflevel1.l2cachesize: 4194304
hw.perflevel1.cpusperl2: 4

2

Three things here appear nowhere in the graphical tools.

physicalcpu equal to logicalcpu confirms no simultaneous multithreading: 14 cores means 14 hardware threads, unlike an x86 part where the two figures differ.

The per-performance-level cache sizes show how unlike each other the two core types are. Performance cores report 128 KB of L1 data cache and a 16 MB shared L2; efficiency cores report half and a quarter of those.

cpusperl2 reports 5 for the performance level. With 10 performance cores that means two clusters of five rather than a single pool, which affects how cheaply threads sharing data can coordinate.

hw.pagesize reading 16384 is the one that silently breaks scripts. Apple Silicon uses 16 KB pages where Intel used 4 KB, so any tool multiplying vm_stat page counts by 4096 understates memory by 75 percent.

The disk

diskutil info disk0 | grep -iE "disk size|solid state|device block size"

Disk Size:                 1.0 TB (1000555581440 Bytes)
Device Block Size:         4096 Bytes
Solid State:               Yes

The byte count is the useful part. It lets you separate the decimal-versus-binary unit question from real filesystem overhead when working out where storage went.

One command for all of it

macprofile() {
  echo "=== Hardware ==="
  system_profiler SPHardwareDataType | grep -vE "Serial Number|Hardware UUID|Provisioning UDID"
  echo "=== OS ==="
  sw_vers
  echo "=== CPU and memory ==="
  sysctl -n hw.model machdep.cpu.brand_string
  sysctl hw.physicalcpu hw.logicalcpu hw.memsize hw.pagesize hw.nperflevels
  sysctl -a 2>/dev/null | grep -E "hw\.perflevel[01]\.(name|physicalcpu|l1dcachesize|l2cachesize|cpusperl2)" | sort
  echo "=== Storage ==="
  diskutil info disk0 | grep -iE "disk size|solid state"
  echo "=== Battery ==="
  system_profiler SPPowerDataType | grep -iE "cycle count|condition|maximum capacity"
}

The grep -vE on the first block strips the three identifying fields, so the output is safe to paste into a public issue without editing it afterwards. Add the function to ~/.zshrc and it is one word from then on.

When this is worth doing

Filing a bug is the obvious case, and the build string plus the model identifier answer the two questions a maintainer will ask first.

Interpreting a benchmark is the less obvious one. A multi-core score on this machine is produced by 10 large cores and 4 small ones, so dividing it by 14 describes no core that exists. Knowing the split before reading the number prevents a category of wrong conclusion.

Buying advice is the third. The gap between an M4 and an M4 Pro is not one number, it is core counts, cluster arrangement and cache sizes, and sysctl reports all of them on any machine you can get a terminal onto, including one in a shop.

Four more things sysctl knows

The profile above covers what most questions need. Four additional sysctl values come up often enough to be worth naming.

sysctl -n kern.osproductversion kern.osversion hw.targettype hw.optional.arm64

kern.osversion returns the same build string as sw_vers, which is convenient when you want one command rather than two. hw.targettype returns the internal platform name, useful when comparing against Apple’s own documentation, which frequently uses those rather than marketing names.

For the instruction set extensions a binary can rely on:

sysctl -a | grep "hw.optional" | grep ": 1"

That lists every optional CPU feature the chip reports as present. It is the authoritative answer to whether a given extension is available, and it is more reliable than inferring from the chip name, because Apple has shipped feature differences within a generation.

Uptime, load and what is actually running

The hardware profile describes the machine. Two more commands describe its current state, which is usually the other half of a useful bug report.

uptime
sysctl -n vm.loadavg

Load average on macOS means what it does elsewhere: the number of processes wanting CPU, averaged over one, five and fifteen minutes. On a 14-core machine a load average of 14 means fully occupied, and sustained figures well above the core count mean work is queueing.

ps -A -o %cpu,%mem,comm | sort -nr | head -8

Ranked by CPU. Worth capturing alongside a profile when reporting anything performance-related, because a maintainer’s first question after “what machine” is nearly always “what else was running”.

Comparing two machines

The reason to have all of this in one command is usually comparison, and the comparison is easier if the output is stable and diffable. The macprofile function above prints in a fixed order with the identifying fields stripped, so:

macprofile > ~/mine.txt
# on the other machine
macprofile > ~/theirs.txt

diff ~/mine.txt ~/theirs.txt

The differences that matter are usually not the ones people expect. Two machines with the same marketing name and the same chip can differ in memory configuration, in storage size, and occasionally in OS build, and any of those can explain a discrepancy that looked like a software bug.

What none of this tells you

Static description has limits worth stating. None of these commands reports sustained clock frequency under load, thermal headroom, or how the machine behaves once it warms up, and those are frequently the properties that separate two apparently identical configurations in practice.

Frequency residency and package power need powermetrics, which requires root. Thermal state is partly available without privileges through pmset -g therm, which reports whether speed limits have been applied, and that is worth adding to any profile taken while investigating a performance complaint:

pmset -g therm

A machine reporting no thermal pressure while running slowly has a different problem from one reporting active speed limiting, and the profile alone cannot distinguish them.

Keeping it to hand

Add macprofile to ~/.zshrc and reload:

source ~/.zshrc
macprofile | pbcopy

pbcopy puts the whole profile on the clipboard, ready to paste into an issue with the three identifying fields already stripped. That combination, one word to generate and one pipe to copy, is the difference between including a proper profile in a bug report and writing “MacBook Pro, latest macOS” because gathering the real answer felt like work.

What to include in a bug report

The three fields a maintainer asks for first are the model identifier, the build string and the chip. Everything else in the profile is context they may or may not need.

sysctl -n hw.model; sw_vers -buildVersion; sysctl -n machdep.cpu.brand_string

Three lines, no identifying information, and enough for someone to know whether your machine is the same class as the one they tested on. Adding pmset -g therm is worth it for anything performance-related, since a machine under thermal limiting has a different problem from one that is not.