mindfork mindfork

~/mindfork/articles

Articles

Longer-form writing about mindfork: architecture, decisions, and how it is built.

  • mindfork at a glance

    The shape of the app: an engine contract over OpenAI-compatible servers, a client-side agentic loop, one turn from start to finish, layered memory, boring durable storage — and where the trust boundaries are.

  • Why the engine is a server, not a library

    mindfork nearly embedded an inference runtime. The contract that replaced it made a local GGUF and a cloud frontier model the same thing.

  • The self-model: a memory that knows it changed

    Each companion keeps a model of itself and of you — a summary, goals, traits and dated observations — and maintains it with its own tools, on your disk.

  • Where vector search earns its keep

    One small embedding server powers the knowledge base, large attachments, notes and memory — and the app notices when you swap the model under it.

  • The same answer, sooner

    FlashAttention and speculative decoding in managed mode: two llama.cpp levers that change how fast tokens arrive — without trading away the answer.

  • Why the Python sandbox is WebAssembly, not Docker

    python_exec runs model-written code in a CPython compiled to WebAssembly — numpy, pandas and requests included — inside a box that ships with the app and, by default, cannot see your machine.

  • Where the trust boundaries are

    An assistant that can browse, run code and edit your project needs edges, not promises: what leaves the machine, where the model may not point, what the code can touch, when the app asks — and what the author receives, which is nothing.

  • The code workspace: containment before capability

    A project attached to a chat: what the assistant can read, edit and run there, why the commands are only ever yours, how every change is a diff with a way back — and the semantic index that was measured and did not ship.

  • Background runs, and the pool they share

    A subagent that outlives its round, the app's own quiet requests, and one local llama-server with one context pool under all of them: what the server does when the pool overflows, how the app keeps it from happening, and what parallel sessions actually buy on one GPU.