Skim
Free, open-source AI email client for Windows
Start new thread

Skim - Free, open-source AI email client for Windows

byā€¢
Skim is a free, open-source (MIT) email client for Windows. āœ‚ļø Minimal on purpose: no calendar, no rules engine, no bloat. Fewer buttons, less cognitive load. āš” Native Rust core (Tauri 2): ~5 MB installer, sub-second cold start, instant full-text search. šŸ”’ Local-first, offline-ready, zero telemetry. āœ¦ AI on your terms: bring your own Anthropic or OpenRouter key and Skim drafts replies in your voice and answers questions across your whole mailbox.

Add a comment

Replies

Best
Maker
šŸ“Œ
I built Skim because I wanted a Windows email client that doesn't suck that hard and couldn't find one. Now I wanna share it with you. Skim is open source and MIT-licensed, free forever. No subscription, no telemetry. Join as a contributor plz! šŸ™ Skim is small: a native Rust core (Tauri 2, no Electron), a ~5 MB installer, offline-first IMAP sync into local SQLite, instant full-text search, and a keyboard-first UI with a Ctrl+K palette. āœ¦ The AI part works on your terms: paste your own Anthropic or OpenRouter key to enable AI features: āœļø it drafts replies in your voice (and can learn from your sent emails) šŸ“„ summarizes your unread mail šŸ” answers questions across your whole mailbox, with cited sources Pretty basic, huh? Right. That's all I need, and I believe there are people who need the same. Requests go straight from your machine to the provider: no middleman, no markup, no subscription. Let me share a bit of the philosophy I try to follow while building Skim: āœ‚ļø Minimalism. It's an email client and that's it. No integrations -> no bloat. Cognitive load matters! šŸŽÆ Contextual actions. Skim tries to be the kind of software that thinks FOR you to save your cognitive resources. Buttons show up only when needed, the app always does the most obvious thing, and the defaults should be the best ones. āš” Resource efficiency. Skim is built to run in the background 24/7, so it stays as humble as possible and eats as few resources as it can. That's why the installer is under 5 MB šŸ˜„ So, with all that said: please, have fun with Skim! I'd love your feedback, especially from folks tired of heavy clients. What would make you switch? What's missing? How could I trick you into contributing? šŸ¤˜

Ā I've migrated from Windows this year, but upvoted for branding only - great job, I like the anti-boring approach ;)

Ā Congrats on the launch! LOVE the website - you clearly put a lot of thought and personality into it.

Maker

Ā that's true, I did! So glad you liked it! šŸ«¶

I will take a look because anything has the be better than MS Outlook these days! Does it handle multiple email accounts?

Maker

Hey, my thoughts exactly šŸ˜„

No multi-account support rn. I thought it wasn't needed, but just yesterday I found myself in a situation where I actually did!

Soooo I'll probably add multi-account support in the next release or so. There are usually 2-3 releases a day btw šŸ˜„

Maker

Ā Just added multi-account feature in new 1.0.4 release! šŸŽ‰

Curious how you handle Gmail OAuth secrets in a public repo though! Great launch, refreshing branding, and love every MIT license.

Maker

Ā Hey, I'm flattered you love the branding! It's something I'm secretly proud of. At first I went the usual route - you know, purple, polished, sterile shit - but then I thought, "Hey, it's free and open source, right? Fuck it, let's have fun," and ended up with this wonderful zine landing you're looking at.

Okay, flex time's over - to your question.

tl;dr: there are no secrets in the repo. The magic is called PKCE.

Brace for the AI-slop explanation, if you're curious:

  1. Gmail uses the installed-app flow (loopback + PKCE), where the "client secret" isn't actually a secret. Google's own docs say the client secret for installed apps "is obviously not treated as a secret" ā€” a distributed desktop app can't keep one confidential, so security comes from PKCE (S256) and the 127.0.0.1 loopback redirect, not from a secret. There's no server in the middle; the token exchange goes straight from your machine to Google.

  2. The client ID/secret aren't committed ā€” they're baked in at build time from env vars (SKIM_GOOGLE_CLIENT_ID / _SECRET), injected in CI from GitHub Actions secrets. So official installers carry them, but nothing sensitive sits in the source tree. Build from source and you just plug in your own Google Cloud project.

  3. Microsoft/Outlook is a true public client ā€” PKCE only, no secret at all.

  4. Per-user tokens never touch disk in plaintext. Refresh tokens, app passwords, and the AI API key live in the Windows Credential Manager ā€” never in the SQLite DB or any config file.

So "public repo" and "OAuth" coexist fine here: the only thing that would be dangerous to leak (per-user refresh tokens) never leaves your OS keychain, and the app-level identifiers are the kind Google/Microsoft explicitly design to ship inside native binaries. šŸ”’

Hey Nikita, congrats!
Any plans to release a Mac version?

Maker

Ā thanks! I don't use Mac, but there's no obstacles to have such version. It would require new building pipeline and some settings. I invite you to šŸ˜„

Do you have plans for Mac or Linux, or is Windows the main focus? The ~5MB installer and sub-second startup would be a pretty strong selling point for anyone tired of bloated Electron apps, so I'm wondering if expanding makes sense or if you want to keep it tight and focused.

Maker

Ā I'd rather focus on Windows, but not because it's against product philosophy, but because I use only Windows šŸ˜„ If you want to add a builder for another OS - feel free to !

The Rust-backed cold start is genuinely instant, feels closer to opening a text editor than an email app. Glad the AI part is opt-in with your own key instead of some bundled subscription, keeps things lean.

Maker

Ā True! šŸ¤˜

love that this is BYOK instead of yet another subscription tier, that's rare for an email client. since the AI can answer questions across the whole mailbox, does it send full email bodies to the API per query or is there some local pre-filtering first so you're not shipping your entire inbox history every time you ask something?

Maker

Ā nice one! And no, it doesn't ship your inbox on every query. Retrieval is local first.

Under the hood the AI is a tool-calling agent. When you ask something, it searches your mailbox on your machine. What crosses the wire from that search isn't email bodies, it's compact rows: date, sender, subject, and a snippet capped at ~160 chars. That's the pre-filtering step you're hoping for: the full-text index narrows thousands of emails down to a handful before anything touches the network.

Full bodies go out only for the specific emails the model then chooses to open - and even those are truncated (roughly 6k chars per email, ~10k for a whole thread). Per query it's bounded to about a dozen reads, not your entire history. Trash and junk are excluded unless you explicitly ask for them.

finally an email client that respects my storage and my sanity, the 5mb install is unreal on windows. love that i can just plug in my own api key and skip the data-sucking defaults.

Maker

Ā Enjoy! šŸ«¶

Honestly the local-first angle is super appealing, and a tiny Rust installer sounds great. One thing that would seal the deal for me though, kind of a small ask, is per-account send aliases so I can manage work and personal replies without juggling separate logins. Would fit nicely with the minimal vibe too.

Maker

Ā hey, looks like a solid feature! Tbh, I don't use aliases myself, so I'd love to understand the workflow. I'd super appreciate if you'll share more details in Github issue that I created for your request:

A few things that'd help me nail the use case (feel free to add comment in Github issue):

  1. What's your setup, one email provider (e.g. a Gmail with a couple of addresses attached), or genuinely separate ones like a work domain + a personal Gmail?

  2. Do work and personal mail land in the same inbox for you, or would you rather keep them separate but just share one "send" experience?

  3. What's missing in the current multi-account switcher for your case, is it the extra login, mixing the inboxes, or specifically picking who the reply comes from?

  4. When you reply, should the app auto-pick the right "From" based on which address the original email was sent to?

love how lean this is, the rust footprint is wild. one thing that would sell me even more is proper vim keybindings for the inbox and reading panes, j/k navigation feels like a natural fit for something this minimal.

Maker

Ā Yeah, j/k navigation works in inbox!

123
Next
Last