What Happens When You Press a Key

One Letter, Eight Processors, Three OS Layers

Reading time: ~15 minutes

You pressed the letter a.

It showed up in your terminal. That felt instantaneous. Sorry to tell you, but it wasn’t. Between the tip of your finger leaving that key and the character appearing on screen, at least eight separate processors handled your input, three operating system layers made decisions about it, and — if you’re working over SSH, and let’s be honest, how else are we talking to Claude at midnight — it crossed the internet encrypted and packetized inside a protocol designed by a Finnish researcher in the 1990s.

The eight processors: keyboard microcontroller, USB host controller, interrupt controller (APIC), your CPU — and on the SSH path, the story repeats on the remote side with its own interrupt controller, CPU, and the NVMe or storage controller that may have been woken to log the session.

This is what “pressing a key” actually is.

The Hardware You Never Think About

Your keyboard is a computer.

That’s not marketing fluff. Inside every modern keyboard is a microcontroller — a small chip running firmware — whose entire job is to watch a matrix of switches and tell the host machine when something changes. The cheap $15 keyboard on your desk has a processor dedicated to this task. It runs all day. You’ve never once thought about it. I didn’t think about it till I was penning this.

The microcontroller doesn’t monitor individual wires for each key. That would require 104 wires for a full keyboard. Instead, it uses an electrical matrix. Each key sits at a row/column intersection. The controller scans the matrix continuously — it sends a signal down one row at a time and checks which columns complete the circuit. If column 3 responds when row 7 is active, the a key is down.

Scan rate varies by firmware quality, a closed source binary, maybe I’ll crack one open and see what’s inside in a future blog. A mediocre keyboard scans at 1kHz — once per millisecond. A gaming keyboard might scan at 8kHz. Your mechanical keyboard probably does something in between both.

The Debounce Problem

Here’s the thing about physical switches: they bounce.

When a metal contact closes, it doesn’t close cleanly. It bounces — makes contact, breaks, makes contact, breaks — for somewhere between 1ms and 20ms before settling. Without software handling this, every keypress would register as between two and fifty keypresses, randomly. Anyone who’s seen my sad graveyard of keyboards — casualties of the Rust borrow checker — knows that’s a lot of bouncing. My current Keychron Q6 Pro is doing the Lord’s work so far.

The firmware debounces the signal. The most common approach is to require the key to be in the same state for N consecutive scans before reporting a state change. Some keyboards debounce in hardware with a small capacitor. Either way, this is why every keystroke we’ve ever made has an invisible 5–20ms delay baked in before the keyboard reports anything at all.

That’s why gaming keyboards advertise 1000Hz polling — lower polling rate means higher USB latency, and debounce delay is already baked into every keystroke. 8ms vs 1ms is 7ms of guaranteed additional input lag. Whether you can feel 7ms is a different argument.

[Narrator: You cannot]

USB: The Polling Station

Once the keyboard microcontroller decides you’ve pressed a real key, it needs to tell the host machine. On a modern keyboard, that means USB — or Bluetooth, which uses the same HID report format over a wireless link. I’m covering USB here because it’s what most developers are plugged into, and the wired path is where the interesting kernel machinery lives.

USB is a polled protocol. The host — your computer’s USB host controller — periodically asks each device “anything to report?” Like that daily standup that should be weekly, except USB never learns. Keyboards advertise themselves as HID (Human Interface Device) class devices and request a polling interval, typically 1ms (1000Hz) for gaming keyboards, 8ms (125Hz) for cheap ones.

When your keyboard has a keypress to report, it packages it as a HID report — a small binary structure, typically 8 bytes, containing a modifier byte (Shift, Ctrl, Alt, etc.) and up to 6 simultaneous key codes. Not character codes. Key codes — numbers that identify physical key positions independent of what those positions mean. Six slots. Modifiers don’t count — they have their own byte. That’s why Ctrl+Shift+A works fine (one key slot plus two modifier bits), but mashing A+S+D+F+G+H+J simultaneously starts dropping keys.

HID Report (8 bytes):
[ modifier ] [ reserved ] [ key1 ] [ key2 ] [ key3 ] [ key4 ] [ key5 ] [ key6 ]
  0x00           0x00       0x04    0x00     0x00     0x00     0x00     0x00
                             ↑
                    "key at position 4" — this is the 'a' key location

The 0x04 there is not the ASCII code for a. It’s the HID usage code for “the key at position 4 on a standard keyboard.” The keyboard doesn’t know what a means. It only knows where the key is.

That’s why keyboard layouts don’t require firmware updates. The physical scan code never changes. The meaning lives in a data file in /usr/share/X11/xkb/ or the kernel’s keymaps. Switching layouts is changing a lookup table, not rewriting firmware. That’s why Dvorak works, why you can type Cyrillic without a Russian keyboard, why your compose key sequences function.

The USB host controller receives the HID report. The hardware interrupt fires. A kernel driver wakes up.

The Kernel Input Subsystem: Three Translations for the Price of One

The Linux kernel’s input subsystem is where things get genuinely interesting. It handles a series of translations, and each one exists for a good reason.

HID scan codes → Linux key codes

The kernel HID driver receives the 8-byte report and maps the scan code (0x04) to a Linux key code (KEY_A, which is 30 in the kernel’s input event numbering). This mapping lives in a translation table in the kernel.

This distinction matters because keyboards from different manufacturers use different scan codes for the same physical key. The kernel normalizes them all into a single, consistent numbering space. After this step, all keyboards look the same to the rest of the stack. Abstraction and encapsulation — turns out it’s not just a user-space design pattern. The kernel does it too, and it does it first.

The kernel emits an input_event struct — a 24-byte structure that gets written to the event device:

struct input_event {
    struct timeval time;  // when it happened (16 bytes on 64-bit; simplified here)
    __u16 type;           // EV_KEY = keyboard event
    __u16 code;           // KEY_A = 30
    __s32 value;          // 1=press, 0=release, 2=repeat
};

(The timeval representation has changed since kernel 5.1 to avoid y2038 issues; I’m simplifying the size here.)

This event appears on a file like /dev/input/event7. Each input device on your system — keyboard, mouse, touchpad, power button, webcam button — gets its own numbered event file. Run ls /dev/input/ and you’ll see a dozen or more. Which one is your keyboard? cat /proc/bus/input/devices tells you, or try evtest and start pressing keys. Everything from here up — your terminal, your GUI, your shell — is reading from this device file.¹

Key codes → key symbols (where your keyboard layout lives)

This is where the letter a actually becomes the letter a — or A, or à, or α.

For a terminal, this translation happens in the kernel’s tty layer or in userspace depending on configuration. For X11 and Wayland, it happens in XKB — the X Keyboard extension, or its Wayland equivalent. Either way, a keyboard layout (a data file, not compiled code) maps KEY_A to the symbol a, and KEY_A + Shift to A, and KEY_A + various modifiers to accented variants.

This is why switching keyboard layouts works without rebooting. The physical scan codes don’t change. The firmware doesn’t change. Only the mapping table changes, in software, at this layer.

Three Paths from Kernel to Program

At this point the path splits. Where the key event goes next depends on what you were running.

Path 1: Your Terminal

If you were typing in a terminal, the key symbol goes into the PTY line discipline.

The terminal emulator holds the PTY master. It takes the resolved key symbol, encodes it as bytes (UTF-8 for most modern terminals), and writes those bytes to the master fd. The kernel line discipline processes them — in cooked mode, that means buffering them until Enter, handling backspace, echoing them back to the terminal for display. The bytes emerge at the PTY slave, where your shell reads them from stdin.

The echo is worth pausing on.

When you see the letter appear on screen as you type — that’s not your program. Your shell hasn’t seen that character yet. The kernel’s line discipline echoes it back through the PTY master, your terminal emulator reads the echoed byte, and renders it. In cooked mode, the shell doesn’t get anything until you press Enter.

Read that again. Every character you see while typing a command is the kernel drawing it, not the shell. The shell is sitting there, waiting for Enter, completely unaware of what you’ve typed so far.

This is why stty -echo works — you type and nothing appears, but the input is still going through. The kernel just stopped echoing. Useful for passwords. Extremely confusing when you accidentally set it wrong and can’t figure out why your terminal is “broken.” (You’ve run reset at least once in your career for exactly this reason. Now you know why it fixed things.)

That’s why stty -echo exists — and why password prompts use it. That’s why stty raw breaks readline — raw mode bypasses the line discipline entirely. No buffering, no backspace processing, no echo. Programs that implement their own line editing (vim, fzf, any TUI app) need this. Programs that relied on the kernel to handle it are now on their own.

And if you’ve ever hit Backspace and seen ^?, or pressed an arrow key and gotten ^[[A spat back at you — that’s the terminal and the program disagreeing about which mode they’re in. Those are the raw escape sequences for those keys. In cooked mode the line discipline interprets them. In raw mode it passes them through verbatim, and the program is supposed to handle them. When nothing handles them, you see the bytes as printed characters. reset fixes it because it forces the terminal back to sane defaults — cooked mode, echo on, line discipline doing its job.

Path 2: X11 / Wayland (GUI)

In a graphical environment, the input stack is different. The kernel’s input event device (/dev/input/eventN) is read by a userspace program — libinput or the legacy evdev driver — which passes events to the display server.

For X11, that’s the X server. It applies XKB key mappings and dispatches key events to whichever window has keyboard focus, via the X11 protocol. Client applications receive KeyPress and KeyRelease events through their Xlib or XCB connection.

For Wayland, the compositor is the display server. It reads directly from the input device through libinput, applies keyboard mappings, and sends key events to the focused client through the Wayland protocol’s wl_keyboard interface.

The compositor also handles the part where Super+L locks your screen before any application sees it. That’s a global key binding, caught at the compositor layer, never forwarded. Your application has no idea it was pressed.

Path 3: SSH (The Internet Leg)

This is the path that gets genuinely wild. If you’re in an SSH session — sitting at your laptop, typing into a shell running on a server three time zones away — the journey looks nothing like what you’d expect.

Your local terminal emulator receives the key event, encodes it as bytes, and passes it to the PTY master running locally. Those bytes emerge at the PTY slave — but on the other side of that slave is not a shell. It’s the SSH client (ssh process), which is sitting there reading bytes from its PTY like any other program would.

The SSH client takes those bytes and:

1. Feeds them into the SSH transport layer (RFC 4253), which encrypts them with AES or ChaCha20 and wraps them in an SSH_MSG_CHANNEL_DATA packet
2. Sends that packet over a TCP connection to the SSH server
3. The TCP stack on your machine fragments it, adds headers, computes checksums
4. Your NIC transmits it as Ethernet frames (or Wi-Fi frames, with their own layer of encryption)
5. It routes across however many hops it takes to reach the server

The server receives the TCP segment, the SSH server decrypts it, extracts the byte, and writes it to the PTY master of the remote shell’s PTY pair. The byte enters the remote line discipline. The remote shell reads it from its stdin … and breathe …

The character appearing on your screen follows the reverse path: the shell writes it, through the PTY, through SSH encrypted back, across the internet, decrypted by your SSH client, written to your local PTY master, read by your local terminal emulator, rendered on screen.

For a keystroke to a remote server in the same city, that round trip is typically 1–5ms. For a server across the continent, 30–80ms. For a server across an ocean, 150–300ms.

Every. Single. Character.

That’s why high-latency SSH sessions feel sluggish when you type — your terminal is waiting for the echo from the server before showing you the character, and the character is crossing the world to get there.

(Some SSH clients and terminal emulators implement local echo to hide this latency. They’re lying to you about what the server received. It’s a benevolent lie.)

The Numbers

Let’s put this together in time. You press a:

Local round trip: roughly 10–30ms from finger-lift to pixel. Dominated entirely by keyboard firmware debounce and USB poll rate.

The CPU doing the actual computation — running your shell, processing the character — is involved for microseconds of that. The waiting is physics and polling intervals.

One Letter, Summarized

Physical key
    └── keyboard microcontroller (scan + debounce)
           └── HID report over USB (scan code)
                  └── Linux kernel HID driver (scan code → key code)
                         └── kernel input subsystem (key code → input_event)
                                └── [branch]
                                     ├── PTY line discipline → shell stdin
                                     ├── X11/Wayland compositor → GUI app
                                     └── SSH client → TCP → internet
                                                            → SSH server
                                                            → remote PTY
                                                            → remote shell

From a piece of metal making contact to a byte arriving in your program: eight processors touched it, the kernel translated it three times, and if you’re on SSH, the internet carried it and brought the echo back.

The key you press is the simple part. Everything after is the iceberg.

What’s Next

That 0x04 scan code became the letter a somewhere in the stack. But what is the letter a? It’s not a byte. It’s not a character. It’s an agreement — one that took sixty years and several spectacular failures to reach.

Next up in Your String is Not What You Think It Is, I’m going to break your mental model of strings. The letter é might be one character or two. The flag emoji 🇬🇧 is four bytes pretending to be one glyph. And MySQL’s utf8 encoding can’t store an octopus emoji because someone in 2002 made a decision that seemed reasonable at the time.

Further Reading

• man 4 input — Linux input subsystem documentation. Describes input_event and the event device interface.
• USB HID Usage Tables — The official USB HID spec. Table 10 has the keyboard usage codes. It’s exactly as dry as you’d expect.
• XKB Configuration Guide — If you’ve ever wanted to understand why keyboard layouts live where they do.
• RFC 4253 — The SSH Transport Layer Protocol. Sections 6 and 7 cover the encryption and packet format. Readable as RFCs go.
• The TTY Demystified — Linus Akesson’s classic. Start here for a deeper look at the line discipline and TTY subsystem.

I’m writing a book about what makes developers irreplaceable in the age of AI. Join the early access list →

Naz Quadri has spent an uncomfortable amount of time reading kernel source to understand why a character takes 30ms to cross 2 centimeters. He blogs at nazquadri.dev. Rabbit holes all the way down 🐇🕳️.

1. Find your keyboard’s handlers with: grep -A5 "Keyboard" /proc/bus/input/devices | grep -oP '(?<=Handlers=).*'. On my machine that returns sysrq kbd event7 leds — sysrq means it can trigger magic SysRq sequences, kbd means the kernel sees it as a keyboard, event7 is the device file you’d read for raw keypresses, and leds means it can toggle your Caps Lock light. ↩

1. The Refresh Token Flow — Validating Against the DB

This is where the real security upgrade happens. Instead of just verifying the JWT signature, we now check the database to confirm the session still exists and hasn’t been revoked.

// auth.service.ts — updated refreshToken method
async refreshToken(rawRefreshToken: string) {

// Step 1: Verify the JWT signature and check expiry.
// jwtService.verify() throws an error if the token is expired or the signature is invalid.


let payload: any;
try {

payload = this.jwtService.verify(rawRefreshToken, {
secret: this.configService.get<string>('JWT_REFRESH_SECRET'),
});
} catch {
// The token is either expired or was tampered with
throw new UnauthorizedException('Refresh token is invalid or expired');
}


// Step 2: Load all active sessions for this user from the database.
// We need to find the specific session that matches this refresh token.

// Note: we explicitly request 'refreshTokenHash' since it has select: false on the entity.

const sessions = await this.sessionRepository.find({
where: { userId: payload.sub, isActive: true },
select: ['id', 'refreshTokenHash', 'expiresAt', 'isActive'],
});

// Step 3: Compare the incoming token against each session's stored hash.
// bcrypt.compare() handles this — it hashes the raw token and checks if it matches.

let matchingSession: Session | null = null;

for (const session of sessions) {
const isMatch = await bcrypt.compare(
rawRefreshToken,
session.refreshTokenHash,
);

if (isMatch) {
matchingSession = session;
break; // Found it — no need to check further
}
}

// Step 4: If no matching session exists, it was revoked (user logged out)

if (!matchingSession) {
throw new UnauthorizedException('Session not found or has been revoked');
}

// Step 5: Double-check the session's own expiry timestamp

if (new Date() > matchingSession.expiresAt) {
await this.sessionRepository.update(matchingSession.id, {
isActive: false,
});

throw new UnauthorizedException('Session has expired. Please log in again.',);
}

// Step 6: Record that this session was just used (for "last active" display)

await this.sessionRepository.update(matchingSession.id, {
lastUsedAt: new Date(),
});

// Step 7: Issue a fresh access token

const user = await this.usersService.findOne(payload.sub);
if (!user) throw new UnauthorizedException('User not found');

const newPayload = { email: user.email, sub: user.id, role: user.role };
const accessToken = this.jwtService.sign(newPayload, { expiresIn: '15m' });
return {
access_token: accessToken,
expires_in: 900,
};
}

Why this matters: A stolen refresh token is now useless the moment the legitimate user logs out. The database is the source of truth — not just the JWT signature.

Performance note: If a user has many sessions (lots of devices), iterating through all of them to bcrypt-compare can be slow. A common optimization is to include the session ID in the refresh token’s JWT payload, so you can look up the exact session directly and only do one bcrypt comparison.

2. Session Revocation — Logout (Single) and Logout-All

Single Device Logout
When a user logs out from one device, we mark that specific session as inactive. The refresh token is now dead — even if it hasn’t reached its JWT expiry date.

// auth.service.ts
async logout(userId: string, sessionId: string) {
// Find the session — and confirm it actually belongs to this user.
// Never skip this check! Otherwise, user A could log out user B.

const session = await this.sessionRepository.findOne({
where: { id: sessionId, userId, isActive: true },
});

if (!session) {
throw new BadRequestException('Session not found');
}

// Mark as inactive (soft delete — we keep the row for audit purposes)

await this.sessionRepository.update(session.id, { isActive: false });
return { message: 'Logged out successfully' };
}

// auth.controller.ts
@Post('logout')
@UseGuards(JwtAuthGuard) // Must be authenticated to logout
@ApiBearerAuth()
async logout(@Req() req, @Body() body: { session_id: string }) {
// req.user.userId is populated by JwtStrategy.validate()
return this.authService.logout(req.user.userId, body.session_id);
}

Logout From All Devices
This is the “I think my account was compromised” button. One call, every session gone.

// auth.service.ts
async logoutAll(userId: string) {
// Deactivate every active session for this user in one query

await this.sessionRepository.update(
{ userId, isActive: true },
{ isActive: false },
);

return { message: 'Logged out from all devices successfully' };
}

// auth.controller.ts
@Post('logout-all')
@UseGuards(JwtAuthGuard)
@ApiBearerAuth()
@ApiOperation({ summary: 'Revoke all active sessions for the current user' })
async logoutAll(@Req() req) {
return this.authService.logoutAll(req.user.userId);
}

3. Password Change = Revoke All Sessions

This one is critical and often missed. When a user changes their password, you should immediately invalidate all their existing sessions.

Here’s why this matters: imagine a user named Kofi suspects his account has been compromised. He changes his password. But without session revocation, any attacker who already has a valid refresh token can keep getting new access tokens for up to 7 more days -completely unaffected by the password change.

// auth.service.ts
async changePassword(
userId: string,
currentPassword: string,
newPassword: string
) {
// Get user including the password field (it has select: false on the entity)

const user = await this.usersService.findOneWithPassword(userId);

if (!user || !user.password) {
throw new BadRequestException('User not found');
}

// Verify the current password is correct before allowing the change

const isCurrentPasswordValid =  bcrypt.compare(currentPassword,user.password);

if (!isCurrentPasswordValid) {
throw new UnauthorizedException('Current password is incorrect');
}

// Hash and save the new password

const hashedNewPassword = await bcrypt.hash(newPassword, 10);
await this.usersService.updatePassword(userId, hashedNewPassword);

// ✅ CRITICAL STEP: Revoke ALL sessions.
// Any stolen refresh tokens are now completely useless.

await this.sessionRepository.update(
{ userId, isActive: true },
{ isActive: false },
);

return {
message:'Password changed successfully. You have been logged out from all devices. Please log in again.',
};
}

The user will need to log in again on all their devices — which is expected and correct. Security over convenience, always.

4. Listing Active Sessions – Letting Users See Where They’re Logged In

This is the feature users love. You’ve seen it in Google Account settings: “Your account is currently active on these devices.” Here’s how to build it:

// auth.service.ts
async getActiveSessions(userId: string) {
const sessions = await this.sessionRepository.find({
where: { userId, isActive: true },
order: { createdAt: 'DESC' }, // most recent login first
});

// Map to a clean format for the client.
// We never expose the refreshTokenHash.

return sessions.map((session) => ({
id: session.id, // client uses this to revoke a specific session
device: ${session.browser} on ${session.os}, // "Chrome on macOS"
deviceType: session.deviceType,
ipAddress: session.ipAddress,
lastUsed: session.lastUsedAt || session.createdAt,
loggedInAt: session.createdAt,
expiresAt: session.expiresAt,
}));
}

// auth.controller.ts
@Get('sessions')
@UseGuards(JwtAuthGuard)
@ApiBearerAuth()
@ApiOperation({ summary: 'List all active sessions for the current user' })
async getSessions(@Req() req) {
return this.authService.getActiveSessions(req.user.userId);
}

A sample response:

[
{
"id": "550e8400-e29b-41d4-a716-446655440000",
"device": "Chrome on macOS",
"deviceType": "desktop",
"ipAddress": "41.66.12.34",
"lastUsed": "2026-03-02T09:45:00.000Z",
"loggedInAt": "2026-03-01T08:00:00.000Z",
"expiresAt": "2026-03-08T08:00:00.000Z"
},
{
"id": "660e8400-e29b-41d4-a716-446655440001",
"device": "Mobile Safari on iOS",
"deviceType": "mobile",
"ipAddress": "41.66.12.35",
"lastUsed": "2026-03-01T22:10:00.000Z",
"loggedInAt": "2026-02-28T14:22:00.000Z",
"expiresAt": "2026-03-07T14:22:00.000Z"
}
]

Users can pass the session id to POST /auth/logout to revoke any specific session they don’t recognize.

5. Tradeoffs & Considerations

Nothing is free. Here’s what you’re taking on with this approach:

What you gain

• Real logout — revocation actually works
• Per-device visibility for users
• Protection against token theft
• Password change security (all sessions wiped)
• Audit trail of login activity

What you’re taking on
Database hit on every token refresh. Every time a client needs a new access token (up to every 15 minutes per active user), you query the database. For large-scale apps, this adds up.

Mitigation: cache session lookups in Redis with a short TTL, or embed the session ID in the JWT payload to enable a direct lookup instead of scanning all user sessions.
You need to clean up old sessions. Sessions pile up over time. Set up a scheduled cleanup job using @nestjs/schedule:

// sessions-cleanup.service.ts
import { Injectable } from '@nestjs/common';
import { Cron, CronExpression } from '@nestjs/schedule';
import { InjectRepository } from '@nestjs/typeorm';
import { Repository, LessThan } from 'typeorm';
import { Session } from './session.entity';

@Injectable()
export class SessionsCleanupService {

constructor(
@InjectRepository(Session)
private sessionRepository: Repository<Session>,
) {}

// Runs every night at midnight

@Cron(CronExpression.EVERY_DAY_AT_MIDNIGHT)
async cleanupExpiredSessions() {
// Delete sessions that have passed their expiresAt date

const result = await this.sessionRepository.delete({
expiresAt: LessThan(new Date()),
});
console.log(Cleaned up ${result.affected} expired sessions);
}
}

Refresh token rotation (optional but recommended). For maximum security, issue a new refresh token on every /auth/refresh call and invalidate the old one. This means if a refresh token is stolen and used before the legitimate user uses it, the legitimate user’s next refresh will fail — an early signal that something is wrong. This is more complex but closes a subtle replay attack window. User-Agent parsing is heuristic. The ua-parser-js library is good, but not perfect. Some browsers misreport themselves, and bots can spoof any user-agent string. Treat device info as helpful metadata for display purposes, not as a hard security boundary.

6. ** Conclusion + Key Takeaways**

Here’s a quick recap of what we built:

The core mental model to remember: JWTs are your fast lane; database sessions are your checkpoint. Short-lived access tokens (15 min) keep performance high because you only check the DB occasionally. Database-backed sessions give you the control to say “no” to a refresh token that was supposed to be dead.

If you’re starting out: the most impactful things to implement first are the session entity, the DB lookup on refresh, and the revoke-all-on-password-change. Everything else — device tracking, cleanup jobs, session listing — is valuable but additive.
Your users are trusting you with their accounts.
Follow for more backend engineering deep dives.

Every time you open your AI, you start over. You explain your project, your stack, the decision you made last Tuesday. Again.

You can stop doing this. In five minutes.

How it works

Hjarni is a note app your AI can read. You write notes. Your AI searches and reads them. One URL to connect.

Step 1: Create your first note

Sign up at hjarni.com. Create a note about something you’re tired of re-explaining.

Title: Tech Stack

Rails 8 + SQLite.
Deployed on Hetzner via Kamal.
MCP server built into the app.
Tailwind + Turbo, no React.
Solid Queue for background jobs.

Step 2: Connect to Claude

Go to Settings. Find Connectors. Add a custom connector.

Name it “Hjarni” and paste https://hjarni.com/mcp as the URL. Done.

Step 3: Ask Claude something

Start a new conversation. Don’t paste any context. Just ask something only your notes would know.

“Write me a pitch based on what you know about my product.”

Claude searches your notes. Finds the answer. No copy-pasting.

What to save next

If you’ve typed it twice, save it. Project context. Decisions and their reasons. Research conclusions.

Every note you add makes the next conversation better. Ten notes in, you just talk to your AI like it’s been on your team all along.

The free tier gives you 25 notes with full MCP access. No credit card.

👉 Start writing free

Works with Claude and ChatGPT today.