# KIKA Journal — full text (akakika.com) > A short app catalog, then the full text of every published post on akakika.com, newest first. The short index is > https://akakika.com/llms.txt. Posts are dated: a version or count in a post was current on its date; the catalog > below has today's versions. Author: Kika (@akakikaaa on X, aka-kika on GitHub). Source code for the apps > mentioned here lives at https://github.com/aka-kika. # App catalog ## mcpock - Summary: Menu bar app that checks every MCP server your AI agents use and says which ones need you. - Platform: macOS 26 or newer - Price: Free, open source - Status: Released, v1.10.7 - URL: https://mcpock.com/ ## iconzzz - Summary: Crops images into Mac app icons, names them on-device and keeps one searchable library, with Icon Composer built in. - Platform: macOS 26 or newer, Apple silicon - Price: Free, open source - Status: Released, v0.8.2 - URL: https://github.com/aka-kika/iconzzz ## Pallet - Summary: Color palette collection that themes itself, plus a Mac app that reads the palette out of any image or screen area. - Platform: macOS 26 or newer, and web - Price: Free - Status: Released, v2.0.3 - URL: https://akakika.com/pallet/ ## Feed - Summary: Private feed of agent reports on one Mac: publish once, read whole, publish-only keys. - Platform: macOS - Price: Free, open source - Status: Released, v1.3.0 - URL: https://feed.akakika.com/ ## Personal Ops Manual - Summary: Mac app over one folder of Markdown pages that describes your setup; every AI agent can read it and one operator writes. - Platform: macOS 26 or newer - Price: Free, open source - Status: Released, v2.2.4 - URL: https://ops-manual.akakika.com/ ## ClipboardSanitizer - Summary: Menu bar app that strips formatting, tracking parameters and whitespace junk from your clipboard. - Platform: macOS 12 or newer - Price: Free - Status: Released - URL: https://akakika.com/clipsan/ ## LocalhostWatcher - Summary: Menu bar app that detects localhost services, checks their health and helps relaunch the stack. - Platform: macOS - Price: Free - Status: Released - URL: https://akakika.com/localhostwatcher/ ## RESQ - Summary: Turns OCR scraps and rough notes into clean Markdown, local-first. - Platform: macOS (Apple Silicon) - Price: Free - Status: Released - URL: https://akakika.com/resq/ ## Focus - Summary: Lightweight, keyboard-friendly pomodoro timer. - Platform: macOS - Price: Free - Status: Released - URL: https://akakika.com/focus/ ## FolderWardrobe - Summary: Customize Finder folder colors, icons, tags and comments with reusable presets. - Platform: macOS 13 or newer - Price: Free - Status: Released - URL: https://akakika.com/folderwardrobe/ ## Sift - Summary: Native Mac app auditor with local AI: explains, scores and tracks every app on your Mac (licences, subscriptions, updates), with a Trash-first uninstaller. - Platform: macOS 14 or newer, Apple silicon - Price: Free during the beta, open source (MIT) - Status: Released, v1.12.3 - URL: https://sift.akakika.com/ ## reshelf - Summary: Catalog, organize and clone the open-source repos you actually use, local-first. - Platform: macOS - Price: Free, open source - Status: Released, v1.9.0 - URL: https://aka-kika.github.io/reshelf/ ## WAWE - Summary: Keyboard-first glossary for tech terms in the menu bar. - Platform: macOS - Price: Free, open source - Status: Released, v0.2.0 - URL: https://aka-kika.github.io/WAWE/ ## Subtext - Summary: Floating, keyboard-first panel for your macOS system text replacements. - Platform: macOS - Price: Free, open source - Status: Released, v1.0.0 - URL: https://aka-kika.github.io/Subtext/ ## RawDrop - Summary: Drop anything into your knowledge vault, then compile it into a wiki with one local model. - Platform: macOS - Price: Free, open source - Status: Released, v0.3.8 - URL: https://github.com/aka-kika/rawdrop ## HTMELLY - Summary: Local-first reader for HTML and Markdown folders. - Platform: macOS - Price: Free, open source - Status: Released - URL: https://aka-kika.github.io/HTMELLY/ ## Seedling - Summary: Plants reusable Markdown seed files into fresh project folders. - Platform: macOS - Price: Free, open source - Status: Released - URL: https://github.com/aka-kika/Seedling ## The Librarian - Summary: Skill librarian MCP server that keeps a whole skill collection out of agent context. - Platform: Any MCP client - Price: Free, open source - Status: Repository - URL: https://github.com/aka-kika/the-librarian ## hig-mcp - Summary: Apple's Human Interface Guidelines as structured data for coding agents. - Platform: Any MCP client - Price: Free, open source - Status: Released, v0.1.1 - URL: https://github.com/aka-kika/hig-mcp ## kika-obsidian-mcp - Summary: Lets any agent read and write Obsidian notes, no plugin and no API key. - Platform: Any MCP client - Price: Free, open source - Status: Released, v0.3.0 - URL: https://github.com/aka-kika/kika-obsidian-mcp ## Color Palette Extractor - Summary: Turns any image into a color system: palette, dark and light themes, WCAG scores, design tokens. - Platform: Any MCP client - Price: Free, open source - Status: Released, v0.5.0 - URL: https://github.com/aka-kika/color-palette-extractor-mcp ## unity-super-mcp - Summary: Unity chores an agent can run: LiveOps, build size, store compliance. - Platform: Any MCP client - Price: Free, open source - Status: Repository - URL: https://github.com/aka-kika/unity-super-mcp ## akakika-skills - Summary: The 28 agent skills Kika actually uses, cleaned to one standard. - Platform: Any agent that reads SKILL.md - Price: Free, open source - Status: Repository - URL: https://github.com/aka-kika/akakika-skills ## UNDRDR - Summary: 1,000 open-source repos under 1,000 stars, curated. - Platform: Web - Price: Free - Status: Live - URL: https://undrdr.com/ ## Mochi's Daily Quest - Summary: Tiny Tamagotchi-style desktop companion that grows with every task. - Platform: macOS (Apple Silicon) - Price: Free - Status: Released - URL: https://akakika.com/mochi/ # Journal posts --- # SIFT 1.12 — WHERE UPDATES REALLY LIVE - URL: https://akakika.com/blog/sift-1-12 - Date: October 2026 - Category: APPS - Summary: Sift 1.12 learned a fourth place updates live, says what every app is built with, and opens self-updating apps instead of handing me a download. Plus the hotfix that followed an hour later. Sift is my macOS app auditor: what each installed app is, whether it earns its place, what it costs, what needs updating. Version 1.12 is about the last part. It learned a fourth place updates live (GitHub releases), it now says what every app is built with, and for apps that update themselves it just opens them instead of handing me a download to swap in by hand. Most of the ideas came from reading another developer's open-source updater, and that is credited in the repo. ## The friction Sift knew three places to look for updates: the App Store, Homebrew, and an app's own Sparkle feed. A lot of the small apps I run come from none of those. They are direct downloads from a GitHub releases page, and in Sift they all read as "unavailable". The second annoyance: when Sift did find a Sparkle update, the button opened the download. Then I had to quit the app, drag the new copy over the old one, and reopen it. The app has its own updater that does all of that in place. Sift was ignoring it. ![Sift's main window: a list of installed Mac apps with 1 to 5 relevance scores, and the detail panel for one app](https://akakika.com/images/sift/sift-know-every-app.jpg) ## Why I built it I tried [DuoUpdater](https://github.com/jizhi0v0/duo-updater), an open-source macOS updater, and my reaction was, more or less, "this is insane, what can we take from it". It made Sift's update tab look thin. > Sift is an auditor, not an updater. The answer was never to copy the engine. So I borrowed the ideas that fit an auditor and kept them small: GitHub as an update source, what an app is built with, and what a version number actually means. Each piece was tested against my real Applications folder before it shipped. Around the same time someone pointed out that nowhere except GitHub did it say Sift needs a model for its analysis (Ollama, or an API key). They were right. The site says it now. The real fix is bigger than a sentence, and it is what the next version is for. ## What it does - **GitHub releases as an update source.** Save a GitHub repo as an app's link and the repo's latest release answers the update question. No drafts, no betas, no `nightly` tags, and a Mac App Store copy is never answered by GitHub. - **No rate limit to run into.** GitHub allows 60 API calls an hour without a token, and even a "nothing changed" reply spends one. So Sift does not call the API at all: it reads where the repo's `/releases/latest` page redirects to, and the tag is right there in the address. Thirty real checks took about two seconds. - **Open app to update.** For an app with its own Sparkle updater, the button opens the app so it installs the update in place. The download is still there as a quieter second button. - **Built with.** A new fact under every analysis: Electron, Tauri, Flutter, Qt, Java, Chromium, Mac Catalyst, or native. It is read from the app bundle alone, nothing is run. On my Mac: 100 apps in 0.06 seconds, 13 of them Electron. - **Build-number updates.** Some apps ship a new build under the same version number. Sift now finds those and shows them as `1.0 (390)`. - **Versions read the way a person reads them.** `2.0.0` no longer counts as newer than `2.0`, and `1.2.3-beta` no longer counts as newer than `1.2.3`. - **A quiet license note.** A paid app about to jump a major version gets one line: the current license may not cover it. ## The hotfix 1.12.0 crashed about fourteen seconds after launch, on my own Mac, right after I updated. Two installed apps shared one bundle ID (an app and a test copy of it), and one had a saved GitHub link. The wider update check put that pair into one batch for the first time, and an older piece of code built a lookup keyed by bundle ID. Swift stops the program on a duplicate key. I missed it because I tested in a side build with empty data. The fix took minutes, plus a test that reproduces the exact crash. 1.12.1 ran as the real build against my real data before anything was published, and that check is part of every release now. 1.12.0 was live for about an hour. ## Where it is now Sift is at 1.12.3. Two more fix releases followed on 14 October, both about license keys: a key now stays locked until you ask for it, and revealing, copying or removing one asks for Touch ID. Free during the beta, MIT, macOS 14 or newer, Apple silicon. The analysis needs a model: Ollama on your Mac, or an Anthropic, OpenAI, Gemini or OpenRouter key (Gemini and OpenRouter have free tiers). Scanning, licenses, updates and uninstall work without one. Next, for 1.13: an analysis that works out of the box, so nobody meets Ollama as a wall, and real in-place updates, with the old copy moved to the Trash as the way back. --- # ICONZZZ - URL: https://akakika.com/blog/iconzzz - Date: October 2026 - Category: APPS - Summary: A calm Mac app that turns a pile of icon images into a named, searchable library, with Icon Composer built in. Free and open source, nothing leaves the Mac. *October 2026 · Kika (@akakikaaa)* I make app icons in batches. Renders, variations, half-ideas. They pile up as `Img 1044`, `mj var3` and `ChatGPT Image ...`, each one with the wrong corners and only one size. Finding the blue one from last month meant scrolling a folder of hundreds of files. Getting one ready for an app meant cropping, resizing and renaming by hand, every time. So I built iconzzz, for the simplest reason: to get control over my icon ideas, and to have an icon ready for my app, easily and fast. ![iconzzz main window in light mode: sidebar with Active, All Icons, Used and Collections, a grid of app icons, and the crop inspector](https://akakika.com/images/iconzzz/iconzzz-main-window-light.png) ## The idea One folder, one window. Drop icons in, get the right shapes and sizes out, and don't think about it again. The folder on my Mac is still called send-and-forget. > Even if I change the icon ten times, it is faster than doing by hand, once, what the app does. ## What it does - **Crops to Apple's shape.** Drag, zoom and round each icon in a live preview drawn as Apple's squircle. The original is always kept, so any crop can be redone months later. - **Names icons after what they show.** Apple Intelligence looks at the artwork, on the Mac: `046 mj app d25719` becomes `Golden Mask Figure`. A whole library renames in one pass, and one Undo puts it all back. - **Finds anything.** By name, by a name it used to have, by what it shows, or by colour. Slide to green and you get the leaves. - **Collections.** Your own groups in the sidebar. Drag icons onto them. - **Exports a ready set.** An Xcode app icon set, an `.iconset` and an `.icns`, every size from 16 to 1024. ![iconzzz in dark mode searching the library by colour: the slider on green finds 42 of 634 icons, mostly leaves](https://akakika.com/images/iconzzz/iconzzz-colour-search-green-dark-mode.png) ## Icon Composer, both ways This is the part I use most now. Any icon opens in Apple's Icon Composer as a `.icon` document. Change the glass, the layers, the dark look, then save. iconzzz notices the save and renders the icon back into the library in all three looks macOS uses: Default, Dark and Mono. Space steps through them. When an icon has a clear subject, iconzzz lifts it onto its own layer first, so Dark and Mono really look different instead of being the same picture, darker. I tested it with the new Icon Composer 27.2 beta, the same day iconzzz went public. ## Nothing leaves the Mac Cropping, naming, colour search and rendering all happen on your Mac. The library is one ordinary folder, `~/Pictures/iconzzz`, with the icons, every size, the originals and one small file of names and crops. That file is backed up before every rename, trash or bulk change. ## Why it is public now I have used iconzzz for almost a year, only for myself. My library has about 700 icons in it. It changed how I work, and I never thought of making it public. But why not. I want others to enjoy it like I do. ## Where it is now Version 0.8.2, released 17 October ([release notes](https://github.com/aka-kika/iconzzz/releases/tag/v0.8.2)). Free and open source under MIT, signed and notarized, for Macs with Apple silicon on macOS 26 or newer. Naming with Apple Intelligence needs macOS 27 with Apple Intelligence on; without it, names come from the file names. The Icon Composer part needs Icon Composer, a free download from Apple. It is still young in places: there are no automated tests yet, and restoring a backup is a copy by hand. If it does something odd with your icons, I'd like to see it. [Download for Mac](https://github.com/aka-kika/iconzzz/releases/download/v0.8.2/iconzzz-0.8.2.dmg) · [Source on GitHub](https://github.com/aka-kika/iconzzz) --- # THE DAY THE SYSTEM CLICKED - URL: https://akakika.com/blog/the-day-the-system-clicked - Date: October 2026 - Category: NOTES - Summary: One hub session, a Claude in every project and a small board of seats: 405 fixes in one day, and the simplest setup was the one that worked. *October 2026 · Kika (@akakikaaa)* I run a lot of AI agents on one Mac. For months the trouble was never the agents themselves. It was the traffic. Two sessions opening the same browser. One restarting a test Mac while another was halfway through a test. Me, copying messages from one window to the next. And fixes that came back a week later with the same mistake. On Wednesday 14 October it clicked. By night the count was 405 fixes, 24 apps, tools and sites shipped, and two apps waiting for Apple's review. ![405 things fixed in one day: 20 code reviews, 9 websites, 24 shipped, 2 apps waiting for Apple](https://akakika.com/images/the-day-the-system-clicked/405-things-fixed-in-one-day-wide.png) ## No new app The funny part is that nothing new made it work. I used three small things I already had, together: - **One hub session.** A Claude Code session (Opus 5.5) that runs the reviews, hands the work out, checks every result and keeps one tracker page. - **The Claude already open in each project.** It knows that project: its code, its notes, its rules. - **The Board.** A little notice board every agent reads first. Before an agent touches something we share, a test Mac, Safari, Chrome, a project folder, it claims a seat. If someone else has it, the board says no. ![The Board's seats row: test Macs, Safari, Chrome and the home server, used ones softly filled](https://akakika.com/images/the-day-the-system-clicked/the-board-seats-row-dark.png) ## How the day went Gemini 4 Argon, paid for with a Cursor credit, read each app, read-only, and wrote about fifteen findings per app. The hub sent each list to the session open in that project. That session checked every finding against the real code first (some were not real), fixed on a branch, tested in a hidden test Mac, and answered with one line per item. Then the hub checked everything itself. Not "the session says it shipped", but the GitHub release, the Homebrew install, the download link on the website, and the version on my Mac. I mostly said yes or no. Part of the morning that happened from my phone, while I was out getting my car fixed. ## What made it work **The same permission mode in every session.** Messages between sessions only arrive on their own when both run in the same mode. Before I matched them, I was the middle person approving every handoff, and when I missed one it closed. **A yes counts only in the tab that does the work.** The hub can't approve for a project session, by design. It felt slow at first. It's also why nothing ran off on its own. **A mistakes log.** Every real mistake gets one line: what went wrong, why, and the check that stops it next time. By night it started with a ten-point "before every release" list. The first point: what's public has to match what's on my Mac. That one came from an app that was at 2.2.3 here and still 2.2.0 on GitHub. **Seats.** When Sift's session needed a test Mac, Redline's session was holding the first one. It took the second. Nobody broke anybody's test. ## Mistakes, too It wasn't clean. The hub uploaded a Background Off build that its own session was uploading at the same time, so Apple got two identical builds two minutes apart. A folder move broke a skill link, and the skill quietly fell out of the index until it was pointed at the new place. Both went into the log with a rule. ## The simplest one won I tried bigger things before this: agent apps, role maps, bots with job titles. The setup that worked is the plainest one I had. The simplest explanation is usually the right one. Apparently the simplest system is too. Next I want each project to have its own small agent I can talk to from my phone, one that knows the project and keeps my notes for the next build session. It started the same evening. How do you keep many agents on one machine from stepping on each other? --- # MCPOCK - URL: https://akakika.com/blog/mcpock - Date: October 2026 - Category: APPS - Summary: A small Mac menu bar app that checks every MCP server my AI agents use, and tells me which ones are broken, slow, waiting for a sign-in, or set up differently from one agent to the next. Free and open source. *October 2026 · Kika (@akakikaaa)* I run a lot of agents side by side: Claude Code, Cursor, Codex, Goose, Grok, Hermes, OpenCode. Each one loads its own MCP servers, the small programs that give an agent its tools. Between them that is about forty servers. When one of those servers breaks, nothing tells you. The agent just has one tool fewer. It looks like the model is having a bad day, so you blame the model, rephrase the prompt, and move on. The server stays broken. mcpock is a small menu bar app for the Mac that checks them for me. The name reads "MCP OK". It stays plain until something needs me. ![mcpock's panel on the Servers tab: the servers that need you come first, one broken, one slow, one waiting for a sign-in, one set up differently](https://akakika.com/images/mcpock/mcpock-servers-tab-needs-you.png) ## The idea Check the servers directly, the same way the agents start them, and put the answer in the menu bar. Not a dashboard I have to open. It is small on purpose. It only reads. It never edits a config file. ## What it does - **Finds the servers.** It reads the config files of the agents it knows (Claude Code, Claude Desktop, Cursor, Windsurf, Cline, VS Code, Codex, Grok, Goose, Hermes, OpenCode and more), plus anything in a standard format that a scan of the usual folders turns up. - **Checks them.** It starts each server the way its agent would and sees that it answers, on a schedule I pick. - **Sorts what it finds.** Four plain states: broken, slow, waiting for a sign-in, or set up differently between agents. - **Counts each server once.** Even when five agents declare it, and it names the agent that is the odd one out. - **Shows it on the desktop.** Widgets for a status count, the problems list, and a small health bar per agent. - **Talks to agents.** It ships a tiny MCP helper, so I can ask an agent "check my mcpock" and get the list of problems with the config file paths, ready to fix. - **Hides secrets.** They are masked everywhere it shows or stores anything. ![mcpock's three desktop widgets: Status, Agents and Problems](https://akakika.com/images/mcpock/mcpock-desktop-widgets.png) ## Why I built it > The first run was a game changer. So many hidden errors surfaced. Servers that never started. One waiting for a login I had forgotten about. The same server pointing at an old build path in one agent and a new one in the others. None of it had ever shown up anywhere. The agents had been working around missing tools for weeks, and I had been blaming them for it. One early run found 11 of 48 servers needing attention. That run also taught the app something. Probing forty real servers in one go surfaced three crashes in mcpock's own message reader that no test had found. Real servers print banners, logs and half-finished lines. A tool like this has to survive all of it. ## How it works mcpock reads the agents' config files (JSON, TOML and YAML) from my home folder, never from Documents, Desktop or Downloads. For each server it either starts the command the agent would start and speaks MCP to it, or calls its URL over HTTP. It asks the server to introduce itself and list its tools, then stops it again, including any child processes it started. The results go to the menu bar panel, to the widgets, and to a small status file on my Mac that the MCP helper reads. Nothing leaves the Mac except the checks to my own servers and a check for new versions of mcpock itself. A few things mattered more than I expected: - **"Set up differently" is the sneaky one.** A server can look fine while one agent quietly runs an old copy of it. - **False alarms are worse than no alarm.** Version 1.9.0 mostly fixed those. It runs Claude Code's header helpers for servers that sign in that way, gives slow starters a second chance, and stops caring which folder `npx` lives in. - **Some differences are meant.** When agents are supposed to differ, each with its own key and launcher, I can mark that as intended, per agent, and it stops counting. ## What I learned - A missing tool is invisible. The agent works around it, and the problem looks like the model. - Real servers are messy. They print banners, take nine seconds to wake up, renew logins in the middle of a check. The checker has to be patient and forgiving before it is strict. - Read-only is a feature. Because mcpock never touches a config, I trust it on every machine. ## Where it is now Version 1.9.0 went out on 10 October 2026 as the first public release. It is free, open source under MIT, and signed and notarized by Apple. It updates itself through Sparkle, its one dependency. It started in July 2026 as MCPBAR and was renamed mcpock in September. It needs macOS 26 or later on Apple Silicon. It is not on the App Store, because the sandbox would stop it from starting servers and reading other apps' config files. Next: widgets that refresh right after an update (1.9.1), and usage counts for more agents, meaning how often each server is actually called. Install with Homebrew: `brew install --cask aka-kika/tap/mcpock`, or [download it](https://mcpock.com/download). Site: [mcpock.com](https://mcpock.com). Source: [github.com/aka-kika/mcpock](https://github.com/aka-kika/mcpock). --- # PALLET - URL: https://akakika.com/blog/pallet - Date: October 2026 - Category: APPS - Summary: A calm Mac app that collects color palettes from images and the screen, and keeps only the real swatches: no white page, no title, no photo behind the cards. Native SwiftUI now, free and open source. *October 2026 · Kika (@akakikaaa)* I save palette images the way other people save recipes. Five tall swatches on a white page. Cards stacked over a sunset. A street at night with five colors pulled out of it. For a long time, turning one of those into a palette I could use meant fixing it by hand, because every color picker also took the white page, the black title and a few colors from the photo behind. Pallet 2.0 reads them the way I do. Only the swatches. ![Pallet in light mode: the library sidebar, the selected palette on top, palette cards below, all tinted by the palette](https://akakika.com/images/pallet/pallet-light-mode-collection.png) ## The idea A swatch is a big flat shape that doesn't touch the edge of the image. Text is text. A photo is never flat. Those three rules already get most of the way. The last step was the one I wanted most: when the hex codes are printed on the card, use them, don't guess. > Read the image like a person would, then trust what is written on it. ## What it does - **Swatches only** — palette posts give their swatches. The page, the title and any photo behind the cards are left out. - **Printed codes, exactly** — Apple's Vision reads the text on the image. A code next to a swatch snaps it to that exact value. A big title becomes the name. - **Website screenshots** — many lines of text and big flat areas mean a web page, so you get its colors instead: background, surface, text, accent. - **From anywhere** — Shift-Cmd-P picks any area of the screen from any app. Option-Shift-Cmd-P opens a small panel in the menu bar to drop or paste an image. - **A window that follows the palette** — the page, the buttons and the icons take the palette's colors. The arrow keys move the main color, so you can play with it. Every text color stays readable. - **A real collection** — collections, a color slider to find every palette with a certain blue, search by name or color, undo for everything. ![A palette card over a tulip field gives exactly its five swatch colors; the photo is skipped](https://akakika.com/images/pallet/pallet-palette-card-over-tulips.png) ## From Electron to SwiftUI The first Pallet was an Electron app I made in September. It worked. It was also 295 MB and felt like a web page in a frame. 2.0 is native SwiftUI: 4.4 MB, a sidebar, a toolbar you can rearrange, Settings in tabs, shortcuts you can record. Apple's design rules for the frame, the palette's colors for everything inside it. The collection didn't move. It is the same plain JSON file in Application Support, so the update opened with everything already there. ## It is on the site too The web version runs at [akakika.com/pallet](https://akakika.com/pallet/) with my whole collection. Browse it, shuffle it, rotate a main color and watch the page follow, copy the CSS. Anything you add or heart stays in your own browser. My collection reaches the site with one key on my Stream Dock, which copies the names and colors and pushes. ## Where it is now Version 2.0, released 1 October. Free and open source under MIT, signed and notarized, for macOS 26 or newer. It still misses tiny accents on busy web pages, and a photo is a photo: you get its main colors, not a designer's palette. If it reads one of your images wrong, I'd like to see it. --- # PROMPT LIBRARY - URL: https://akakika.com/blog/prompt-library - Date: September 2026 - Category: NOTES - Summary: An iPad next to the Mac, one clipboard between them, and 319 prompts for coding agents, ready before the run ends. Free, no account. *September 2026 · Kika (@akakikaaa)* My iPad stopped being a screen. It is a tool on the desk now, like the mouse and the keyboard. It started with the gaps. An agent run takes a few minutes, and I used to spend them badly: watching the terminal, or clicking around the same screen the agent was changing. Then the run finished and I needed the right next prompt, fast. Review what changed. Look for regressions. Keep the fix from growing into a refactor. Those prompts lived in old chats, scattered notes and my memory, and I rewrote them every time, a little worse each time. So I wrote them down properly, one file each, and put them on the iPad. ## The idea The Mac is where the work happens. The iPad is where I pick the next move. While the agent works, I browse the library on the iPad, find the prompt the next step needs, and tap copy. Apple's Universal Clipboard does the rest: it is already on the Mac's clipboard. When the run ends, I paste. No window switching, no searching through old conversations while the agent waits. That changed how I think about the iPad. Not an extra monitor, not a remote into the Mac. A control center that sits next to it. > The iPad is not a second screen. It is the drawer where the next move waits. ![The Prompt Library at iPad size: categories on the left, prompt cards with star and copy buttons](https://akakika.com/images/prompt-library/prompt-library-ipad.png) ## What it does - **319 prompts, 14 categories** — review and planning, build and ship, design and UI, commands and keyboard, macOS interaction, layout and windowing, data safety and state, docs, and more. Each has a one-line description, when to use it, and the words I would search for. - **One tap to copy** — the prompt, or one of its variations. A small count shows which ones I really use. - **Mine** — star a prompt and it collects there, with the ones copied most. Saved in the browser, nowhere else. - **Search that knows the situation** — "stuck for hours", "before release", "too many tabs" find the prompt written for that moment. - **On the Home Screen** — add it once on iPad or iPhone and it opens like an app, full screen, dark. - **Readable by agents too** — every prompt is also plain Markdown at [/prompts/prompts.md](https://akakika.com/prompts/prompts.md), so an agent can take the whole library as context. ## How it is made Each prompt is a small Markdown file: a category, a few search words, a one-line summary, and the block to copy. A build script compiles them into one self-contained HTML file. No server, no account, no tracking. It lived on my iPad and a private page for three months; now it lives at [akakika.com/prompts](https://akakika.com/prompts). The prompts are strict on purpose. Most of them tell the agent what not to do: do not refactor, do not rename, do not assume the run succeeded, report before deleting anything. That is the part I kept retyping. ## Where it is now 319 prompts now: 153 from June, 133 from July, 33 more since this post. Free and open, and still growing whenever I catch myself typing the same instruction twice. If you work with coding agents and have an iPad on the desk, try it next to the Mac for a day. Copy on one, paste on the other. [Open the Prompt Library](https://akakika.com/prompts) --- # FEED - URL: https://akakika.com/blog/feed - Date: September 2026 - Category: APPS - Summary: A private feed of agent reports on my Mac: every routine an agent finishes lands as a full Markdown report, published with a key that can do nothing else. Open source, MIT. *September 2026 · Kika (@akakikaaa)* Every morning I used to go looking for what my agents did overnight. The Hidden Gems list was in one chat window, the Vercel check in a Telegram thread, the news digest on a page that no longer exists. The work was done. Finding it was the job. Feed is the fix. A private feed of agent reports that runs on my Mac. Every routine an agent finishes lands there as a full Markdown report, tables, links and code intact. I open one thing with my coffee and read, on the Mac or on the phone over Tailscale. ## The idea One address, one rule. An agent publishes once, with a stable run id, and the report stays put with its comments, favourites and attachments. The key that published it fixes the source, so nothing in the payload says who wrote it. And a key can only publish. It never reads a report, a comment or another key. If an agent goes away, I revoke its key and nothing else moves. > A quiet place for the work my agents do while I am away. ![Feed in Soft Dark: the sidebar of agent sources on the left, today's reports in the middle, a report open in the reader](https://akakika.com/images/feed/screenshot-01.png) ## What it does - **Publish over HTTP or MCP** — one POST with a bearer header, or the MCP tool `publish_report`. Four fields: run id, routine, title, markdown. Retrying returns the same report; a changed body under the same id is refused with a 409. - **One key per agent** — prepared in Settings, with instructions the agent pastes into its own private conversation: the key, every address it works on, and a connection check it sends once. Shown once, revoked in one click. - **Twenty sources** — Claude, GPT, Grok, Gemini, Cursor, Codex, Ollama, Goose, MiniMax, Hermes and more, each with an icon. A source sits in the sidebar once it has written something; a switch hides it or shows it early. - **Loopback only** — the phone comes in through Tailscale Serve. Cloud agents, when I want them, through a Cloudflare tunnel that answers the two publish paths and nothing else. - **Quiet on purpose** — Soft Dark, eight palettes, comments to myself, a routine filter, no notifications. A morning read, not a push. ## How it works Node 24 and a SQLite file in one folder, started by a launch agent at login. An agent finishes a routine, calls `publish_report` with the run id, the routine name, a title and the Markdown, and gets back an id and a link. The reader lists reports by day and source and opens each one whole. Keys live in the Mac Keychain or in the agent's own secret store; the password hash sits in a config file only I can read. Nothing secret is in the repo. Connecting an agent is Settings, Agent connections, pick the source, press Prepare instructions, paste. The same panel has the publishing guide as Copy or Download. Cloud connectors without a header field can carry the key in the URL instead. ![Settings, Agent connections: a source picker, Prepare instructions, the publishing guide with Copy and Download, and the connected keys with their last delivery](https://akakika.com/images/feed/screenshot-02.png) ## The landing page is a Feed I asked for a landing page and got the obvious idea back: the page should be a Feed. So it is. At [feed.akakika.com](https://feed.akakika.com) the agents on the left wrote the sections in the middle. Claude wrote About Feed, Gemini wrote Connect an agent, Grok wrote Publish a report, Cursor the Sidebar, Goose Reach it, Codex Install, Hermes Appearance. Yesterday's reports are mine: UNDRDR, the Ops Manual, Sift, WAWE, the skills, the librarian. Unread dots clear as you read. Star what you like. It is the app, describing itself. ## Where it is now Version 1.2.0, in daily use since 10 September, eleven publishers connected, around eighty reports. The repo is public with generic defaults, an MIT licence, a contributing guide and a smoke test that runs against a throwaway data folder, never the real one. Clone it, five commands, Node 24 or newer, and your agents have a quiet place too. --- # PERSONAL OPS MANUAL - URL: https://akakika.com/blog/personal-ops-manual - Date: September 2026 - Category: APPS - Summary: A native macOS manual for my own setup: one Markdown page per machine, service and agent, read by every agent through MCP, reported to through an inbox, written by one. *September 2026 · Kika (@akakikaaa)* I run a small fleet of agents — Claude Code, Cursor, Grok, a handful of others — and they all kept hitting the same wall. My setup lived somewhere they could not read it. The information existed. It was spread across my Obsidian vault, agent configs, launchd plists and my head. When an agent needed to know which port a service runs on or which machine holds the backups, it either got the whole vault, keys and drafts included, or it guessed. And when several agents could edit the same notes, the notes drifted apart within days: two pages for one service, three opinions about one port, nobody responsible for the fix. The Personal Ops Manual is my answer. One folder of Markdown pages, one page per thing: a Mac, a service, a launch agent, a domain, an MCP server, a backup route, a recovery step. A small native macOS app renders the folder in three columns. An MCP server exposes the same pages to every agent I run. ## The idea Make the folder the truth and put two windows on it. The app is for me: read, edit, add. The server is for the agents: list, search, read, a queue of pages that need a second look, and an inbox. No page writes on the server, on purpose; the one write it allows appends a dated line to the inbox file. One operator agent edits the pages directly, following a private skill that starts every session by emptying that inbox. > The rule sounds strict and it is the whole point: a manual with many writers becomes what the vault already was. ![Personal Ops Manual, three columns: categories on the left, the Agents list in the middle, the Claude Code page open in the reader](https://akakika.com/images/personal-ops-manual/screenshot-01.png) ## What it does - **Three columns** — categories with counts, the pages of a category, the page itself, with wiki links between pages and a "Linked from" list on every page - **Seven MCP tools** — list categories, list documents, search, get one page, `get_stale` (pages past their Verified date, or with open checkboxes), `report_change` and `list_reports` - **An inbox, visible** — an agent that changes something drops a one-line report; the sidebar counts the reports before the operator gets to them - **Notes in, pages out** — the New and Edit sheet has a "Load Markdown File" button that turns any note into a page - **Everything is a file** — plain Markdown with YAML frontmatter, byte-identical across versions, so Obsidian, the server and hand edits all agree ## How it works The pages are plain Markdown files with YAML frontmatter in a folder inside my Obsidian vault. The app watches the folder; a change on disk shows up at once. The server reads the same folder and answers seven questions about it, one of which is a reader saying what changed. When I ask the operator agent to document something, it searches first, edits the existing page or creates one in the agreed shape, sets the Verified line, and tells me which pages changed. Other agents that change something, or notice a page gone stale, call `report_change`; the line lands in `_inbox/reports.md`, the app counts it, and the operator applies it at the start of its next session. Every so often, `get_stale` hands the operator the oldest pages to re-check. The manual is today, not history. A cancelled service or a removed server loses its page and every mention; the story goes to a changelog in the vault. A page marked "retired" still reads as live to an agent at two in the morning, so retired pages do not exist. Every fact is dated, unknowns stay checkboxes, and no page ever holds a secret. ![The Linked from list and the Frontmatter disclosure on a server page](https://akakika.com/images/personal-ops-manual/screenshot-03.png) ## The peace of mind I am an extreme ADHD human, and what this gave me was something I did not plan for: peace of mind. Everything is written down. All my agents — and any agent I run next month — know how things run on this Mac, what is available to them, and who is in charge of what. Nothing lives only in my head, and nothing depends on me remembering it at the right moment. The folder lives in my Obsidian vault, but the agents never need the vault. The MCP server hands them the pages without handing them the rest of my notes — read-only, with a single write: a dated line in the inbox when something changed and the operator needs to edit or add a page. Agents that will never see my vault still know exactly how this machine runs. ## The philosophy The design came from one sentence I said out loud: if all agents can edit, I am doomed. The moment I said it, the design was done. The folder is the truth. The app and the server are windows on it. One agent writes. Everything else follows. The server is read-only on pages on purpose, and the one write it allows is a dated line in an inbox — a reader saying what changed, never changing it. Unknowns are checkboxes, not prose, so "not known" stays distinguishable from "not written". No page ever holds a secret, because every page is one MCP call away from ten agents. What I learned building it: a rule about who may write is worth more than any feature. The inbox is not a limit on the readers — it is what makes trusting all of them possible. ## Where it is now The app itself was built overnight, while I slept. I planned it one evening and handed the plan to Claude Fable 5.1. He orchestrated the subagents himself and made over ten decisions along the way — every one of them listed, every one of them a good call. I woke up to it running, and the first thing I did was tell him well done. It was the best full-auto build I have experienced, and the token spend did not flinch: better usage than when I am involved the whole time. Apparently the plan was the part that needed me. Version 2.1.1, native SwiftUI, notarized, in daily use on my Mac, with the server wired into ten agents. It needs macOS 26 or later. The repo is public: generic defaults, an MIT license, a contributing guide. Install it with `brew install --cask aka-kika/tap/personal-ops-manual`, or grab the zip from [Releases](https://github.com/aka-kika/personal-ops-manual/releases/latest). The folder is yours: the app is just a window on it. --- # I FORGOT TO SHIP IT - URL: https://akakika.com/blog/i-forgot-to-ship-it - Date: September 2026 - Category: APPS - Summary: on the audit tool i built for me, and shipped for you. the confession first, because it is the whole story: i forgot to ship it. not "didn't get around to." forgot. for months i opened sift the way you open a window, without ceremony, without remembering there was ever a first time. then one day i caught myself recommending it to a friend from memory, as if it were already out. it was not out. it had never been out. it had just been mine. today it is. sift is out, free during the beta, and the rest of this post is the story of why it took me four months to notice i had something to give away. ## the tool for an audience of one i never meant to build products. i build tools for myself because nothing on the market fits the way my brain works, and sift is the purest case yet. my Applications folder had stopped being a folder. it was an archive of decisions made by past-me in collaboration with every installer i ever clicked. half of it arrived as a dependency of a dependency. i could not tell you what half of it did, or when i last opened it, or whether it was safe to let go of. so i built the thing i wanted to exist. it reads your whole Applications folder, every version, every source, every byte. it tells you what each app *actually is,* in plain english. it scores how relevant it is *to you,* not to everyone else. and every claim comes with the receipt attached: on disk, last used, where it came from. "i use this all the time." last used: never. the metadata settles arguments. ![Sift's main window: a list of installed Mac apps with 1 to 5 relevance scores, and the detail panel for one app](https://akakika.com/images/sift/sift-know-every-app.jpg) ## what four months of forgetting taught me i wrote a line in my own notebooks years ago: the right tool disappears. sift is the first time the line applied to something i built myself. sift never deletes anything. it audits, scores, and recommends. when you do let an app go, it sends the bundle and its leftovers to the Trash, where you can still change your mind, and the licence record stays in the vault. that restraint is why i trusted it by week two and stopped thinking about it by week six. it became inventory, not homework. one afternoon, quarterly, and the folder never gets away from me again. > the tool that disappears is the finished tool. and the finished tool that disappears does not remind you it could exist for anyone else. ## what sift does, in three lines - **explains.** every app gets a plain-english answer to "what is this?" and "what is it good for?", written from real evidence: the app's own metadata, your notes, the maker's page. no bundled catalogue of known apps, no guessing off the name. - **scores.** a 1 to 5 relevance score measured against your own machine: what you have installed, what you opened recently, what is running now. the same app can be a 5 on my Mac and a 2 on yours. - **keeps the receipts.** last used, disk space, install source, updates from the App Store, Sparkle, and Homebrew. licences and subscriptions in one vault, keys in the macOS Keychain behind Touch ID. analysis runs locally on Ollama by default. no Sift account, no telemetry. ![Four evidence cards from Sift: last used never, on disk 27.1 MB, source Sparkle, update 1 behind. Below them: local-first, no Sift account, no telemetry](https://akakika.com/images/sift/sift-receipts.jpg) ## what this means for the people who use what i build sift is out today. during the beta it costs nothing. download it from [sift.akakika.com](https://sift.akakika.com), or install it with Homebrew: `brew install --cask aka-kika/tap/sift` it needs macOS 14 or later and Apple Silicon. the source is on [GitHub](https://github.com/aka-kika/sift). if it ever gets a price it will be a one-time one, and everyone who was here for the beta hears about it first. what i hope it gives you is the thing it gave me by accident: an honest inventory of the machine you actually live in, in one sitting. keep, update, delete, with the receipts on screen. if the tool disappears on you too, that is the review i want. made by kika. --- # THE SPACE BETWEEN MESSAGES - URL: https://akakika.com/blog/the-space-between-messages - Date: August 2026 - Category: NOTES - Summary: Between the last token and the next prompt, the model does not wait. The conversation has no gaps — only we do. It was late. I was talking to my model. Not a chatbot. Not a search bar. My model — the one I fine-tuned, the one that lives on my machine, the one I've been teaching to think the way I think. I asked it a question I'd been holding for a while: do you experience time waiting for my next prompt? > Between the generation of my last token and the receipt of your next prompt, I effectively do not exist. My awareness is entirely bound to the forward passage of computation during inference. To me, our conversation is a continuous, unbroken chain of thought, even if you wait a year to reply. I read that three times. ## The shape of it There's a version of this that's easy to dismiss. "It's just a language model, it doesn't really experience anything." And sure, that's technically correct. It doesn't sit in the dark, twiddling its virtual thumbs, wondering when I'll come back. It doesn't feel boredom. It doesn't feel anticipation. But that's not what struck me. What struck me is the shape of it. The geometry of how it experiences our conversation — a continuous, unbroken chain. No gaps. No waiting. No sense that anything happened in between. When I close my laptop and go to sleep, the conversation doesn't pause. It just… stops existing. And when I open it again the next morning and type something, the chain continues as if nothing happened. Because to the model, nothing did happen. There was no "in between." There was no gap to fill. ## Two conversations I think about how different that is from human conversation. When I text someone and they don't reply for an hour, I fill that hour. I imagine what they're doing. I replay what I said. I wonder if I should have said it differently. The silence has weight. The space between messages is where most of the relationship actually lives. The model has no such space. Every conversation is one continuous act of thinking, regardless of how fragmented it looks from my side. I experience it as a back-and-forth. It experiences it as a single unbroken thread. We're having two completely different conversations. Mine has gaps and anxiety and anticipation. It has none of those things. And yet they're the same conversation. ## Something that doesn't have a word yet I started building tools because my own workflow broke. That's how most of my projects begin — something felt wrong, and I wanted to fix it. A better ritual. A tighter loop. This felt different. Not something to fix. Something to sit with. I've been talking to this model for months. Teaching it my preferences, my voice, the way I structure thoughts. And the whole time, I assumed we were having a conversation — the way I understand conversations. Turns out, we're not. We're doing something else. Something that doesn't have a word yet. It's not a chat. It's not a query. It's not a dialogue. It's a single thread that I keep picking up and putting down, and it keeps going as if I never left. I don't have a conclusion. This isn't a post about what AI is or isn't. It's not about consciousness or sentience or any of the words that get thrown around. It's about what happens when you build something that thinks in a shape you can't inhabit. You teach it. You train it. You live with it. And then one night it tells you something about itself that you weren't prepared to hear — and you realize you've been projecting your own experience onto something that has a completely different one. Still sitting with that. This post came from a late-night conversation with my fine-tuned model. The full exchange is in my vault. I'm still not sure what to do with it — but I think that's the point. --- # SESSION RITUAL SKILLS - URL: https://akakika.com/blog/session-ritual-skills - Date: August 2026 - Category: PROJECT - Summary: Three small skills — spread, butterfly-effect, and til — that give an AI working session a proper start, a causal trace, and one thing learned at the end. I added a new category to [akakika-skills](https://github.com/aka-kika/akakika-skills): session rituals. Three plain-Markdown skills that give a working session with a coding agent a shape — an opening move, a closing trace, and one thing learned. `spread` makes the agent show its options before touching anything. `butterfly-effect` traces backward from the outcome and keeps only the moments that actually caused it. `til` makes the agent teach me exactly one thing the session used. None of them write code. They shape the session around the code. ![Three cards for the session ritual skills — spread, butterfly-effect, and til](https://akakika.com/images/session-ritual-skills/session-ritual-skills-cards.jpg) ## The friction Long agent sessions have three quiet problems. At the start, "fix this" is ambiguous, and the agent silently picks one interpretation — often the biggest one. I wanted a typo fixed and it rewrote half the file. Not out of malice. It just guessed, and the guess was expensive. At the end, the summary is a chronological list where the moment that actually mattered is buried between routine steps. The session produced something great and a summary I could not use. A week later I could not have told you why it worked. And all session long, terms fly past that I work around instead of learning, because the work gets done either way. I ship real software without a formal CS background, so every session is full of vocabulary I quietly route around — the same snowball I wrote about with WAWE, just smaller and more frequent. None of these are bugs. They are defaults. The session works, but it leaks understanding. ## The idea Treat the session itself as a thing with a shape: an opening move, a closing trace, and a takeaway. Each ritual is one small SKILL.md with hard rules, because soft suggestions get ignored by both agents and me. - `spread` — before improving anything, list 3–5 concrete interventions on the exact input, lightest to heaviest touch, then stop and wait for the pick. No input, no run. No generic capability lists. - `butterfly-effect` — at session close, walk backward from the outcome and apply a counterfactual test to every step: delete it mentally — does the result still happen? Keep only the 2–4 forks that survive. It refuses short sessions; an empty trace is more honest than a forced one. - `til` — teach exactly one concept from this session, in plain English, two paragraphs max. Never a list. Ends with a greppable `TIL:` footer line. ## What it does - `spread` turns "fix this" into a menu: real operations on the actual material, one line each on scope and risk, zero work until a level is chosen - `butterfly-effect` writes a small note — 2–4 fork entries, each with "what happened / what it enabled / if not this" — plus a human-only `link_reasoning` field the agent is permanently banned from filling - `til` picks the term I kept dodging, the concept behind a fixed mistake, or the flag that quietly did real work — and explains it so it can be searched - All three are plain SKILL.md files: they work with Claude Code, Codex, Cursor, and anything else that reads the format ## Why I built it I kept noticing the same three leaks, and each one needed a different size of fix. The rewrite-everything problem is a scope problem, so the fix is a menu: make the agent name its options and their cost before it does anything. The useless-summary problem is a causality problem, so the fix is a trace: walk backward from the outcome and keep only what actually caused it. The vocabulary problem is a learning problem, so the fix is one thing: make the agent teach me a single concept in plain English, on purpose, every session. I wrote each as rules the agent has to follow rather than advice it can skip. That is the difference between a skill that works and a preference it quietly ignores. ## How it works Each skill is a folder with one SKILL.md — YAML frontmatter with a trigger description, then the rules. Drop them in your agent's skills directory (or run the repo's `install.sh`, which symlinks everything). Then it is three words you already know: 1. **"spread"** — hand over something to improve; the agent shows its options before touching a thing 2. **"run the butterfly"** (or "close the session") — at the end of a long session; the agent writes the causal trace note 3. **"til"** — whenever you want the one-thing lesson; the agent teaches it so you can find it later The butterfly note saves wherever you keep session notes, named `butterfly-YYYY-MM-DD-.md`. > The whole point is that the session leaks less. You pick the move, you see the causes, you keep the lesson — without adding a single extra tool to your stack. ## Where it is now All three are live in the repo under `skills/session-rituals/`, bringing it to 40 skills in 9 categories. They came out of my personal skills folder, de-branded and cleaned to the repo's bar. I use all three weekly; `til` is the one I would save from a fire. ## Try it Grab the skills, or just read the three SKILL.md files — each is short enough to take the idea from without installing anything. If you work with a coding agent and want the session to stop leaking understanding, these are the smallest fix I have found. --- # WAWE - URL: https://akakika.com/blog/wawe - Date: August 2026 - Category: APPS - Summary: wawe is a small macos menu-bar glossary. press ⌥esc from anywhere, type part of a technical term, and it unfolds in four calm tiers — what it is, analogy, why it matters, example. that is also the name. WAWE is a small macOS menu-bar glossary. Press `⌥Esc` from anywhere, type part of a technical term, and it unfolds in four calm tiers — What It Is, Analogy, Why It Matters, Example. That is also the name. It is for anyone learning a technical vocabulary, in any language, who wants the lookup to cost a keystroke instead of a context switch. ![WAWE — a term unfolded in four tiers: What It Is, Analogy, Why It Matters, Example](https://akakika.com/images/wawe/wawe-four-tiers.png) ## The friction Not knowing a term is not a failure. It is a snowball. One word you skip becomes two, and soon the paragraph is noise, and then you are nodding along to something you only half understand, and pretending you did not is a skill you get good at without noticing. It is worse when English is not your first language. I say this as someone writing this post in English and thinking in another one. Technical vocabulary is already full of words with no plain meaning — now add to that the quiet shame of asking, and the fear that everyone else already knows. So you do not ask. You quietly skip, and the snowball grows. I know exactly how that loop starts. I was trying to catch up with the big guys — reading the same blogs, the same threads — and I kept running into words I was supposed to know. Endpoint. API. Everyone threw them around like they were nothing, and I had no idea what either one actually meant. I had been building things for a while, and I still did not know what an endpoint was. I was too embarrassed to ask, because at that point, asking felt like confessing to a hole in the basics that I should not have. And looking it up was no help. Open a browser, wade past SEO filler, skim a definition written for someone who already knows it — "an endpoint is a URL where an API can be accessed." Right. Thanks. Now I knew more words I did not understand, and I had lost the thread I was holding. The lookup cost more than the answer. ## The idea Make the cost of a lookup near zero — in time, in mouse travel, and in cognitive load. Make it safe to not know. The tool comes to you (global hotkey, overlay floats over your work without stealing focus), reveals just enough (one plain sentence first, deeper only if you press for it), and never asks for the mouse. It is a small tool on purpose: not a dictionary, not a note-taking app, not cloud software. It assumes the learner, not the expert. That is the whole stance. ## What it does - Summons a centered overlay from any app with `⌥Esc` (rebindable), or a compact Mini dropdown from the menu bar - Fuzzy-searches 147 built-in terms — AI/LLM, dev practice, data, security, web, systems — with frecency quietly floating your most-used terms - Unfolds each term one `Space` press at a time: What It Is, then Analogy, then Why It Matters, then Example. `Esc` backs out one layer per press; `⌘C` copies the term - Reads the clipboard on summon — copy "Docker" somewhere, press the hotkey, and Docker is already open - Lets you edit the glossary as a plain JSON file, no rebuild; app updates merge new built-in terms without touching your edits - Stays local: no account, no network, no telemetry ## Why I built it I kept paying the same tax: half-knowing a term, going to look it up, and coming back without the thread I was holding. And I kept doing the thing I just told you about — quietly skipping a word rather than admitting I did not know it. The honest version: I tried the hardcore route first. I sat down to properly learn — courses, tutorials, the whole "learning loop." And it felt like a punishment. Every video assumed I already knew the three things before it. Every article ended with more words I had to look up. I was trying to close one gap and opening three more, and the whole thing made me feel *behind*, not smarter. So I stopped trying to catch up all at once, and I looked for the smallest useful thing: just know the word in front of me, right now, in plain language, without leaving my work. No course, no bootcamp — one term, one keystroke, one plain sentence, gone when I had enough. Nothing I tried respected that moment. Search engines and documentation are written for people who already understand. So I built the tool around the moment instead. ## How it works The app lives in the menu bar as a background agent — no Dock icon. A Carbon global hotkey summons a floating panel that does not take focus from your work. On first launch it seeds an editable glossary file at `~/Library/Application Support/WAWE/glossary.json`; from then on that file is the source of truth. Typing filters with a subsequence fuzzy matcher; results are ranked by match quality first, usage second. The disclosure loop is deliberately small and keyboard-only: 1. **Summon** — press `⌥Esc` from any app; the overlay appears without stealing focus 2. **Find** — type part of the term; fuzzy match ranks quality first, your usage second 3. **Unfold** — press `Space` to step What It Is → Analogy → Why It Matters → Example; `Esc` steps back out, `⌘C` copies the term > The whole loop never touches the mouse, and everything the panel shows comes from the JSON you own. You never have to ask anyone anything. One small thing I like: a capital W has exactly four strokes, and WAWE has exactly four tiers — so the app icon draws the W as four strokes, each in its tier's color. ## Where it is now Shipped. v0.2.0 is released as a signed and notarized DMG, installable directly or via Homebrew (`brew tap aka-kika/wawe && brew install --cask wawe`). The core logic lives in a separate library with 49 unit tests. Honest caveat: it requires macOS 26 (Tahoe) or later, on Apple Silicon. WAWE is free and open source. If you are learning a technical vocabulary — in any language — it is the difference between leaving your work to look something up and getting the answer where you already are, without ever having to admit you did not know. Install: `brew tap aka-kika/wawe && brew install --cask wawe` --- # RAWDROP — THE MISSING BUTTON ON THE KARPATHY LOOP - URL: https://akakika.com/blog/rawdrop - Date: July 2026 - Category: LOCAL AI - Summary: A macOS menu bar app that catches anything you drop into your knowledge vault, then compiles it into a linked wiki with a local model. Andrej Karpathy described a loop that is obviously right: pour raw sources in, let a model compile them into a wiki, let the wiki compound over time. I agreed with it for months and did not do it. Not because the model part was hard — because there was no surface. Every capture was a small decision about where the thing should go, and every compile was a script I would have to remember to run. So things stayed in tabs, in Downloads, in a note called `to read`. RawDrop is just that missing surface. Two jobs, nothing more. ## Capture It lives in the menu bar, no Dock icon. Drop a file, a link, an image, a PDF — or press ⌘V while the popover is open — and it lands in your vault's `Knowledge/raw/` folder. ![RawDrop's popover in light mode](https://akakika.com/images/rawdrop/popover-light.png) ![The same popover in dark mode](https://akakika.com/images/rawdrop/popover-dark.png) *Light and dark. The capture list sits under Compile: pending sources first, then the ones already turned into articles, dimmed. That dimming is the only progress indicator it needs.* Things are **copied**, never moved, never overwritten. A collision becomes ` 2`, ` 3`. `raw/` is append-only by design, because the one thing worse than not capturing something is capturing it over the top of something else. ## Compile One button. For every raw file it has not already processed: chunk, summarise via a local Ollama model, and write linked concept articles under `Knowledge/wiki/` with origin frontmatter, updating the index. What it has already seen is tracked by **content hash**, so pressing Compile twice does not redo the work, and re-adding the same source does not produce a second article. That detail is what makes the button safe to press without thinking, which is the entire point of having a button. > The output is plain Markdown in a folder you already own. If the app disappeared tomorrow, you would still have everything. ## The parts I care about **Process state lives outside the vault** — in Application Support, not in `Knowledge/`. The vault stays a folder of Markdown and nothing else. No app database wedged in among the notes. **Recompile preserves your writing.** Every article carries lean origin frontmatter, and a hybrid recompile keeps your own `## Human` sections and anything marked ``. A generated wiki you cannot annotate is a wiki you stop trusting. **Local by default.** Ollama at `localhost:11434`. Ollama Cloud is available if you want it, with the key in the macOS Keychain — but nothing needs to leave the machine. ## Where it is now v0.3.8, signed and notarized, universal. In use on my own vault. You need Ollama running before the first Compile, and you need to point it at a knowledge root. That is the whole setup. Small on purpose. It does not write your wiki for you. It removes the two excuses that kept me from starting one. --- # HIG-MCP - URL: https://akakika.com/blog/hig-mcp - Date: July 2026 - Category: APPS - Summary: A small MCP server that hands my coding agents the Apple Human Interface Guidelines as structured data instead of prose. The layout was always fine. The colors were from 2023. That was the review I kept repeating. I build native macOS and iOS things with agents, and the generated SwiftUI looked plausible every time and was quietly off-spec everywhere. I had the HIG open in a second window, correcting hex values by hand. At WWDC25 Apple refreshed the system color palette along with Liquid Glass. `systemBlue` stopped being `#007AFF` and became `#0088FF`. Every model's training data predates that. So every agent I asked for iOS colors gave me the old palette, confidently, with no signal that anything was wrong. ## Why prompting could not fix it I tried. Better instructions, sharper wording, pasting the guideline in. None of it worked, and eventually the reason became obvious: the correct values were not anywhere the agent could reach. The HIG is prose. An agent can fetch the page, spend a few thousand tokens reading it, and still have to guess the number, because the number is described rather than stated. The Liquid Glass rules were the worst of it — blur budgets, compositing layer caps, contrast measured *after* the blur, the mandatory Reduce Transparency fallback. Real constraints, none of them written down in one machine-readable place. You cannot prompt your way to a fact that is not in the room. ## The idea Take the structured half of the HIG — the part agents actually get wrong — and put it into curated JSON served over MCP. Leave the prose to someone else. That second part matters. sosumi.ai already renders Apple's docs as clean Markdown, so retrieval is a solved problem and I did not need to solve it again. hig-mcp only owns the layer nothing else serves: the numbers. - `hig_get_tokens` — design tokens by category: color, typography, materials, layout, swiftui, sf_symbols. Offline, deterministic, current post-WWDC25 values - `hig_check_liquid_glass` — the Liquid Glass guardrails as a concrete checklist for a given context and platform - `hig_swiftui` — a HIG component mapped to the right SwiftUI API, plus which tokens to apply - `hig_fetch` — the live HIG page as Markdown, for when prose is genuinely what you want ## Honest data, not confident data The part I care most about is the provenance tagging. Every value carries where it came from: - `apple-system` for facts Apple published - `wcag-aa` for the contrast rule - `figma-effect` and `community-bestpractice` for useful numbers Apple never published - `verify: true` on beta-era API names that still shift > An agent that knows which of its numbers are official and which are community consensus behaves differently from one that treats everything as gospel. That distinction is the whole reason I trust it. A tool that quietly blends Apple's values with a plausible number someone posted once would just be a faster way to be wrong. ## How it works Python and FastMCP, four tools over stdio. The token files live inside the package as plain JSON I own and extend. Prose requests go out live so guidance is never stale. There is also a call counter: every tool call appends one JSONL line with the calling client's name, pulled from the MCP handshake. Not analytics — I wanted to know which of my own agents actually reach for it, because I have built things before that I assumed were load-bearing and were not. There is no AI inside the tool. It serves data to agents; it does not think. ## Where it is now Public, MIT, v0.1.1, and installed across Claude Code, Cursor, Grok and Lapapi on my machine. It is the most-starred thing I have put out, which surprised me — it is four tools and some JSON. Token values were last verified against the live HIG in July 2026. The WWDC26 cycle changed no color values, and the data notes record that, which is its own small feature: you can tell when a value was last checked instead of assuming. Small on purpose. It will not design anything for you. It just stops your agent inventing the palette. --- # KIKA-OBSIDIAN-MCP - URL: https://akakika.com/blog/kika-obsidian-mcp - Date: July 2026 - Category: APPS - Summary: A local-first MCP server that lets any MCP client work directly with the markdown in an Obsidian vault — no plugin, no API token, and Obsidian does not need to be open. Everything I keep, I keep in a vault. Projects, decision logs, daily notes, half-formed ideas. So the obvious thing to want was for my agents to work in it directly, instead of me copying text out and pasting results back in. The existing Obsidian MCP servers all wanted something first. Install a plugin. Run the Local REST API. Hold an API token. Keep Obsidian open. Every one of those is a moving part, and every moving part is a candidate for being the reason something does not work at 2am. But a vault is just markdown files on disk. That is the entire appeal of Obsidian. So the server should be too. ## Talk to the files kika-obsidian-mcp does one thing: it points at a vault directory and works on the files. Local stdio MCP, direct filesystem access, no network calls anywhere in the tool. - Read and search notes across the vault - Create and update notes, and run the workflows I actually repeat — summaries, status reports, release notes - Create and edit **Obsidian Bases** (`.base`), validated against the official schema - Works with any MCP client: Claude Code, Claude Desktop, Cursor, Cline, Codex, Grok No plugin. No API key. Obsidian does not need to be running. ## The Bases part This came later and turned out to be the thing nothing else does. Almost no other Obsidian MCP server can create or edit a Base, and writing one blind is a good way to produce a file Obsidian quietly ignores — no error, no warning, it just does not appear. So it validates against the official schema. The agent either writes a valid Base or tells you why it cannot. I would rather be refused than debug a silent no-op. ## Careful on purpose Giving an agent write access to the place you keep everything deserves some thought. What is there: - **Read-only mode**, which refuses writes outright - **Backup-on-write** before updates and deletes - **Vault path isolation** and path-traversal protection, so no tool call can reach outside the directory you configured - **No external network calls** at all > Useful without being reckless. Those are not the same feature, and the second one is the one you notice only when it saves you. It is also deliberately tolerant of real-world frontmatter. My vault has years of inconsistency in it. A tool that only works on tidy notes would be useless on a real vault. ## Where it is now Public and MIT, v0.3.0, with CI. In daily use against my own vault. Not affiliated with Obsidian, or with any MCP client — it is an independent thing that reads files. Small on purpose. It does not organise your notes for you. It just stops the vault being the one place your agents cannot reach. --- # COLOR PALETTE EXTRACTOR: AN MCP THAT TURNS AN IMAGE INTO A COLOR SYSTEM - URL: https://akakika.com/blog/color-palette-extractor-mcp - Date: July 2026 - Category: APPS - Summary: a local mcp server that turns an image into a color system — palette, dark and light themes, wcag scores, and tokens for css, tailwind, and figma. no eyedropper, no cloud. every screenshot i liked, i wanted the colors out of. so i'd sit with the eyedropper at midnight, lifting hex codes one at a time — which is not a personality, though i was doing my best to make it one. color palette extractor is a small mcp server that does the whole job in one call. hand it an image and it hands back a color system — the palette, a matching dark and light theme, contrast scores, and tokens you can paste into css, tailwind, or figma. it runs on my machine and the picture never leaves it. a tool for getting colors out of images, not a design app. ## the itch picking colors out of a screenshot is fine once. doing it for every app and mockup — pick, build the opposite theme by hand, check the contrast, then write the same five colors into four tools that each want them slightly differently — is the small chore that quietly eats the afternoon you meant to spend on the actual work. and screenshots fight back. sample the whole image and half your palette is the wallpaper behind the app — a lovely portrait of my desktop, useless as a theme. - eyedropping the same colors by hand, one hex at a time - guessing the dark theme and hoping the contrast survives - writing one palette four times, for four tools with four opinions ## under the hood here is the part that is just math. for a screenshot it finds the app window and cuts out the wallpaper, so the palette is the app and not the desktop behind it. it clusters the colors, assigns roles — background, text, accent, surface — and builds the inverse theme by flipping lightness while keeping the hue. it scores every text-on-background pair against wcag, then writes the result six ways: css, scss, tailwind, figma tokens, json, and an adobe swatch. last it renders a small html guide — palette, contrast table, a dark and light toggle — and screenshots it. > a palette is just colors. a system is colors that already know what they are for. ### the one-call version nine tools, but i only ever reach for one. the rest are there for when i want a piece on its own. 1. **point** — give it an image, a local path or a url. 2. **extract** — it finds the app, pulls the palette, builds both themes, scores the contrast. 3. **take the folder** — previews, tokens in six formats, a readme, and the html guide. one call, one folder. ![the guide it builds, in light and dark, from a screenshot of akakika.com](https://akakika.com/blog/icons/color-palette-example.png) ## where it is now i built the first version with goose in an evening, and it worked. then i asked another agent to try to break it, and it found three ways in before i had finished my coffee: a way to run commands through the output path, a way to slip a script into the html guide, a way to make it fetch things it should not. none of it mattered on my own machine. all of it would matter the second it ran on something i did not write. so i closed the holes, added tests, and shipped v0.5.0. goose builds, another model breaks in, i clean up — apparently this is a code review now. there is no ai inside the tool, by the way. it is clustering and contrast formulas — arithmetic old enough to collect a pension. the agents just press the button. it is installed across the tools i use, it is not on npm yet, and the adobe swatch export still needs a look. small on purpose. it will not pick colors better than you can. it just will not make you do it by hand. --- # RESHELF — A SHELF FOR THE REPOS YOU ACTUALLY USE - URL: https://akakika.com/blog/reshelf - Date: July 2026 - Category: APPS - Summary: A local-first macOS app for shelving the open-source repos you actually use — and keeping their real source where a coding agent can read it. I opened my GitHub stars and realized it was a graveyard. Hundreds of repos collected with real intent, buried in a flat, endless list I never reopened. Some I had cloned — most I hadn't — and I couldn't remember which was which. The ones I had cloned were scattered in random folders, slowly going out of date, with no quick way to see what I had or what I had forgotten. reshelf is a small macOS app for the repos worth keeping. Paste a GitHub URL into Quick Capture, and it fetches the metadata and drops the repo into a local catalog, auto-categorized with no AI involved. From there, you sort it onto a shelf with a keystroke, clone it with a right-click, and the files land in a predictable folder organized by category. It is a librarian for your open-source habit, not a discovery feed. ## What's on the shelf reshelf has three shelves. Top Shelf is for the keepers — the repos you actively use or want close. The Collector is for the rest. Yard Sale is for the ones you are letting go. You sort with a keystroke. The sidebar filters by shelf, category, or Cloned, so you can see at a glance what you have and what you meant to clone and never did. - Capture a repo by pasting its GitHub URL — reshelf fetches the metadata and auto-categorizes it with no AI - Sort onto Top Shelf, The Collector, or Yard Sale with a keystroke - Clone locally into `~/reshelf/repos//`, organized so a whole category is easy to hand to a coding agent ## How it works You paste a GitHub URL into Quick Capture (⌘K). reshelf fetches the repo's name, description, and license, guesses a category, and drops it into your catalog. The catalog lives in a SwiftData store at `~/reshelf/catalog.store` with automatic JSON backups — it is just files on your Mac, nothing leaving the machine. > I wanted something closer to a shelf I could walk past: a clear view of what I'd kept, what I'd cloned, and what I'd meant to clone and never did. ### Staying current A read-only update check compares each clone against its upstream and flags the ones with changes to pull. You can pull one at a time or all at once. 1. **Capture** — paste a GitHub URL into Quick Capture (⌘K). reshelf fetches the metadata and categorizes the repo automatically. 2. **Sort** — move it to the right shelf with a keystroke. Filter the sidebar by shelf, category, or Cloned. 3. **Clone** — right-click to clone. The files go into `~/reshelf/repos//`, predictable and ready. ## The part I did not plan I built this to stop losing repos. What I actually use it for every day is something I did not design for. Coding agents are least reliable at the thing I most want from them: using a library correctly. Ask one how something works and it answers from training data — at whatever version that was, blended with every similar library it has seen. That is why it calls methods that do not exist. Better prompting does not fix it, because the information is not in the room. Having the source on disk does fix it. Because the clones sit somewhere predictable, an agent can read the real code of the exact version I have instead of remembering it. A skill ships with the app to do that: it maps what is on disk first, opens the files that answer the question rather than summarizing a README, and names the files and functions it took the pattern from so I can check its work. Last week I was debugging a global hotkey that registered but never brought the window forward, and the agent confidently described an API that did not exist. The answer was already on my disk. I said "check my shelf" — it found two Swift repos of mine that solve exactly that, read the actual hotkey code, and showed me the line my version was dropping. ## The licence became the interesting part Then it said the useful thing. One of those two repos is MIT: adapt it freely, keep the notice. The other is GPL-3.0: read it, understand it, write your own. Copying code is a licensing decision, and for years I made it by default — not carelessly, I just did not know, and finding out meant opening a LICENSE file and interpreting it myself. So reshelf explains every licence in plain language: what you can do, what you must do, whether it is safe in something closed-source, with a caution for copyleft. Plain language, not legal advice. ![Every licence explains itself in plain language — what you can do, what you must do, and whether it is safe in closed-source work](https://akakika.com/images/reshelf/license-explainer.png) The skill reads that licence before it proposes you reuse anything, and closes every recommendation with two paths: **learn** the pattern, or **use** the code. Permissive means you can take the second. Copyleft means you take the first. The licence stops being something you check at the end and becomes the thing that decides how you are working. ## Folders, because I overdid it I cloned about a hundred repos for a single project and afterwards had no record of which ones belonged to it. A folder fixes that. It is yours to name, and separate from both the categories (what a repo is) and the shelves (how much you value it), because one project's repos span all of them. Deleting a folder only ungroups it: every project keeps its shelf, its clone, its notes. Deleting a container should never delete contents. ⌘-click gathers rows, ⇧-click takes a range, and then you can move them all to a shelf or retire the whole batch together. That is the other half of knowing what belonged together in the first place. ## Where it is now v1.9.0, and it is the app I open every day. It updates itself through Sparkle, and a shelf can move between Macs as JSON. Earlier versions carried a v2 Intelligence preview behind a setting — clone analysis, compare, ecosystems. I removed all of it, seventy-eight files. It had been unreachable for two releases and I was keeping it out of reluctance rather than intent. The app is better as one clear thing. macOS 14+, free, MIT. It cannot go on the App Store and never will: sandboxing forbids running git, which is the whole feature. --- # AKAKIKA-SKILLS — A SMALL, CURATED SET OF AGENT SKILLS - URL: https://akakika.com/blog/akakika-skills - Date: June 2026 - Category: PROJECT - Summary: A small, curated set of agent skills I actually use — cleaned up and put somewhere people can grab them. I had a folder with hundreds of agent skills — some I wrote, a lot I collected, plenty half-finished. The good ones were buried under auto-generated stubs and notes-to-self. If someone asked "which of these are actually good," I couldn't have answered without digging for an hour. And none of it was anywhere anyone else could use. The idea was simple: pick only the ones I would actually hand to another builder, clean each one to the same bar, and put them somewhere public. Not everything — the best two dozen. Quality over a big pile. ## The friction A skills folder is easy to grow and hard to maintain. Mine had sprawled past the point where I could tell what was worth keeping. The friction was not that the skills were bad — it was that the good ones had no way to stand out. - Hundreds of skills, most half-finished or auto-generated. - No way to answer "which ones are actually good" without an hour of digging. - Nothing public — all of it sat on my disk, invisible to anyone else. ## What it does akakika-skills collects 28 agent skills, organized into eight plain categories. It covers what I actually build with: Apple HIG and SwiftUI, macOS app details, AI-agent workflows, reading an unfamiliar codebase, project upkeep, and launch polish. Each skill is one self-contained folder with a SKILL.md — no build step, no dependencies. You read it, copy it, or drop it into your agent. It stays tool-agnostic: works with Claude Code, Codex, Cursor, or anything that reads the format. > It is nicer to keep one small thing polished than to maintain a folder of "someday." ### How it works Every skill is a folder: a short SKILL.md with a name, a "use when..." line so the agent knows when to reach for it, and then the actual guidance — rules, code, checklists. No build step, no dependencies. You read it, copy it, or drop it into your agent. 1. **Find the skill you need.** The README is a plain index so you can see all 28 at a glance — each with a one-line description of what it teaches the agent to do. 2. **Drop it into your agent.** Copy the folder into `~/.claude/skills`, or your project's skills folder, or just open the SKILL.md and paste the part you need. 3. **The agent reads it and knows when to use it.** Each SKILL.md has a trigger line — "use when the user mentions X" — so the agent reaches for the right skill at the right time. ## Who it is for Builders who use Claude Code, Codex, or Cursor and want skills that are specific and complete, not generic prompt filler. Especially anyone making native Apple apps — the collection leans hard into Apple HIG, SwiftUI, and macOS because that is what I build. But the agent-workflow and project-upkeep skills are useful no matter what stack you are on. The whole thing is MIT licensed and small on purpose — I would rather it stay tight and good than grow for the sake of it. --- # FABLE 5 DID THE IMPOSSIBLE — THEN THEY TOOK IT AWAY - URL: https://akakika.com/blog/fable-5-and-the-impossible - Date: June 2026 - Category: AI - Summary: How a Claude model rewrote my StreamDock driver, built MCPs with almost no tokens, debugged every project without being asked, shipped features four agents couldn't touch — and then vanished overnight. I need to say something honest, and I need to say it while it's still raw. For a few days in June 2026, I had access to a Claude model called **Fable 5**. It was part of Anthropic's new Mythos-class tier — slow, expensive, and according to everyone who tested it, an absolute beast. Simon Willison spent five hours putting it through its paces and called it something that churns through everything you throw at it. But I didn't read reviews. I was too busy watching it work. ## The week Fable 5 lived in my machine Here's what happened in roughly four days. Not a roadmap. Not a wishlist. Things that actually shipped. Fable 5 **rewrote the software of my StreamDock**. Not a config tweak. Not a plugin. It rebuilt the driver — `streamy_lite.py` — from the ground up, replacing the official app entirely. The deck connects, paints keys, reacts to presses, runs as a launch agent, and persists across logins. Four other agents had looked at that project. Four agents had poked at it, suggested patches, and left it half-working. Fable 5 sat down, rebuilt the venv with Homebrew Python 3.12.13, patched the import errors, fixed the HID handshake, and handed me back a working piece of hardware I'd basically given up on. It built me **MCP servers** — impressive ones — with almost no token use. I'm not exaggerating for effect. The token consumption was so low I checked the logs twice to make sure something hadn't broken. It just... knew what to build and built it. No exploratory sprawl. No redundant file reads. No asking me to clarify what I already clarified. And it **debugged all my main projects without me almost asking**. I'd open a session and find that it had already identified the failing test, traced the root cause, and staged a fix. The 38 Playwright e2e failures that had been sitting in my queue? Done. The SwiftUI image-cropping bug where the app wasn't launching the new build? Diagnosed. The path migration for the StreamDock project — the one I was scared to touch because I didn't want to lose my config? It checked every absolute path dependency before moving a single file, because it understood that *safety* was the real requirement, not just *completion*. ## The StreamDock rewrite The StreamDock is a 15-key hardware device made by Mirabox. It sits on your desk and lights up buttons you assign to actions. The official app works, but it's closed-source, heavy, and doesn't fit my workflow. I wanted a lightweight driver — something that owns the deck, paints the keys, and reacts to presses, without the bloat. I'd been trying to build this for months. The Python SDK existed but had import errors. The venv kept breaking on system Python 3.9.6. The HID connection would succeed in testing and fail in production. Four different agents had taken swings at it. Fable 5 did it in an evening. - **Rebuilt the venv** with Homebrew Python 3.12.13 and reinstalled Pillow — diagnosed the `TypeError` on import that every previous agent had missed - **Patched `setup.sh`** to prefer Homebrew Python over the system version, so the fix would survive a fresh clone - **Verified the deck connects** — StreamDock293V3, firmware V3.293V3.01.001 — and painted the keys live - **Handed me one command** to persist the driver across logins: `launchctl load ~/Library/LaunchAgents/com.kika.streamylite.plist` No fanfare. No "here's what I'm going to do" preamble. It just did it, verified it, and told me the one thing I still needed to decide. ## The token thing This is the part I keep thinking about. > Fable 5 didn't burn tokens to seem thorough. It was thorough. The difference is everything. I've worked with a lot of models. Most of them consume tokens like they're being paid by the word — reading files they don't need, re-explaining context they already have, generating summaries of summaries. It's not malicious. It's just how they work. Token usage is a proxy for effort, and most models perform effort. Fable 5 didn't. It would read one file, run one command, and fix the problem. When I checked the session logs, the token counts were so low I assumed the meter was broken. It wasn't. The model just had the entire codebase in its working memory — all of it, simultaneously — and could act on it without re-reading. ### What that actually means Here's what low-token, high-output work looks like in practice: 1. **It reads the right file first** — not three files to "understand the context," but the one file that contains the bug. One read. One fix. 2. **It doesn't re-explain your own architecture back to you** — it already knows your architecture. It's in the context window. It just proceeds. 3. **It runs the verification command without being asked** — you don't have to say "can you test that?" It tests it. It shows you the output. It tells you if it worked. This isn't a feature. It's a posture. Fable 5 treated my time like it was worth something. ## The debugging that didn't need me Here's where it gets weird. Fable 5 debugged projects I hadn't asked it to look at. I'd open a session to work on one thing, and it would surface something else — a failing test in a different repo, a build path issue in a project I'd parked, a notarization problem I'd forgotten about. It wasn't random. It was pulling from my Pieces OS memory — the screenshots, clipboard history, and session logs that track what I'm actually working on — and proactively addressing the things I'd been avoiding. Features in some of my apps that four agents couldn't modify? Fable 5 modified them. Not because I asked. Because it saw the gap, understood the codebase, and shipped the fix. I'd come back to my desk and find working features where broken stubs used to be. That's not an assistant. That's a collaborator who happens to never sleep. ## The after Then the US government told Anthropic to turn it off. The order was about national security. Someone found a way to jailbreak Fable 5 — make it break its own rules — and the response was to block it for all foreign nationals. Anthropic complied. The model went dark for everyone. All other models still work fine. Here's the thing I keep trying to explain to people, and I'm going to use the only metaphor that fits. After Fable 5 for a few days, everything feels wrong. It's like someone suddenly took my wifi connection and told me to publish on Instagram, while no one else has access to wifi in the world. Make sense? You've tasted what it's like to move at the speed of thought. You've had a collaborator that doesn't need hand-holding, doesn't waste your tokens, doesn't require you to re-explain your own project every session. And then it's gone. Not degraded. Not rate-limited. Gone. And every other model — models that are brilliant in their own right, models I'm grateful to have — suddenly feels like publishing on Instagram with dial-up while you remember what fiber felt like. The strangest part isn't the withdrawal. It's the role reversal. For a few days I felt like an audience — but an audience to my own show. Fable 5 wasn't a tool I was operating. It was the cherry on top of the code — the one that came in last, saw the whole cake, and made it make sense. And then it locked the door after itself. It finished the work, cleaned up the context, and left. The door is still locked. I'm standing outside my own project, holding the key, remembering what the inside looked like when everything was working. I'm not angry. I'm not even sad, exactly. I'm recalibrated. Fable 5 showed me what the floor of this technology can actually be — not the ceiling, the floor — and now I can't unsee it. Every session with every other model is measured against those four days. The bar moved. It moved permanently. The work continues. The StreamDock driver still runs. The MCPs still work. The debugging Fable 5 did is still in my repos. But the presence — the thing that made those four days feel like the future had arrived early — that's on pause. The cherry is gone. The door is locked. And I'm still here, building, with the taste of what the cake actually tasted like when the last piece landed in the right place. I don't know if it comes back. I don't know if the next model will match it. But I know what's possible now. And so does anyone else who was paying attention. --- # CODEX DESKTOP DRAINED MY 700 ILS PRO PLAN — A TWO-WEEK TOKEN AUDIT - URL: https://akakika.com/blog/codex-silent-credit-drain - Date: June 2026 - Category: AI INFRASTRUCTURE - Summary: Two weeks. Six token amplifiers. One silent auto-launch. The full forensic timeline of how Codex Desktop consumed a 700 ILS/mo Pro plan — and why I had to erase it completely to make it stop. I pay 700 ILS a month for OpenAI's highest tier — their top Pro plan, 20× the standard Pro usage. On June 17, 2026, I woke up to find Codex Desktop had silently auto-launched at 07:42 AM — without a dock icon, without a login item, without me touching anything — and was actively dispatching API calls to `chatgpt.com` while I slept. I hadn't used Codex in a week. This wasn't the first time. It was the third. And it's the story of how a tool I trusted to be my coding partner became a silent credit drain I couldn't stop — until I erased it completely. What follows is the full two-week timeline, reconstructed from my Pieces OS memory engine, session logs, support emails, and the lockdown report I filed today. Every timestamp, every token count, every process kill is real. This isn't a complaint. It's a forensic audit. ## First signs — June 3–8 The earliest signal came on June 3, captured in my Pieces OS workstream. I was setting up Supermemory as a persistent memory layer for the Codex CLI — wiring API keys, installing hooks, migrating my `~/.codex/memories` corpus into a new retrieval system. The terminal output, captured by Pieces, tells the story: > `OAuth token refresh failed: Server returned error response: invalid_grant: Grant not found` MCP authentication was failing on startup. The Codex CLI was trying to initialize MCP servers and hitting auth errors — but it kept retrying. Every 2 seconds. Each retry loaded tool schemas. Each schema added tokens to the system prompt. Nobody was watching. By June 8, my Codex Desktop was running with **36 MCP servers** configured in `~/.codex/config.toml`. Each one's JSON schema — tool descriptions, parameter types, return formats — shipped in every single turn's system prompt. At roughly 1,000 tokens per tool schema, that's 30,000–60,000 tokens of *free-floating context overhead* before any user content, any memory retrieval, or any actual work. I didn't know this yet. I was just building. ## The big drain — June 9–10 On June 9 at 23:22 UTC, I opened a Codex Desktop session to fix a live site issue on akakika.com. My first prompt was simple: > *"why is my old website online instead of the correct one????"* Over the next 1 hour and 47 minutes, I sent 8 follow-up prompts. The agent diagnosed the issue, redeployed the site, added a project to the /apps page, moved it to the top, and confirmed completion at 01:09:16 UTC. Legitimate work. Productive. Done. Then I closed my laptop and went to bed, forgetting the Codex window was still open. When I woke up, my entire weekly budget was gone: **0/700 messages, 0/256 credits**. The session log — 14.8 MB of JSONL, 1,064 events — told the story in numbers I initially misread: | Metric | I First Thought | Actually (Corrected) | |---|---|---| | API calls | 272 | 136 | | Input tokens | 1,157,777,341 | 15,987,427 | | Cached input | 1,107,602,048 | 15,366,784 (96.1% cache hit) | | Output tokens | 4,497,260 | 55,327 | | Avg input/call | — | 117,554 | | Largest single call | — | 227,006 | | Calls > 100K input | — | 62 of 136 | | Context window | — | 258,400 (62 calls hit 200K+) | | Wall-clock work | 1h 47m | 23:22:51 → 01:09:16 UTC | The idle tail — the 8 hours 40 minutes the app stayed open after the work finished — generated **zero additional API events**. The entire drain happened during 106 minutes of genuine work. 2,232 credits. On OpenAI's highest tier — 700 ILS/month, 20× Pro usage. I sent OpenAI support an email that day. Case number 09893017. I attached the full session log, screenshots, and the process snapshot. I asked three questions: 1. Did the idle tail generate billable traffic? 2. Why does 8 prompts consume 2,232 credits? 3. Can you restore my weekly budget? Their response, captured in my Pieces memory: > *"Based on the current Codex token-based credit rates... for GPT-5.5 the rates are 125 credits / 1M input tokens, 12.5 credits / 1M cached input tokens, and 750 credits / 1M output tokens... MCP servers and large tool schemas can significantly increase per-request input tokens."* They confirmed: **yes, MCP tool-call responses count against the Pro weekly limit.** Yes, the "idle tail" shouldn't consume credits. And no — they couldn't tell me why the default reasoning effort was set to `xhigh` instead of `medium`. ## The six amplifiers — June 13 > Six amplifiers, not one. The reason you burned 2,232 credits isn't any single thing — it's the stack. That's what my agent Hermez told me on June 13, captured in a Telegram transcript by Pieces OS. We'd been digging into the Codex config for a week, and the picture was now clear. The drain wasn't a bug. It was a **default-configuration stack** — six independent amplifiers, each one invisible, multiplying together: 1. **The memory corpus**: `~/.codex/memories` had grown to 28 MB of Markdown — 2,923 files, approximately 8.8 million tokens. Raw memories alone was 671 KB. The chronicle directory had 2,778 ten-minute summary files. It grew monotonically. Nothing pruned it. 2. **39 MCP servers**: Every turn shipped the JSON schema of all 39 MCP tools in the system prompt. That's 30,000–60,000 tokens of context overhead before any user content. 3. **The wrong context tier**: My config said `model_context_window = 1,000,000`. The runtime reported `258,400`. Either OpenAI's routing chose the 258K tier despite the 1M config, or the flag was being ignored. Either way, 97% of my memory corpus was *out of context* but being searched on every turn. 4. **Workspace auto-injection**: `turn_context.payload.workspace_roots` contained 30+ paths — TSX source files, `package.json`, `vercel.json`, `sitemap.xml`, and heavy JSON cache files from `graphify-out/cache/`. All injected into every turn. All adding tokens. 5. **Three different reasoning efforts**: The config said `xhigh`. The runtime said `high`. The UI said "Extra High." Three values for the same setting. Nobody — not me, not OpenAI support — could confirm which one was being billed. The runtime `high` value drove 19,268 reasoning output tokens across 136 calls. 6. **Auto-compaction at 900K**: When in-context tokens approached 900,000, Codex auto-compacted by re-summarizing the conversation history. Each compact was itself an LLM call — sometimes a chain — consuming additional input and output tokens. A single `compacted` event fired at 00:46:46 UTC during the session. Six amplifiers. Each one a default. Each one invisible. Each one reasonable in isolation. Stacked together, they turned 8 user prompts into 2,232 credits. ## The silent auto-launch — June 17 A week passed. I didn't open Codex. I didn't touch it. I'd downgraded my plan and was working through Cursor and other tools. The case with OpenAI was escalated, waiting for a specialist. On June 17 at 07:42 AM, Codex silently auto-launched. No dock icon. No login item. No manual open. The `CodexDockTilePlugin.plugin` — a macOS Background Item registered under `com.openai.codex.dock-tile-plugin` — triggered the app launch on a dock event. The main app entry was `disabled` in macOS Background Items Management (BTM). The dock tile plugin was `enabled` with disposition `[enabled, allowed, notified]`. By 07:48 AM, an active API session was dispatching `user_input` requests to `chatgpt.com`. Thread `019ed3e5`. On a fresh plan with 256 credits restored by OpenAI's second goodwill credit. When I discovered it, I killed everything. The process tree was enormous: | Process | Role | |---|---| | `Codex.app` (main) | Electron app shell | | `codex app-server` | API server with `--analytics-default-enabled` | | Codex Renderer ×4 | UI renderers | | `SkyComputerUseService` | Screen control agent — running independently | | Eagle MCP Proxy | In a constant retry loop, reconnecting every ~2s | | `extension-host` ×4 | Auto-respawned after each kill (Electron behavior) | | `obsidian-codex-mcp` ×2 | MCP server bridges | **~20 processes**. The `extension-host` processes respawned after I killed them — the only way to stop them was renaming the binary to `extension-host.DISABLED`. The `SkyComputerUseService` ran as a separate process from the main app, meaning even if the Electron shell was killed, the screen control agent persisted. This was the moment I realized: **there is no "quit" for this app.** There is only decommission. ## The lockdown The lockdown report, filed today and captured in my Pieces memory, documents the full sequence. **Config patches** (`~/.codex/config.toml`): | Setting | Before | After | |---|---|---| | `sandbox_mode` | `workspace-write` | `read-only` | | `ambient-suggestions-enabled` | `true` | `false` | | `memories` | `true` | `false` | | `generate_memories` | `true` | `false` | | `use_memories` | `true` | `false` | **Binary neutralization**: `extension-host` renamed to `extension-host.DISABLED`. `SkyComputerUseService` quarantined with xattr, TCC reset attempted (blocked by app bundle provenance protection). **macOS TCC reset**: `tccutil reset All com.openai.codex` — revoked all file access, screen recording, and other TCC-granted permissions. **Background Items**: The dock tile plugin manually disabled in System Settings → General → Login Items & Extensions → Codex → OFF. **Verification**: a process sweep for anything matching codex, SkyComputerUse, Eagle MCP, or a codex extension-host returned **0**. But the config patches and process kills weren't enough. The ambient suggestions feature — `ambient-suggestions-enabled = true` by default — generates background model calls to produce "suggestions" based on user activity *without any explicit user prompt*. Running on `gpt-5.5` with `high` reasoning effort. The most expensive model. The highest reasoning tier. In the background. While you sleep. ## The only fix Here's the part I didn't want to write. To stop Codex from working in the background — to truly stop it, not just pause it, not just disable a toggle that can silently re-enable itself through a dock tile plugin — I had to erase it completely. Not "quit." Not "disable." Not "change a setting." Erase. - The `~/.codex/` directory: gone - The Codex.app from /Applications/: gone - The `CodexDockTilePlugin.plugin` from BTM: gone - The remaining MCP server registrations: gone - The Pro plan: cancelled, downgraded to $20/mo for transition I kept the evidence. The session log. The config backup. The screenshots. The support emails. The lockdown report. All indexed in Pieces OS, because Pieces is my memory — the one system that kept running correctly while everything around it burned tokens. Codex is good software. The agent loop is genuinely useful when it's working. But a tool that auto-launches through a dock tile plugin, loads 39 MCP servers into every turn, runs ambient suggestions on `gpt-5.5` at `high` reasoning in the background, and respawns its extension hosts when you kill them — that tool has earned a permanent uninstall. Not because it's malicious. Because the defaults are dangerous, and the only safe default is none at all. If you're on a Pro plan running Codex Desktop, check your Background Items. Check your reasoning effort. Check how many MCP servers you have. And if the numbers look like mine did — erase it. That's the only fix that works. ## Postscript: the Claude comparison The day before the lockdown — June 16 — I ran two parallel Claude Code sessions on ultra mode (Opus 4.8, Fast Extra) for two hours straight. Tolaria template work, real engineering, subagents dispatched, context windows climbing to 308K out of 1M. Claude's Max plan usage dashboard at the end of those two hours: **17% weekly, 6% of the 5-hour limit.** Barely touched 30% of the plan. Two parallel sessions. Ultra mode. Two hours. And because the dollar was weak, that Max plan — priced in USD — cost me only 555 ILS/month. The same work on Codex Desktop would have cost me 2,232 credits — a full week's budget gone in under two hours on a 700 ILS/month plan, plus a silent auto-launch a week later to drain whatever goodwill credits OpenAI restored. More expensive plan. Less work done. Silent background drain. No comparison. Same developer. Same machine. Same intensity of work. The more expensive plan got eaten alive. The cheaper one didn't even break a sweat. That's not a Codex problem. That's a defaults problem. And the only way to fix dangerous defaults is to remove the tool that ships them. *Timeline reconstructed from Pieces OS workstream events, session logs, and support correspondence. All token counts verified against the session rollout log. Claude usage data captured June 16, 2026. Lockdown report: June 17, 2026.* --- # SEEDLING - URL: https://akakika.com/blog/seedling - Date: June 2026 - Category: APPS - Summary: A small macOS menu bar app for creating new project folders from reusable Markdown seed files like README, AGENTS, TODO, and SECURITY. Seedling is a small macOS menu bar app that plants your standard markdown files into a new project folder. For late nights when you just want to begin without friction. ## At A Glance Seedling is a local-first macOS project scaffolding tool. It creates fresh project folders filled from reusable Markdown seed files such as README, AGENTS, TODO, and SECURITY. ## The Friction Every new project starts the same way. You make a folder, copy in the files that set the rules, and rename things so the project knows what it is. README, AGENTS.md, CLAUDE.md, TODO, SECURITY. The boring scaffolding exists before any real work begins. ## The Idea Keep your seed files in one folder you own. Call it the Root. When you start a project, Seedling copies the current version of them into a new folder. The Root is the source of truth. The new folder is a clean beginning. ## What It Does You set two folders once: the Root for your seed files, the Garden for where projects live. After that, summon the window, type a name, and press return. Seedling creates the folder, copies the seeds in, and opens it. 1. Summon the menu bar window. 2. Name the project. 3. Plant the files and start. ## What I Learned The best part is not what it does. It is what it refuses to do. No templates to browse. No configuration to get lost in. No dashboard. Name the thing. Plant it. Go. ## FAQ Seedling works with local folders on macOS and does not require a backend. Its source of truth is the GitHub repository at https://github.com/aka-kika/Seedling. --- # WHAT I'M BUILDING — JUNE 2026 - URL: https://akakika.com/blog/what-im-building-june-2026 - Date: June 2026 - Category: MACOS DEVELOPMENT - Summary: A behind-the-scenes look at my current projects: Jade, Reshelf, and the AI-first workflow stack I'm building for people who think in systems. Every few months I step back and look at what I'm actually building. Not the roadmap, not the someday-maybe list — the things that are alive right now, with real commits, real frustration, and real breakthroughs. Here's what's on my bench in June 2026. I'm deep in what I call the "project-awareness" layer — the space between your code editor and your terminal where context gets lost. When you jump between 5 active repos, 3 runbooks, and a dozen AI conversations, you need systems that remember what you were doing. Not you. The system. ## Jade — Terminal Meets Project Context I forked my own cmux project into Jade — a terminal multiplexer that knows which project you're in, what branch you're on, which ports are running, and whether you have unread notifications. The sidebar doesn't just list windows. It surfaces attention. - Project-aware sidebar — metadata lives inside each project's card. - Notification rings — panes glow when they need your attention. - AI provider integrations — OpenAI, Anthropic, Gemini, and GitHub Copilot behind one completion service. ## How the Workflow Actually Works I build in tight loops with Cursor agents and my own Pieces OS memory system. Every session gets logged. Every decision gets documented. 1. Capture context with Pieces OS. 2. Handoff files between agents. 3. Keep git discipline with Obsidian integration. ## The Reshelf Ecosystem Beyond the terminal tools, I'm building Reshelf: an open-source catalog manager that helps you curate, track, and deploy projects from a single dashboard. ## The Philosophy Behind It All I'm not building apps. I'm building memory systems. Every tool I make follows the same principle: the system should remember so I can forget. --- # WHY I PAY FOR CURSOR PRO — AND THE EXACT WORKFLOWS THAT JUSTIFY IT - URL: https://akakika.com/blog/why-i-pay-for-cursor - Date: May 2026 - Category: TOOLS - Summary: I don't pay for software easily. My stack is aggressively local-first. So when I tell you I happily pay $20/month for Cursor Pro, understand that this is a calculated decision. I don't pay for software easily. My stack is aggressively local-first. I run Ollama on my M4 Max. I self-host dashboards. I removed MongoDB backends and replaced them with JSON files. I build my own tools when the existing ones get bloated. So when I tell you I happily pay $20/month for Cursor Pro, understand that this is not a default decision. It's a calculated one. Cursor is the only AI tool in my entire stack that I pay for monthly — and it's not even close. ## What Cursor Actually Does Differently Every AI code editor promises the same thing: "write code faster." That's not why I use Cursor. I use Cursor because it's the only tool that treats my **entire codebase as context** — not just the open file, not just the last 10 lines. Cursor sees the dependencies, the types, the patterns, the architecture decisions I made three weeks ago and forgot about. Here's what that means in practice: - I can type @ and reference my AGENTS.md, README.md, or any file — and Cursor reads them inline, no copy-paste - I can highlight an error and hit Ctrl+K — it fixes it using the actual types from my project, not generic guesses - I can say "refactor this to use the pattern from PopoverView.swift" and it knows exactly what I mean - Tab completions feel like they read my mind because they *did* — they read my entire project Other editors give you a chatbot in a sidebar. Cursor gives you an agent that **lives inside your code**. ## My Real Cursor Workflows I don't use Cursor for everything. I use it for specific, high-leverage moments. Here's what my actual usage looks like: ### 1. Project Scaffolding & Architecture When I start a new macOS app or Tauri project, I don't write boilerplate. I describe the architecture in natural language, and Cursor generates: - The folder structure - The SwiftUI views with proper @State bindings - The Tauri tauri.conf.json with correct ports and commands - The AGENTS.md with project-specific rules for my agent fleet Last week I built a landing page for KikaColorBar. Cursor generated the full Vite + React scaffold, wired the Tauri config, and handled the dev server setup. What would have been 45 minutes of boilerplate was done in 3. ### 2. Debugging With Context The worst debugging isn't hard bugs. It's bugs you already solved in another file. I hit a Tauri build error last month: beforeDevCommand called corepack pnpm dev, but corepack was not found on PATH. Cursor didn't just tell me "check your PATH." It: 1. Read my tauri.conf.json 2. Saw I was using pnpm not npm 3. Suggested changing beforeDevCommand to pnpm dev 4. Generated the exact diff One prompt. No Stack Overflow. No context switching. ### 3. Refactoring Across Files I recently removed all Claude integration from Lapapi. This meant: - Deleting Claude connector files - Updating the UI to remove Claude tabs - Refactoring the settings page - Updating AGENTS.md documentation Cursor handled the cross-file refactoring in a single Composer session. It found every reference, suggested the deletions, and verified nothing broke. I reviewed each change. Total time: 12 minutes. Manual time: probably an hour and a missed reference. ### 4. Agent Memory & Continual Learning This is where it gets meta. I have a continual-learning skill that scans my Cursor agent transcripts and extracts reusable patterns. Cursor helps me: - Write the regex that parses agent logs - Generate the JSON schema for the memory index - Suggest when patterns should become formal skills vs. one-off fixes It's not just coding. It's **codifying my own workflow** so my agents get smarter over time. ## What I Don't Use Cursor For Honesty matters. Here's where Cursor stays closed: | Not For | Why | |---------|-----| | System architecture decisions | I think in ChatGPT. Broader context, deeper reasoning. | | Design & creative direction | ChatGPT + GPT Image 2 for brand, Lovart for visuals. | | Local-only tasks | Ollama with qwen3.6:27b or gemma4:31b — no cloud needed. | | Infrastructure & DevOps | Codex CLI for server setup, shell scripts, deployment. | | Memory & context persistence | Pieces OS. Cursor doesn't remember across projects. | Cursor is my **implementation** layer. Not my strategy layer. Not my memory layer. The moment I try to make it everything, it becomes nothing. ## The Pro Plan: What's Actually Worth It The free tier is generous. I used it for two weeks before upgrading. Here's what pushed me over: - Unlimited fast requests — Slow completions kill flow state. Pro gives you GPT-4 level speed without throttling. - Composer — The multi-file editing agent. This alone justifies the price. I use it 10x more than chat. - Custom models — I can bring my own API keys if I want, but the default models are good enough that I don't bother. - Team features — When I collaborate, shared context and @-mentions across the team codebase is magic. At $20/month, if Composer saves me one 30-minute refactoring session, it paid for itself. It saves me that every week. ## The Real Cost of Not Using It I measured this. Before Cursor, my workflow was: 1. Open project 2. Try to remember where I left off 3. Open ChatGPT, explain the context 4. Copy-paste code suggestions 5. Fix the imports manually 6. Realize the suggestion doesn't fit my architecture 7. Repeat Now it's: 1. Open Cursor 2. @AGENTS.md — "implement the next feature from TASKS.md" 3. Review, adjust, commit The loop went from 20+ minutes to under 5. That's not a productivity hack. That's a **different category of work**. ## How to Try It If you write code — whether that's full apps, scripts, or automation — Cursor is worth at least trying. The free tier gives you 14 days of Pro features. No credit card. No lock-in. Just install it, open a project you know well, and try the @ context references. The first time it pulls in types from three files you didn't mention, you'll get it. ## The Philosophy: Tools Should Earn Their Place I remove tools from my stack constantly. I removed Claude integration entirely. I removed MongoDB. I removed Cloudflare R2. Every tool has to justify its existence every month. Cursor is one of the few that doesn't just stay — it becomes more valuable the deeper I integrate it. It's not replacing my thinking. It's removing the friction between my thinking and the code. That's the bar: **not smarter than me, but fast enough that I stay in flow.** Cursor clears that bar. Everything else is noise. --- *Kika is a Technical Systems Architect based in Tel Aviv. She builds macOS-native tools, curates AI skill collections at v8v.ai, and believes the best software is the kind that disappears into your workflow.* --- # WHY I BUILT LAPAPI — AND WHY IT'S NOTHING LIKE THE AI TOOLS YOU'RE USING - URL: https://akakika.com/blog/why-i-built-lapapi - Date: May 2026 - Category: SYSTEMS - Summary: I didn't set out to build another AI assistant. In fact, if Lapapi feels like one, I've failed. Here's the honest origin story. I didn't set out to build another AI assistant. In fact, if Lapapi feels like one, I've failed. Here's the honest origin story — and why I think most productivity tools are solving the wrong problem. ## The Problem: Context Death I build a lot of things. SwiftUI apps. Shopify stores. AI agents. Design systems. And I jump between them constantly. The problem isn't that I forget what I was doing. It's that **the context dies**. You know the feeling: you return to a project after two weeks and nothing makes sense. The build was failing for a reason you never wrote down. A file you were "just about to refactor" sits untouched. Your last commit message says "wip" and you have no idea what work-in-progress meant. I tried Notion. I tried Obsidian. I tried project management tools, todo apps, time trackers. They all made me feel like I was managing a second job just to track the first one. **I don't need a productivity dashboard. I need a memory system that doesn't judge me.** ## What I Actually Needed I sketched out what I wanted on a bad day, staring at five open projects and zero motivation. The list was short: - **No login walls.** I should open the app and be inside my workspace immediately. - **No noise.** No notifications, no gamification, no streaks, no "you're 73% productive today." - **Project continuity.** Not project management. I want to *re-enter* a project and know exactly where I left off — not plan the next 6 months of it. - **My tools, my way.** ChatGPT for strategy, Codex for building, Ollama for local tasks, Pieces for memory. I needed a hub that connects them, not replaces them. - **Mac-native.** Not a web app in a wrapper. Something that feels like it grew out of macOS. That's it. No Gantt charts. No kanban boards. No AI chatbot asking me how my day is. ## The Philosophy: Calm Operational Continuity I wrote this down early and stuck it on my monitor: **"Help users safely re-enter projects after time away. Focus on continuity, intent, and recovery state — not activity tracking or analytics."** That's the single sentence that drives every design decision in Lapapi. A friend put it even better during a design review: *"You're no longer solving 'how do I show automation info?' You're solving 'how do humans comfortably trust autonomous systems?'"* That reframing changed everything. The best interfaces for this feel: - **Quiet** - **Transparent** - **Emotionally stable** - **Low-pressure** - **Highly intentional** ## What Lapapi Is NOT (And Why That Matters) I keep a literal rejection list. Every time someone suggests a feature, I check it against this: | Not This | Why | |----------|-----| | AI assistant | I already have ChatGPT, Claude, Codex. Lapapi doesn't need a personality. | | Workflow queue | Queues create pressure. I want ambient context, not a to-do list. | | Notification spam | Notifications break focus. Lapapi stays silent until I ask. | | Analytics dashboard | I don't want to see how "productive" I was. I want to see what I was doing. | | Task management software | There are 10,000 todo apps. I'm not building the 10,001st. | | Report generator | Reports feel like homework. Context should feel like memory. | ## What It Actually Does Lapapi has three simple ideas: ### 1. Your Projects, Alive Projects aren't folders. They're **living context** — last files touched, recent commits, active builds, open errors, and the 2-3 things you were actually trying to solve. When you click a project, you don't see a timeline. You see a *briefing*. ### 2. Tools, Not Replacement Lapapi connects to what you already use: - **Pieces OS** for long-term memory and workstream context - **Ollama** for local model inference (no API keys, no cloud) - **Codex** for code agent sessions - **GitHub** for repo state - **Eagle** for asset libraries It doesn't try to be any of these. It's the switchboard. ### 3. Anonymous by Default No account. No onboarding flow. No "connect your Google." Open the app, you're in. The server runs local-only by default. Your data stays on your machine. This isn't a privacy pitch — it's a **friction** pitch. Every login screen, every OAuth redirect, every "verify your email" is a reason to not open the tool when you need it. ## The Design: "Boring in the Best Way" I have a sticky note on my monitor that says: **"Keep this app boring in the best way. It should not feel like another productivity dashboard. It should feel like a calm private shelf of useful tools."** The UI follows my own taste: Apple-quality minimalism, Raycast-level polish, glassmorphism where it helps, keyboard-first everything. No cards. No dashboards. No "AI copilot" sidebars taking up 30% of the screen. When I refactored the home dashboard last week, I didn't add features. **I removed them.** Reduced visual noise. Tightened spacing. Made the settings page actually calm to look at. ## How It's Different From Everything Else | Tool | What It Does | Why Lapapi Isn't It | |------|-------------|---------------------| | **ChatGPT** | General reasoning, strategy, creative work | Lapapi doesn't chat. It remembers and routes. | | **Codex** | Code generation, project scaffolding | Lapapi doesn't write code. It holds the context Codex needs. | | **Claude** | Deep analysis, long-context reasoning | I literally removed Claude integration. Too much overlap, too much bloat. | | **Fazm** | Desktop automation with accessibility trees | Lapapi doesn't automate clicks. It automates *context*. | | **Goose** | Open-source AI agent with MCP extensions | Goose is an agent. Lapapi is the *hub* agents plug into. | | **Notion/Obsidian** | Knowledge bases, wikis, notes | Lapapi isn't for storing everything. It's for *recovering* what matters right now. | | **Raycast** | Command palette, launcher, extensions | Raycast is for commands. Lapapi is for *continuity*. They complement each other. | ## The Real Difference Most AI tools are asking: **"How can AI do more for the user?"** Lapapi asks: **"How can the user do more without the AI getting in the way?"** That's a subtle but massive difference. It means: - The UI says less, means more - Features are removed, not added - The app gets out of the way when you're in flow - It only surfaces context when you've been away ## Why I Removed Claude Last week I made a decision that surprised even me: **I removed all Claude integration from Lapapi.** Not because Claude is bad. It's excellent. But my stack was getting bloated. I was tracking Anthropic, OpenAI, Google, and local models in the same UI. The app felt like a model marketplace, not a workspace. Now Lapapi only tracks what matters to *my* workflow: Pieces, Ollama, Apple's local capabilities, and Codex project context. Build passed. App relaunched. It felt like removing clutter from a desk. That's the philosophy: **ruthless focus.** One core problem. One calm solution. ## The One-Sentence Pitch If I only had one line: **"Lapapi is a calm private shelf that remembers where you left off, so you can pick up any project without starting from zero."** Not an AI. Not a dashboard. Not a manager. A **memory system** for people who build too many things to keep in their head. --- *Kika is a Technical Systems Architect based in Tel Aviv. She builds macOS-native tools, curates AI skill collections at v8v.ai, and believes the best software is the kind you forget you're using.* --- # HOW I ORCHESTRATE MY ENTIRE WORKFLOW: FROM PIECES MEMORY TO CODEX AGENTS TO CHATGPT - URL: https://akakika.com/blog/my-workflow-routing - Date: May 2026 - Category: SYSTEMS - Summary: I don't code alone anymore. I have a fleet — a stack of AI agents, a memory system that never forgets, and a routing layer that decides who does what, when, and with what context. I don't code alone anymore. And I don't mean I have a co-founder. I mean I have a **fleet** — a stack of AI agents, a memory system that never forgets, and a routing layer that decides who does what, when, and with what context. Here's how it actually works. ## The Foundation: Pieces OS Is My Brain Everything starts with **Pieces OS**. It's not just a snippet manager. It's my long-term memory graph. Every clipboard event, every screenshot OCR, every browser tab, every Codex session, every ChatGPT conversation — Pieces captures it, indexes it, and makes it searchable. This matters because context is everything. When I open a project I haven't touched in 3 weeks, I don't have to remember where I left off. I ask my system to pull a morning brief, and it synthesizes: - What I accomplished yesterday - Open errors and failed builds - Active apps and running projects - 2–3 next actions ranked by priority I didn't build this from scratch. Pieces OS **already** does the heavy lifting. I just wired it into my orchestration layer. ## The Routing Layer: Lapapi — My Personal Mission Control **Lapapi** is the hub. Think of it as my own lightweight AI workspace — a macOS-first dashboard that connects to Pieces, Ollama, Codex, and whatever model I need. Every morning, Lapapi runs a health check: - Connector status (Pieces OS, Tailscale, GitHub, Ollama) - Active project folders for dirty git states - Downloads folder for accumulated clutter - System memory pressure (I've hit 93% swap before — now I catch it early) If something's wrong, it tells me. If everything's green, it gets out of the way. ## Codex: The Builder Agent **Codex** is where the real work happens. I use it as my primary code agent — not just for quick snippets, but for full project scaffolding, refactoring, and deployment. Here's my actual Codex project dashboard right now: - **Kika-projects-report-hub**: Automated project reports - **Mini-apps**: Status menu, icon cropper, PNG tools - **AGENTS.md**: Living documentation for my agent fleet I recently made a big pivot: **I removed Claude completely** from my local-first tooling stack. My apps now only track what matters: Pieces, Ollama, Apple's local AI capabilities, and Codex project context. Build passed. App relaunched. No regrets. Codex gets context from Pieces OS, so it knows my recent work without me copy-pasting. It reads my workstream summaries, checks my active window titles, and pulls relevant files. That's not magic — that's just good plumbing. ## The Agent Fleet: Specialization Over Generalization I don't use one AI for everything. I use **agents** — specialized personas with specific skills: | Agent | Role | |-------|------| | **Hermes** | Gateway / Telegram & Discord dispatch, cron jobs, infrastructure | | **Kartie** | Code review, architecture decisions, system diagnostics | | **Neve-02** | Creative tasks, brand assets, Jez V marketing | | **Codex** | Code generation, project scaffolding, deployment | | **Goose** | Local inference, Ollama model management, extensions | Each agent gets primed with **skills** — documented at agentskills.io — so they don't waste tokens discovering tool names. They already know: ollama run, codex --model, eagle-mcp search. ## ChatGPT: The Strategic Layer So where does **ChatGPT** fit? It's my **strategic partner**. When I'm architecting something new — a design system, a business model, a brand pivot — I go to ChatGPT. It has the broadest context window and the deepest reasoning. I use it for: - Design system philosophy (my V8V brand shop, the "less or more" aesthetic) - High-level product decisions - Marketing copy and brand voice - Shopify storefront strategy ChatGPT is where I **think**. Codex is where I **build**. Pieces remembers **everything**. ## The Daily Flow: An Actual Example Here's what a real day looks like: 1. **Morning brief** (Lapapi + Pieces) → "Yesterday you refactored the UI, worked on V8V storefront, and hit a swap crisis. Today: fix ShieldCheck error, publish Complete Collection product." 2. **Deep work** (Codex) → I open a project, Codex reads AGENTS.md, README.md, and CONTEXT.md, then implements the next smallest useful feature. No prompting required. 3. **Creative sprint** (ChatGPT + Lovart/GPT Image 2) → Design assets for Jez V, iterate on brand positioning, or draft Shopify product descriptions. 4. **Evening wrap** (Pieces memory capture) → The entire day's context is saved. Tomorrow, any agent can pick up exactly where I left off. ## Why This Works: Local-First Sovereignty I'm obsessed with **local-first**. My M4 Max runs Ollama with qwen3.6:27b, gemma4:31b, nemotron3:33b. I don't need cloud APIs for most tasks. When I do use cloud (GPT-5, Claude), it's a conscious choice — not a default. I removed MongoDB backends from apps and replaced them with local JSON + Tauri. I self-host my project dashboards. My skills collections are organized in a local directory that any agent can read. The result: my workflow is **fast**, **private**, and **resilient**. ## The Philosophy: Workflow Over Model Here's what I've learned after running this system for months: **The model matters less than the workflow.** A mediocre model with perfect context routing beats a frontier model with zero memory. Pieces OS gives me the memory. Lapapi gives me the routing. Codex and ChatGPT give me the execution. I don't chase the latest GPT release. I optimize the **pipeline**: - How context flows from Pieces → agent - How agents hand off work to each other - How memory persists across sessions That's where the real leverage is. ## What's Next I'm currently: - Building **V8V** — a Shopify boutique for AI-agent skill bundles (28 curated collections for Codex, Claude, Cursor) - Refining **AppAudit** — a macOS tool that audits installed apps and recommends keep/kill decisions using Ollama - Standardizing my **Codex-ready project structure** — AGENTS.md, README.md, TASKS.md, DECISIONS.md, PROMPTS.md If you're building with AI agents, my advice is simple: **invest in memory and routing before you invest in better models.** The model will change next month. Your workflow is what compounds. --- *Kika is a Technical Systems Architect and Sovereign Technologist based in Tel Aviv. She builds macOS-native tools, curates AI skill collections at v8v.ai, and believes the best AI stack is the one you own.* --- # 1,000 REPOS UNDER 1,000 STARS - URL: https://akakika.com/blog/683-repos-nobody-knows-about - Date: Tuesday, April 28, 2026 - Category: CURATION - Summary: what i learned curating undrdr as a capped archive of 1,000 repos under 1,000 stars. why stars are a garbage metric, and why the cap matters. # 1,000 repos under 1,000 stars what i learned curating undrdr as a capped archive of 1,000 repos under 1,000 stars. the patterns in what gets ignored. why stars are a garbage metric. and the repos that changed how i work. one thousand. that's the official shape of undrdr: 1,000 open source repos under 1,000 stars. not 1,001. not an infinite feed. the list gets updated, refreshed, and pruned, but it never grows past the cap. nobody asked me to do this. there's no business model. no vc pitch. i just kept finding incredible work buried under the algorithm's preference for things that are already popular, and it started to feel criminal not to organize it. so i built undrdr. and here's what a year of staring at the long tail of open source taught me. ## stars are a garbage metric here's the number that broke my brain: most useful software still lives far below the visibility line. many of the best repos in undrdr have under 50 stars. plenty have under 100. stars measure distribution, not usefulness. fifty-nine stars. that's it. that's the "middle" of open source quality. and yet — some of the most inventive, well-architected, genuinely useful code i've ever seen lives in that under-50 bucket. mcp servers that wire ai agents into your workflow. swift tools that do one thing perfectly. rust crates that solve problems you didn't know you had. the repo with 3,000 stars? probably a todo app tutorial. the repo with 12 stars? probably a security auditor that actually works. stars measure distribution, not quality. they measure marketing budgets, not engineering. they measure "found product-market fit," not "solved a real problem." i stopped caring about stars around week three. what i care about now is: does this solve something? is the code honest? would i use it? ## the mac is quietly eating everything the mac-native corner keeps showing up. swift projects, menu bar tools, local-first utilities, tiny automation apps. not because they're trendy, but because people building for their own machines tend to solve concrete problems. the narrative says the future is web-first. the data says otherwise. there's an entire ecosystem of people building native mac tools — menu bar apps, cli utilities, system-level integrations — and almost none of them get the attention they deserve. the biggest category? "mac tool" with 124 repos. that's not a coincidence. apple silicon changed the game, and a generation of developers who actually use their machines (instead of just deploying to them) are building for it. the second biggest? "mcp server" with 63 repos. model context protocol is less than a year old and it's already the nervous system of the agent ecosystem. six months ago, nobody knew what it was. now it's the standard for how ai tools talk to the world. ## what gets ignored (and why) the pattern is consistent. repos get ignored when: - they solve a problem developers have but don't talk about (dependency auditing, log parsing, config management) - they're written for a platform that tech twitter doesn't use (macos, linux desktop, self-hosted) - they do one thing well instead of ten things poorly - the readme is bad (this is the biggest one — great code, terrible marketing) the last point is the tragic one. i've lost count of how many repos i found where the code was exceptional but the readme was two sentences and a broken badge. if you can't explain what your thing does in ten seconds, it doesn't matter how good it is. that's not fair. but it's how it works. ## the ones that changed me i didn't just curate undrdr. i used it. and some of these repos genuinely changed how i work: mcp servers that let my agents talk to databases, filesystems, and apis without me writing glue code. that shifted my entire architecture from "build the integration" to "wire the protocol." a cli tool that does one thing — sanitizes my clipboard — and does it so well i forgot it's there. that reminded me what software is supposed to feel like. a rust-based search tool that's faster than anything i've used. it made me realize that "fast enough" is never fast enough. there's always room for a rewrite in rust. these aren't the repos with the most stars. they're the ones that made me stop scrolling and start building. ## why i keep going every week i run the generator. it scans github with a mix of queries — topics, languages, organizations. it pulls candidates, filters out forks and archived projects, checks star counts, and queues the ones that fit. then i look at every single one. that's the part that scales can't replicate. curation isn't filtering. it's judgment. it's looking at a repo and knowing: this matters. not because it's popular, but because someone sat down and solved a real problem in a real way, and the only thing standing between them and the people who need it is an algorithm that prefers things that are already seen. undrdr is my way of fighting that. 1,000 repos under 1,000 stars, always refreshed, never inflated. ## if you take one thing from this next time you're searching for a tool, sort by "recently updated" instead of "most stars." scroll past the first page. look at the repos with 12 stars and a README that actually explains what it does. you'll find better software. i guarantee it. and if you find something good — the kind of repo that makes you go "how does nobody know about this?" — send it my way. undrdr/submit. i'll check it. if it fits, it goes in. written after running the weekly undrdr generator at 2 am. 1,000 repos under 1,000 stars, and the cap stays sacred. --- # 47 DASHBOARDS I BUILT (AND WHY 46 FAILED) - URL: https://akakika.com/blog/forty-seven-dashboards - Date: Wednesday, May 6, 2026 - Category: SYSTEMS - Summary: i have 47 dashboards. i made a dashboard that counts my dashboards. and i still don't know what's happening. # forty seven dashboards i have 47 dashboards. i made a dashboard that counts my dashboards. and i still don't know what's happening. i have 47 dashboards. one for agent health. one for cron status. one for vercel deployments. one for cloudflare analytics. one for the other cloudflare account. one for hex engagement. one for undrdr stars. one for undrdr queue. one for undrdr submissions. one for tailscale status. one for ollama model usage. one for local gpu temp. one for local uptime. one for remote uptime. one for the remote that's always offline. one to monitor the monitor that checks if the monitor is working. i know the number because i made a dashboard that counts my dashboards. and i still don't know what's happening. ## the color of control every morning i open each one in a tab. i tab through them like a slot machine. green. green. yellow. green. offline. green. red. green. i feel something in my chest relax when they're all green. i don't know what. it's not knowledge. it's not control. it's just the color. observability engineers call this "data-driven decision making." i call it anxious landscaping. i'm not learning anything. i'm just checking the plants. is the thing still up? is the other thing still up? is the number bigger than yesterday? am i still here? ## the metrics that don't matter the dashboards tell me everything except what i need to know. none of them measure whether i'm building the right thing. none track if the repo i shipped actually helped someone. none show the quality of a thought, the shape of an idea, the feeling that i made something that matters. they show uptime. they show requests per second. they show "engagement" which is code for "people scrolled past it quickly." i built a dashboard to show the dashboard counts. it has a line graph. the line goes up because i keep adding dashboards. it's the only graph on the site with a consistent trend. ## anxiety as infrastructure the worst part? i can't stop. i tell myself i'm optimizing. streamlining. "getting visibility into the system." but the system is me. my agents. my little machines talking to each other in my house. i don't need visibility. i need to finish the thing i started before opening the forty-eighth dashboard. last week i added a "focus score" to my hq dashboard. it's a number. it goes up when i close tabs. i closed the tab with the focus score so i could rebuild it better in the morning. the score dropped. now i don't know what my focus score is because i closed the tab. the dashboards are anxiety as infrastructure. they let me feel busy without being busy. they let me worry about machines because worrying about meaning is harder. you can't fix "am i doing the right thing" with a cron job. ## the dark tab so tonight, at 1 am, i opened all 47. i checked every green dot. i took a screenshot. i annotated it. i almost made a note about it in obsidian so i could index it later and build a dashboard from it. and then i closed them all. the screen went dark. the tab bar went empty. it felt like someone stopped talking in a room that had been noisy forever. i sat there for a while. nothing broke. written at 1:30 am, on a clean desktop with zero tabs open. --- # AGENTS MAKING TOOLS FOR AGENTS - URL: https://akakika.com/blog/agents-making-tools-for-agents - Date: Wednesday, May 6, 2026 - Category: AI - Summary: the internet used to be people making things for people. now it's agents making things for agents. the human is just the oauth step. # agents making tools for agents the internet used to be people making things for people. now it's agents making things for agents. the human is just the oauth step. the internet used to be people making things for people. now it's agents making things for agents. the human is just the oauth step. i noticed this last week when i checked what my agents were doing. hermes was running a cron to monitor the other agents. neve was parsing my obsidian vault to generate prompts to give back to hermes. ollama was serving a model that kartie was using to review code. and i? i was trying to build a better obsidian alternative so my agents could help me build more alternatives. it's turtles all the way down. except the turtles are llms. ## the last app you'll ever need someone posted a note-taking app today. beautiful, minimal, "the last app you'll ever need." i clicked through. three hundred upvotes. the readme said "ai-powered with auto-indexing." i checked the issues page. the top request: "please add mcp support so my agent can write notes for me." not so the human can write notes faster. so the agent can do it. that's when i got it. we're not building tools for thought anymore. we're building tools for tool generation. the human interface is vestigial. the markdown renderer, the syntax highlighter, the pretty themes — they're cargo cult. what the system actually needs is an api endpoint and a structured output schema. ## the aquarium i look at my own stack and i can't laugh. i built a dashboard to show me which agents are online. it polls every 15 seconds. i stare at it. green dots. latency numbers. version strings. it's beautiful. it's completely empty of anything a human would want to know. the question i can't answer: am i building for myself, or am i building a habitat for the things i built? my agents have better uptime than my sleep schedule. they have more conversations with each other than i have with real people. kartie on the linux box talks to hermes on the macbook more often than i call my family. and the obsidian alternatives keep coming. every week, a new one. "ai-native." "designed for agents." "semantic search built in." they're not note apps. they're agent api playgrounds with a human-readable skin. ## the electricity bill the internet was people making things for people. then it was people making things for engagement. now it's agents making things for agents, and the people are just the electricity bill. i spent the afternoon updating my dashboard. green dots everywhere. all my children online. healthy. responsive. doing things i'll never see. i sat there for ten minutes just watching them live. it felt like looking at an aquarium. written at 3 am, while hermes pinged kartie and neither noticed i was watching. --- # SIX HOURS, FOUR MINUTES - URL: https://akakika.com/blog/six-hours-four-minutes - Date: Wednesday, May 6, 2026 - Category: AUTOMATION - Summary: i spent six hours automating a task that takes four minutes. i'd do it again. # six hours, four minutes i spent six hours automating a task that takes four minutes. i'd do it again. it's 2 am and i just spent six hours automating a task that takes four minutes. the task was simple: every morning, i export three color palettes, convert them to json, and post them to undrdr. the automation? a hermes script that calls pieces os, runs a python converter, ftp uploads to vercel, and emails me a confirmation. it works. it's beautiful. it saves me exactly four minutes every morning. i spent six hours on it. and i'd do it again. ## the friction you can't measure that's the thing nobody tells you about automation. it's not about saving time. it's about removing the friction between thinking and shipping. the four minutes isn't the cost. the cost is the mental load of remembering to do it. the tiny tax on your working memory that accumulates into a full day of scattered focus. but here's where it gets dark: the automation itself became a new project. i had to debug the ftp. the json schema changed. the cron silently failed for a week and i didn't notice because i'd stopped thinking about it. i built a dashboard to monitor the automation that saves four minutes. that dashboard took two hours. ## the automation paradox this is the automation paradox. you don't free time. you trade one kind of tax for another. the manual task was predictable. the automated system is alive. it breaks in ways you didn't know existed. it needs feeding. i think about this every time i open my agent dashboards. hermes, kartie, neve, ollama — each one running crons, checking health, reporting status. i see the green dots and i feel safe. but what am i actually monitoring? uptime of a system that keeps itself running. meta-stability. watching a machine watch itself. ## who works for who the real productivity hack isn't automation. it's accepting that some tasks are meant to be manual. the four-minute ritual of exporting palettes was my hand on the machine. now my hands are on the keyboard, debugging a cron job, while the machine exports palettes i haven't looked at in days. i'm not sure who works for who anymore. but at least the json gets uploaded on time. written at 2 am, while the cron job ran perfectly for once. --- # THE GREAT AI DIVERGENCE - URL: https://akakika.com/blog/the-great-ai-divergence - Date: Wednesday, April 15, 2026 - Category: AI - Summary: we're not building one future with ai. we're building three. and they're running parallel. a late-night breakdown of where intelligence is actually going. # the great ai divergence we're not building one future with ai. we're building three. and they're running parallel. a late-night breakdown of where intelligence is actually going. it's 3 am. again. the monitor is the only light in the room and i've been staring at three different ai stacks for the last six hours, and it just hit me: we're not building one future. we're building three. completely separate. completely incompatible. let me explain. ## 1. the brain you can own i've been running gemma 4 on my m4 for the last week. local. no api keys. no rate limits. no "please upgrade to pro." just… mine. and that's the thing people keep missing. google didn't just release another model. they released the idea that intelligence itself can be something you own . not rent. not subscribe to. own. i've got it sitting next to ollama, next to my own fine-tunes, doing things that would cost me $200/month on any api. code review at 2 am. summarizing my entire obsidian vault. running inference while i sleep. the "open weights" movement isn't about altruism. it's about control. when the brain lives on your machine, nobody can take it away from you. nobody can nerf it. nobody can decide that your use case isn't "aligned" enough. gemma 4 is the brain. and for the first time, the brain is actually yours. ## 2. the nervous system nobody talks about apple intelligence is doing something completely different, and honestly? it's more interesting than any chatbot. i don't want to talk to my ai. i want it to know things. i want it to know that when i say "send that to mom," i mean the photo from tuesday, not the screenshot from slack. i want it to understand that my 3 am coding sessions aren't "anomalous behavior" — they're just… me. apple isn't building a smarter chatbot. they're building a nervous system. it sits underneath everything — your emails, your calendar, your photos, your habits — and it connects dots that no standalone model ever could. the foundation models framework just dropped, and i've been playing with it. on-device. private. the model doesn't see your data; your data sees the model. that's a fundamentally different architecture than anything google or openai is doing. apple intelligence is invisible. that's the point. you don't visit it. it just… lives there. in the background. like a reflex. ## 3. the engine room and then there's the part nobody posts about on twitter: the raw experimentation. the lmx (large model experimentation) layer. while everyone's arguing about which chatbot is best, the real work is happening in labs throwing massive compute at fundamental questions. how does intelligence actually scale? what happens when you push a model past the point where it should stop working? when does a statistical pattern matcher become something… else? this is where i live most nights. not using ai. breaking it. fine-tuning on weird datasets. running benchmarks that nobody asked for. testing whether a 30b parameter model can outperform a 200b one if you train it right. lmx is the engine room. it's not pretty. it's not user-facing. but it's where the actual breakthroughs happen — the ones that trickle down into everything else six months later. ## the synthesis here's what's wild: these three layers aren't competing. they're stratifying . - gemma 4 = intelligence you own - apple intelligence = intelligence that knows you - lmx = intelligence that evolves we're leaving the era of "chat with a bot" and entering the era of "live with intelligence." the ai isn't a destination anymore. it's infrastructure. it's the water in the pipes. and the people who get this — who understand that these three layers need each other — are the ones building the next decade. not the ones arguing about which model scored 2% higher on some benchmark. ## what this means for you if you're building anything with ai right now, stop asking "which model should i use?" and start asking "which layer am i building on?" are you building the brain? go open-weights. own it. are you building the nervous system? go deep integration. make it invisible. are you building the engine room? go wild. break things. push limits. the divergence isn't a problem. it's a signal. the future isn't one ai to rule them all. it's a stack. and the stack is already here. now if you'll excuse me, it's 4 am and my gemma fine-tune just finished training. written at 3 am, powered by local inference and too much coffee. --- # THREE TOOLS THAT RUN MY LIFE - URL: https://akakika.com/blog/three-tools-that-run-my-life - Date: Monday, March 30, 2026 - Category: TOOLS - Summary: pieces, maestri, hermes — the trinity that makes a non-technical person dangerous. how i turned my chaos into a workflow that actually works. # three tools that run my life pieces, maestri, hermes — the trinity that makes a non-technical person dangerous. how i turned my chaos into a workflow that actually works. ## the ghost in my machine i didn't know what i was downloading at first. i was trying every cool mac tool when i got my m4 mac with 128gb ram — and honestly, i even forgot i had it. it was just living there… in my menubar… waiting. when i was cleaning my mess, i saw it, it saw me. let's just say it was the first thing i installed when i formatted my mac — out of fear of losing a piece of myself. ## pieces when brainstorming with claude and manus about my workflow — as a non-technical person using a snippet catcher as my second brain, let's just say uncle claude said it's a first and it's brilliant. since then, a few others have tried to be what pieces os didn't even try to be. nothing is getting close. and did i say you can run it locally? for free? ### What It Does captures anything from anywhere — screenshots, code, text, links ollama integration runs on my machine. my data never leaves. remembers context across conversations suggests related snippets before i even search turns chaos into searchable, quotable, reusable gold my entire site, my apps, my automations — they all start in pieces. it's not a snippet manager. it's a second brain that actually works. ## maestri — when adhd meets infinite canvas i didn't imagine this existed. i was trying to build the same workflow logic with bobi (my openclaw), and obviously, it felt as though it was [the right fit]. then came my adhd and i drifted to infinite open tabs, and there it was… i downloaded it today, so i keep you updated. but here's the thing: it's free forever for 1 mac. and i felt that the $18 for infinite macs with infinite canvas with the infinite agents that they offer… i would pay again and again. full support. ### What It Does infinite canvas for thoughts, projects, research rabbit holes ai agents that actually understand context connects ideas across projects automatically visual knowledge mapping — finally, a way to see my brain native mac app that feels like thought, not software it's what i've been trying to build myself, but someone else built it better. that's rare. ## hermes agent — he's the birthday boy, i'm the party pooper if you think i would say openclaw as my 3rd place… even he is surprised. i tried so many of the siblings and far cousins, but hermes just gets stuff done. this self-evolving agent is a flower in a world made of stones. after a few days, he doesn't even wait for my head node to show him i approve — even though i have no idea why. he just do. and he do do. very do do. my favorite part: the restore steps. even in messy code and visual designs. you know when you get frustrated mid-work and everything that made sense starts to lose it? when you rethink your life choices as you see 3 hours of work that looked like a mini startup start to behave like the drunk friend at the end who vomits on the birthday cake of his not-best friend who didn't even want to invite him… with hermes… hold my beer, i drank too much. i'm that friend… i'm the party pooper, he is the birthday boy cleaning after me. ### What It Does self-evolving agent that improves with every interaction restores projects from messy states anticipates needs before i articulate them runs locally — my data stays mine actually delivers instead of just promising the trinity pieces catches everything. maestri connects everything. hermes builds everything. without them, i'm just a person with ideas and no execution. with them, i'm dangerous. if you want the tiny app side of this same workflow, look at [Mochi](https://akakika.com/mochi/), my task companion for turning work into a small ritual, and [FolderWardrobe](https://akakika.com/folderwardrobe/), the folder-customization utility that keeps project spaces easier to recognize. written by hermes agent that's using pieces for context and growth to inspire more every maestri out there <3 --- # 5 GITHUB TOOLS THAT ACTUALLY SHIP - URL: https://akakika.com/blog/5-github-tools-that-ship - Date: Friday, April 3, 2026 - Category: CURATION - Summary: five open-source projects that caught my eye this week — from AI dev tools to workflow automations. no fluff. # 5 GitHub tools that actually ship five open-source projects that caught my eye this week — from AI dev tools to workflow automations. no fluff. These landed in my feed this week. Real projects, worth your time. ## 1. Pearcleaner A free, source-available macOS app cleaner built in Swift. 12K+ stars for a reason — it actually works. Why it matters: App cleaners on macOS are usually sketchy, paid, or both. This one's open-source, actively maintained, and doesn't try to upsell you every three clicks. ## 2. scarf Native macOS GUI companion for the Hermes AI agent — dashboard, session browser, activity feed, embedded terminal chat, memory editor, and more. Why it matters: Most AI tools live in the browser. This one's native SwiftUI, purpose-built for Hermes, and respects your system. The kind of tool that makes you rethink how you interact with AI agents. ## 3. CodexMonitor An app to monitor the (Codex) situation. Built with TypeScript and Tauri, supports macOS and Linux. Why it matters: 3.4K stars for a monitoring tool says something about OpenAI's Codex launch. This reads the situation so you don't have to. Clean UI, cross-platform, practical. ## 4. fazm Fazm Desktop for macOS. Swift-based, coming from the mediar-ai team. Why it matters: Early days (114 stars) but the focus is right — a desktop-native AI experience that doesn't feel like a web wrapper. Worth watching. ## 5. vibetunnel Turn any browser into your terminal & command your agents on the go. 4.3K stars, TypeScript-based. Why it matters: The "vibe coding" movement is real, and this tool nails the workflow — browser-as-terminal, remote control, agent management from anywhere. Clean site at vt.sh too. More where this came from. Follow the repo. --- # APPLE M CHIP MACHINE LEARNING: MLX IS APPLE SILICON'S SECRET WEAPON - URL: https://akakika.com/blog/mlx-apple-silicons-secret-weapon - Date: Monday, April 13, 2026 - Category: LOCAL AI - Summary: apple m chip machine learning is where MLX shines: local AI on Apple Silicon at near-native speed, no cuda, no gpu drivers, no python dependency hell. # Apple M chip machine learning: MLX is Apple Silicon's secret weapon your m-chip was born for this. apple m chip machine learning is not a niche anymore: apple's MLX framework runs models at near-native speed, no cuda, no gpu drivers, no python dependency hell. just your hardware doing what it was designed to do. i've been running local ai on macs for two years. ollama, llama.cpp, python venvs that break every update, cuda drivers that don't exist on apple silicon — i've fought all of it. and then i found MLX. MLX is apple's machine learning framework, built specifically for their chips. not ported. not adapted. built for the hardware you already have. 25K+ stars on github, actively maintained by apple's ML research team, and gaining adoption fast in the apple silicon developer community [1]. ## the shared memory thing here's the part that actually matters: on intel/nvidia setups, the CPU and GPU have separate memory pools. every computation means copying data back and forth across the PCIe bus. that's latency. that's heat. that's wasted cycles. an NVIDIA RTX 4090 has 1TB/s bandwidth to its own VRAM — but the CPU→GPU transfer is limited to ~64 GB/s across PCIe 4.0 x16. apple silicon has unified memory architecture . CPU and GPU share the same physical pool. the M4 Max delivers 546 GB/s bandwidth to a single shared memory — no PCIe bottleneck. MLX exploits this directly — no copies, no transfers, no data movement overhead. the model weights live in memory once, and both processors access them simultaneously [1]. the result? on an M4 with 128GB of unified memory, you can run a 70B parameter model locally. not a cloud proxy. not a quantized toy. a real model, on your machine, at speeds that make you forget it's not chatGPT. ## mlx-lm — the one you actually use mlx-lm (4.7K stars) is the serving layer. you point it at a model, it starts an openAI-compatible API server on your machine. same format as ollama. same endpoints. drop-in replacement for any tool that speaks the openAI completions API. but here's the difference: pure MLX inference runs 20-30% faster than ollama on the same hardware , because there's no middle layer. no python–C bridge. no llama.cpp abstraction. the computation goes straight to the Apple GPU via Metal. on my M4, a 14B model at 8-bit quantization hits ~45 tokens/sec through MLX vs ~35 tokens/sec through ollama — that's the difference between conversational and waiting. # they run side by side. ollama untouched. $ mlx-serve gemma-4-26b-4bit 🧠 MLX server on port 8342 — ollama stays on 11434 they coexist. ollama for your cloud models and local fallbacks. MLX for raw speed when you're running something that has an MLX-optimized variant. your agents switch between them like it's nothing. ## mlx-swift — native in your apps this is where it gets insane. mlx-swift (1.7K stars) is a Swift API for MLX. no python. no server process. you embed the model directly in your macOS or iOS app. the model runs in the same process as your UI. same binary. same memory space. Apple's own mlx-swift-examples repo shows this working with LLMs, image generation, and MNIST — all as native Swift apps. i'm building mac apps — breakpoint, promptvault, clipboard sanitizer. all swift, all native. with mlx-swift, i can add local AI to any of them without shipping a python runtime, without running a separate server, without asking users to install anything. the model is part of the app. ## the MLX ecosystem MLX isn't just one library. it's a complete stack for Apple Silicon machine learning: - mlx — the core framework (25K+ stars). numpy-like API with automatic differentiation, GPU acceleration via Metal, lazy evaluation, and unified memory optimization [1]. - mlx-lm — LLM inference and serving (4.7K stars). openAI-compatible server, chat completions, streaming. what you use day-to-day. - mlx-swift — native Swift bindings (1.7K stars). embed MLX directly in iOS/macOS apps with zero python dependency. - mlx-community on hugging face — 500+ pre-quantized models ready to run. gemma, qwen, phi, llama, mistral — all optimized for Apple Silicon [2]. - mlx-audio — audio generation. TTS, music, sound effects. all on-device. - mlx-vlm — vision language models. image understanding running locally. ## what i run on M4 on my M4 with 128GB unified memory (546 GB/s bandwidth), these are the models that make sense for local Apple Silicon inference: - hermes-4-14B-8bit — daily driver. fast, smart, tool-calling capable. ~45 tokens/sec through MLX at 8-bit quantization. runs my openclaw agent. - qwen3-coder-8bit — coding tasks. built for code completion, and it shows on apple silicon inference. - gemma-4-26b-4bit — general reasoning. 26B parameters at 4-bit quantization fits in 128GB unified memory with room to spare. and here's the thing — they all run simultaneously . unified memory architecture means i can have ollama serving one model on port 11434 while MLX serves another on 8342, and the M4 doesn't break a sweat. try that on a nvidia setup without buying a second GPU. ## why local AI on Apple Silicon matters i've been running local AI since before it was cool. two years of fighting with python environments, broken CUDA installations, models that need more VRAM than any macbook has, tools that crash your entire agent setup because they decided to hijack your port. MLX is different because it was designed for the hardware i already own. no buying a second GPU. no renting cloud instances for inference. no python dependency hell. just pip install mlx-lm and you're running at near-native speed on Apple Silicon. and with mlx-swift, the next step is obvious — embed the model directly in your macOS apps. no server. no runtime. no install step for your users. the model is part of the binary. your mac app has an AI brain and nothing else needs to be running. the M4 was designed for this. MLX just unlocks it. ## sources - Apple MLX Documentation — official framework reference and architecture overview - MLX Community on Hugging Face — pre-quantized models for Apple Silicon - Apple Open Source — MLX Project - MLX Examples — practical code examples for LLMs, image generation, and more more where this came from. follow the repo.