The two pictures probably show the same binary being analyzed. But the two Cutter versions might not be the same, and that's likely the cause for the discrepancy you see.
Cutter is a front end for Rizin, and disassembly is performed by Rizin and then reformatted by Cutter for display. There was a change in Rizin v0.5.0 (February 2023) that affects the display of stack variables: The Rizin team removed the old bp/sp related addressing for x86 family architectures, because it often caused misleading results. Instead, all variables would from then on be displayed as
stack - hexoffset , as is the case in your first picture.
Before this change, Rizin users would sometimes see two different variable names/offsets, and not realize they resolved to the same address (and thus the same variable). This doubled up the number of detected variables at the top of the function, led to a lot of confusion, and also made integrating the stack variables into decompilers (such as rz-ghidra) a mess.
If you use a Cutter version released in or after February 2023 (such as Cutter v2.2.0-rc1 or later), that one likely packages a Rizin version containing the mentioned change. AFAIK, the behavior of the display of stack variables cannot be configured.
I think you might be following a tutorial such as the one linked below. If that's the case and you want to followed it closely, you can simply install the same version of Cutter. The author of the linked tutorial is using Cutter v2.1.0 from June 2022, which contains rizin v0.4.0. If you're using Linux, the AppImage of that version is still available on the releases pages.
Tutorial (not mine):
'Exploiting Return Oriented Programming (ROP) tutorial - Binary Exploitation PWN101' on YT