Swiftpoint Z3 · profiles, tools and guides · unofficial
An ordinary mouse has two buttons, a wheel and a DPI switch — that is the whole vocabulary. The Swiftpoint Z3 has thirteen programmable buttons, five of which measure how hard you press, a gyroscope that feels you tilt it, a 64 × 32 screen on the side and 80+ profiles stored inside the device. What a button does is not a property of the button: it is a property of the profile that happens to be active. This is where those profiles get shared, built and read — in a browser, with nothing to install and nothing uploaded unless you publish it.
Browse community profiles Build one yourself What the mouse is
01 — the site
Three of the four never send anything anywhere. The Builder, the
Checker and the OLED editor all work on a file inside your own
browser, and a .spcf only leaves your machine when you
deliberately publish it. If you have one question — does
anyone already have my setup?, can I make my own?,
what does this file do? — one of these four is the
answer, and all four are one click away.
.spcf.
For: “nobody has my exact setup” →
.spcf Checker
Open any profile — one you downloaded, or one you just
built — and read it in plain language: every trigger, every
nested binding, the DPI stages, the tilt ranges and the OLED
animation. It also warns when a binding fires inputs the instant
it activates, or loops forever.
For: “what does this file actually do?” →
OLED Editor
Draw 64 × 32 one-bit images and animations for the screen on
the mouse: pixel tools, layers, keyframes with easing, sixteen
ready-made examples, PNG / sprite sheet / ZIP export — then
push the result straight into a profile.
For: “put something on that screen” →
All four run from the keyboard too — Ctrl + K anywhere opens the jump bar — and the guides walk through the Builder from the first binding to nesting, tilt and OLED work.
02 — the hardware
The Z3 is not a mouse with more buttons. It is a small computer that happens to point. What the hardware gives you is a set of inputs — presses, force levels, angles — and what you do with them lives in software, on the device, per game. The same body of plastic is an aim setup in one game, a macro pad in the next and a keyboard-nub for CAD at your desk, without anything about it changing. In the manufacturer's own words it replaces a mouse, a macro pad, an analog joystick and part of a keyboard in one shell.
It is also the first wireless mouse in the Z series: the Z2 was wired, the Z3 speaks 2.4 GHz, Bluetooth 5.0 and USB-C at the same time, and carries eighty-plus profiles in its own memory. That last point is the one that matters for this site — a profile is a file, and a file is something you can share.
Two main buttons and a wheel at the front; two fingertip buttons under the index and middle fingers; two triggers that read both pushed and pulled; two edge buttons along the top left; two thumb buttons on the side. Thirteen, all of them where your hand already is — none of them needs a grip change to reach, which is the only reason thirteen is a number you can live with. Five of them also read how hard you press them, and those five are what turn a single button into two or three.
Thirteen buttons is sixteen press inputs. The spec counts a trigger once; the mouse reports its push and its pull separately. On top of that come the inputs that are not buttons at all — and every single one of them is bindable:
Five of the buttons do not just report that they were pressed, they report how far they went. That turns one press into up to three actions, and you decide where the stages begin. The mouse vibrates each time you cross into the next one, so you learn the threshold by feel instead of by looking at a progress bar.
The pattern below is the one most shooters end up with: the right button aims on a light press, holds your breath when you press harder, and drops the DPI all the way down while you keep holding it — and letting go puts the DPI back. One finger, three actions, and nothing to release except the button itself.
Light press, harder press, hardest press — three different actions out of one button, with the thresholds under your control and a vibration to mark each one. It is the single feature that makes a thirteen-button mouse usable rather than a puzzle.
A gyroscope reads how you hold the mouse. Tilt left and right can be a real analog axis or a plain action — leaning around a corner, switching browser tabs. Clip the joystick extender underneath and the same gyro becomes an analog stick for flight sims and 3D navigation.
The 64 × 32 monochrome OLED shows the active profile, DPI, battery and connection — or your own text and images. It can also show how hard you are pressing, which is how you get better at Deep Click. Lift the mouse and it goes into config mode, so settings are changed where the mouse is.
Vibration is an action, not a side effect: it can mark a Deep Click stage, confirm a profile switch, or sit in a binding's list of actions beside the key press. It is also a notification channel — a script can buzz the mouse when your build finishes.
Profiles are stored on the device, so they follow it. Plug the Z3
into a school computer, a work laptop or a LAN machine and the
profiles are already there — no software, no install, no
cloud. The control panel can also link a profile to an
application, so starting a game switches the mouse into that
game's profile and closing it switches back. A profile you
download here is a .spcf, and you can write one
yourself in the Builder.
03 — the part nobody expects
The X1 Control Panel is not just a settings window. It exposes a local IPC socket, and anything that can open a socket can drive the mouse: switch profiles, set DPI, buzz the haptics, paint the OLED, zero the gyro. Python, Node, AutoHotkey, a shell script, a watchdog on your second monitor — everything the control panel can do to the mouse, a script can do too.
It is off by default. Enable Enable X1 API in the X1 options menu, restart the app, and the endpoint is yours — a named pipe on Windows, a Unix socket on Linux and macOS. That is the whole difference between the two snippets below; the protocol itself is one line in, one line out.
import os
import socket
# Windows is a named pipe, macOS and Linux a Unix socket.
ENDPOINT = (
r"\\.\pipe\swiftpoint.x1.v2.command"
if os.name == "nt"
else "/tmp/swiftpoint.x1.v2.command"
)
def send(command: str) -> str:
"""One command in, one line out. The X1 app has to be running."""
if os.name == "nt":
fd = os.open(ENDPOINT, os.O_RDWR)
try:
os.write(fd, (command + "\n").encode("utf-8"))
return os.read(fd, 1024).decode("utf-8").strip()
finally:
os.close(fd)
with socket.socket(socket.AF_UNIX, socket.SOCK_STREAM) as sock:
sock.connect(ENDPOINT)
sock.sendall((command + "\n").encode("utf-8"))
return sock.recv(1024).decode("utf-8").strip()
print(send("DPI 1600")) # OK
print(send("Profile Get")) # Desktop
print(send("Vibrate 70 100")) # OK — the mouse buzzesimport net from 'node:net';
// Windows is a named pipe, macOS and Linux a Unix socket.
// The doubled backslashes are JavaScript escaping, not the path.
const ENDPOINT = process.platform === 'win32'
? '\\\\.\\pipe\\swiftpoint.x1.v2.command'
: '/tmp/swiftpoint.x1.v2.command';
function send(command) {
return new Promise((resolve, reject) => {
const sock = net.connect(ENDPOINT);
let answer = '';
sock.setEncoding('utf8');
sock.on('connect', () => sock.write(`${command}\n`));
sock.on('data', (chunk) => { answer += chunk; });
sock.on('end', () => resolve(answer.trim()));
sock.on('error', reject);
});
}
console.log(await send('DPI 1600')); // OK
console.log(await send('Profile Get')); // Desktop
console.log(await send('Vibrate 70 100')); // OK — the mouse buzzes
Two commands to try first: Profile List shows you what is
on the device right now, and OLED Message Ready puts a
word on the screen in the mouse. From there it is a loop — read
a status from somewhere, send a command, done.
A sample device, answering canned replies — the point is
the shape of the conversation. Send OLED Message Ready and
the words appear on the mouse; send Vibrate 70 100 and it
buzzes. Because the API talks to the mouse and not to the cloud, it
also works for the things a profile cannot know: which window is in
front, how long the build has been running, whether the match is over.
Switch on a hotkey or a watchdog script, when X1 cannot tell that anything changed.
Clock, CPU temperature, the current track, your live KDA — pushed to the mouse by a script.
Green in the queue, red when you are dead, blue while recording. One line of code each.
Compilation finished, upload complete, an email arrived: a haptic pulse, no screen needed.
04 — the work
The hardware is the same in all of these. What changes is the profile, which is why a profile is worth stealing: a good Tarkov layout is a hundred decisions you would otherwise make one painful evening at a time. Here is what those decisions usually look like.
CS2, Valorant, Tarkov, Hell Let Loose, Rainbow Six. Hold the right button to aim and the buttons underneath it get a second meaning.
WoW, Final Fantasy XIV, the usual suspects. You run out of keys long before you run out of buttons, which is the whole problem this mouse solves.
Fusion 360, SolidWorks, AutoCAD, Revit. The mouse becomes a navigation device: the gyro does what a three-button mouse would need a hand for.
Photoshop, Illustrator, Premiere, DaVinci, Canva. Tools on the fingertips, timeline work on the triggers, undo always where your hand expects it.
Chrome, Excel, Sheets, mail. The everyday win: tab switching, editing and meetings without taking your hand off the mouse.
OBS, a meeting, a talk. Scenes, mute and the laser pointer on inputs that do not disturb whatever you are presenting.
These are sketches, not presets. When a community member publishes the version that actually works for them, it is in the gallery — tagged with the game, and readable before you download it.
05 — the file
A profile is easy to picture as a list of keys. It is closer to a very small program, and four words are enough to read one: a group holds triggers, a trigger runs actions, and a trigger can sit nested under another one. Every guide on this site uses those four words, and so does everything on this page — including the tools, which are built to show you exactly these four things about a file.
Five lines, one file, and every one of them visible before you install it — that is what the profile cards and the Checker are for. If you would rather write the file than read it, the quickstart has you building one in five minutes.
06 — the short version
Search the profiles for your game. Read the mappings on the card, download the file, and import it with the X1 Control Panel. Ten minutes, no new software.
Open the Builder and start from a blank profile or an existing one. The quickstart walks through your first binding; the bindings guide is the reference for every input the mouse has.
Drop it into the Checker. It prints every trigger and action, every nested binding, the DPI stages and the OLED frames — and tells you what is bound to nothing, what fires inputs on activation, and what loops.
Sign in with Discord and publish. A published profile keeps the author’s name, shows up on the front page and in search, and comes back out of the download exactly as it went in. The OLED editor is where a published profile gets its screen.
07 — the people using it
Every profile here was exported from the Swiftpoint app by somebody and uploaded on purpose. That is the whole moderation story: there is nothing hidden, and you can read what a file does before you install it. The newest ones are below — the ones carried over from the old Swiftpoint forum say so.
The guides cover the Builder from the first binding to nesting, tilt and OLED work. The ones worth starting with are interactive: a recording of the real Builder, playable inside the editor, which performs every step while you watch. Replaying a guide changes nothing on your account and uploads nothing.
Everything that changes gets written down in the updates, marked as a website update or a mouse update so you can read only the half that concerns you. And if something is broken, stuck or confusing, the forum is a support desk: you open a ticket, a moderator marks it in progress, on hold or closed, and you are told which — no waiting in the dark.
08 — the small print, in short
.spcf never sends it anywhere.