For me it's a combination of privacy and wanting to be able to experiment as much as I want without limits. I'd happily take something that is 80% as good as SOTA but I can run it locally 24/7. I don't think there's anything out there yet that would 100% obviate my desire to at least occasionally fall back to e.g. Claude, but I think most of it could be done locally if I had infinite tokens to throw at it.

What operating system are you using? I was looking at this exact machine as a potential next upgrade.

> That means the code is sketchy sometimes, sure, but it's in my control. I wrote it, I understand it, and when it breaks, I know exactly where to look.

This resonates with me so hard. I'm not a "no external packages" purist, but there are a number of pieces of functionality that I wrote for myself because there wasn't anything quite like what I wanted.

One example is a function to expand the region (selection) to any arbitrary set of pairing delimiters that I define in a defvar (parens, quotes, brackets, or I can can supply a custom left/right regex for matching). Then, when I execute the function, it waits for a second keypress, which is the trigger key I've defined for that matching pair, and it will expand the region to the left and the right until it meets the applicable delimiter.

Repeating the same key presses results in selecting the left and right delimiters themselves, and another repeat will extend to the next set of matching delimiters, and so on.

Even though I use a treesitter-based expand-region plug-in, my custom function is still invaluable for when I want to jump past a series of valid treesitter object expansions, or when certain text objects are just not defined in treesitter.

Some of the helpful custom expansions I have defined are:

"w" to select what Vim considers a lowercase-w word

Space to select what Vim considers an uppercase-W word

"$" to select ${...}-style expressions

"/" to select everything between forward slashes

"*" to select between asterisks (useful when editing markdown)

It's really an invaluable function for me, personally, but I always talk myself out of trying to open-source it because it has some gotchas and limitations, and I just don't want to be on the hook for trying to make everyone who uses it happy.

Don't anthropomorphize the lawnmower.

Matchlock[0] is probably the best solution I've come across so far WRT problem 1 and 2:

> Matchlock is a CLI tool for running AI agents in ephemeral microVMs - with network allowlisting, secret injection via MITM proxy, and VM-level isolation. Your secrets never enter the VM.

In a nutshell, it solves problem #2 through a combination of a network allowlist and secret masking/injection on a per-host basis. Secrets are never actually exposed inside the sandbox. A placeholder string is used inside the sandbox, and the mitm proxy layer replaces the placeholder string with the actual secret key outside of the sandbox before sending the request along to its original destination.

Furthermore, because secrets are available to the sandbox only on a per-host basis, you can specify that you want to share OPENAI_API_KEY only with api.openai.com, and that is the only host for which the placeholder string will be replaced with the actual secret value.

edit to actually add the link

[0] https://github.com/jingkaihe/matchlock