DEV Community: Reno Lu

OpenKnowledge points your editor and your agents at the same folder

Reno Lu — Thu, 03 Sep 2026 16:45:18 +0000

Most tools that offer to organize your knowledge start by asking you to move it. OpenKnowledge starts by asking for a folder path. You open a directory that already contains markdown or mdx files, and that directory stays where it is, in whatever shape it already had.

That sounds like a small design choice until you look at what it rules out. No import wizard. No proprietary block format. No database that quietly becomes the real source of truth while the exported files rot. The README names the targets it expects you to point at: existing codebases, wikis, Obsidian vaults. Your repo's docs directory qualifies. So does the pile of meeting notes you have been dragging between text editors for years.

Editing markdown without feeling the markdown

The editing surface is billed as full true WYSIWYG, with the stated goal that working on a markdown file feels like working in a Google Doc or a Notion page. The README's own shorthand for the whole thing is Notion meets VS Code, which is a fair summary of the tension it is trying to resolve. Plain text files win on portability and lose on the writing experience, and most teams have quietly accepted that trade for a decade.

Around the editor sit the things you would expect from an IDE rather than a notes app: file navigator, search, tabs, and a graph viewer for wiki links. There is also support for embeddable HTML and rich components, aimed at engineering specs and visualized reports, which is the category of document where raw markdown usually gives up and people move to a hosted doc tool.

The install step that carries the weight

The interesting command is not the one that opens the editor. It is ok init.

npm install -g @inkeep/open-knowledge
cd your-project
ok init
ok start

ok init scaffolds the project and wires up the AI editors it detects on your machine. The README lists Claude Code, Claude Desktop, Cursor, Codex, OpenCode, and OpenClaw. What it installs is MCP and skills, described as designed to give agents enriched search and authoring of documents rather than whatever they would manage on their own against a directory tree.

Read that alongside the folder-first decision and the architecture gets clear. The editor is the human view of the files. MCP is the agent view of the same files. Neither one owns the data, and there is no sync problem between them because there is nothing to sync. Side-by-side AI editing is listed for Claude, Codex, OpenCode, and Pi, with any other harness reachable through MCP or the CLI.

This is the part worth stealing even if you never install the app. Teams keep building agent context layers that duplicate content into a vector store, then spend the next quarter reconciling drift. Pointing the agent at the same bytes the human edits removes an entire class of failure.

Sharing without a sharing service

Team sharing and auto-sync are described as no-code, powered by git and GitHub underneath, and they are optional. You can run the whole thing without touching them.

That framing matters for the privacy claim. The project describes itself as private, local, and free, and the sync story is consistent with that rather than working against it. Collaboration is a repo you already know how to audit, revert, and back up, not a hosted workspace with its own permission model to learn.

Practical notes before you try it

The desktop app covers macOS on Apple Silicon, Windows 10 and up on x64 or Arm64 with a per-user installer and no admin prompt, and Linux via deb or rpm. Intel Macs and servers go through the web app path instead, which runs the same editor locally and needs Node.js 24 or newer plus git.

The license is GPL-3.0 or later, which is fine for using the app and worth a closer look if you were planning to build on the code. The repo lives at inkeep/open-knowledge, and the project takes public pull requests and issues.

If you have been waiting for a reason to stop pasting documentation into a chat window, the wiring is the reason. The files are already there.

GitHub: https://github.com/inkeep/open-knowledge

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

LoopX Holds the State Your Agent Harness Forgets

Reno Lu — Wed, 02 Sep 2026 16:55:23 +0000

The most consequential line in the LoopX README is a disclaimer: "LoopX is not an autonomous production controller." Dangerous permissions, publishing, production writes, and final ownership stay with the human. For a project whose whole subject is agents that run for days, that is a real constraint, and the rest of the repo is built to honor it.

The problem is the gap between turns

LoopX starts from an observation most agent tooling skirts. A single session can finish a task. Long-running work breaks somewhere else: objectives shift, an owner decision shows up mid-stream, evidence goes stale, one agent hands work to a peer, and a scheduler keeps burning turns after there is nothing useful left to transition to. The README's phrasing is blunt about the usual answer. Chat memory and a timer are not enough to govern that.

So LoopX does not try to be the thing that executes. It calls itself a lightweight state kernel and a local-first control plane, running on top of Codex App, Claude Code, Cursor, dsh, or a harness you wrote yourself. The harness executes one bounded turn. LoopX holds the objective, the gates, the todos, the scope, the evidence, and the quota, then decides what happens next. Stated plainly in the docs: not another agent framework, not a provider-specific orchestration runtime.

The control flow diagram is short enough to read in one pass. State comes in. If human judgment is needed, the loop asks a concrete question and waits. If a safe fallback exists, it runs one bounded agent slice. The runtime takes its turn, writes evidence, a handoff, and the next todo, and quota decides whether there is another tick.

That waiting step is the part worth stealing even if you never install this. Most loops fail open. This one is designed to stop and ask.

An agent-native Kanban, with the board demoted

The mental model the docs offer is a Kanban board for long-running work, but with a twist: cards carry identity, authority, evidence, and continuation, and moves are validated operators such as claim, gate, monitor, and writeback. The board is a projection. LoopX state stays the source of truth.

The same rule governs the workspace UI. loopx dashboard launches a browser or PWA surface where you can see what needs you, what is running, what is being watched, and what is scheduled or stopped, then continue across Codex, Claude Code, or direct-model sessions without losing Goal state. Protected changes go through typed preview, explicit confirmation, and receipts. The README is careful to note that LoopX state, not the browser, remains authoritative. The experimental Tauri desktop shell gets the same treatment: it reuses the loopback status and Chat services rather than becoming a second state authority, and closing the window stops only what the shell itself started.

Registered agents are peers. Claims, leases, task boundaries, capabilities, and typed continuation decide who acts next. No durable leader identity required.

Evidence with the caveats attached

The showcase section is where the project's temperament shows clearest. Two arcs, a public OpenViking contribution sequence and a redacted owner-run Auto ML experiment, each span more than 200 hours of elapsed loop lifetime. The README immediately defines the term: elapsed lifetime is wall-clock project time, not 200 hours of continuous model execution, and not a claim of unattended production autonomy. The ML graph is labeled an owner-run showcase, not a reproduction, not a production result, not an employer endorsement.

The third case, Auto Research, is the reproducible one. Proposer, executor, and evaluator/promoter agents iterate in parallel over a built-in exact-KNN demo whose task definition, editable and protected files, deterministic CPU evaluator, and dev/held-out commands all ship in the repository. Even there the README calls it a demo result.

Independent user reports carry the same labeling: a C++ accuracy run past the thirteen-hour mark, a four-day unattended run, seven merged PRs on a public engine refactor with the reported token scale marked as a user claim rather than a measurement.

Fitting this to your own work is a short test. If your agents finish inside one session, skip it. If you run multi-day objectives, issue and PR loops that must preserve scope and review state, gates for safety or publication or private data, or peer agents that need leases and handoffs, this is the layer that has been missing.

GitHub: https://github.com/huangruiteng/loopx

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

LazyCodex Bets That Installation Is the Hard Part of an Agent Harness

Reno Lu — Tue, 01 Sep 2026 17:03:47 +0000

LazyCodex ships almost none of the agent behavior it advertises. The engine, OmO, sits under src/ as a git submodule. What the repository itself holds is a distribution layer, a Next.js site, and two CI workflows. That split is the interesting part. Someone looked at a working agent harness and concluded the remaining hard problem was not the agents. It was getting them installed, verified, and cleanly removed on a machine nobody on the project has ever seen.

Installation is treated as a first-class feature

The primary path is one line, and the README is insistent about it: npx lazycodex-ai install, no global install, no npm i -g. That command expands to npx --yes --package oh-my-openagent omo install --platform=codex. If you want the version that never stops to ask, --no-tui --codex-autonomous gives you an unattended setup. Note where that flag lives. The newer marketplace route, adding the repo as a marketplace inside Codex and installing omo@sisyphuslabs, never touches Codex permission settings. Autonomous mode stays something you type on purpose.

The marketplace path also documents its own awkwardness, which is rarer than it should be. Hooks do not run until you approve them in Codex's startup review. The first approved session prints a notice that bootstrap is running in the background and that you should restart when it completes, because a worker is still writing config blocks, agent roles, bin links, and a pinned sg binary for the ast_grep MCP. After an upgrade, that same startup review shows the hooks as Modified, which the README calls expected rather than leaving you to wonder what got tampered with.

Then there is npx lazycodex-ai doctor, which prints a health report across plugin cache, hooks, MCP servers, agents, and config state. Uninstall is equally specific: plugin cache, bin links, agent roles, and the managed sections of ~/.codex/config.toml. A tool that names the exact regions of your dotfiles it claims ownership of is a tool you can let near them.

Three commands, then a drawer of skills

The command surface stays small. $ulw-plan writes a plan to plans/<slug>.md and never writes product code, so planning cannot quietly turn into a half-finished implementation. $start-work executes that plan until every checkbox is done and prints ORCHESTRATION COMPLETE. $ulw-loop runs a self-referential loop until an Oracle verification passes, capped at 500 iterations in ultrawork mode and 100 in normal mode. Those caps are the honest detail. Anyone who has watched an agent loop knows the failure mode is not stopping too early.

Below the commands sits a skill layer you reach by typing $ in the Codex composer. $init-deep scores complex directories and writes hierarchical AGENTS.md files near the code that needs them, so future agents get landmarks before they start editing. Others cover narrower ground: LSP for diagnostics, definitions, references and renames, AST-grep for structural search and rewrite, review-work for post-implementation review, remove-ai-slops for behavior-preserving cleanup of code that reads like it was generated.

Sub-agent roles get installed into ~/.codex/agents/ as explorer, librarian, plan, momus, metis, and codex-ultrawork-reviewer. You pick one by passing agent_type to Codex's own spawn_agent tool. The installer exposes that parameter on multi_agent_v2 sessions because Codex hides it by default, and if your build has no such parameter, the skills fall back to describing the role inside the message.

Routing is about quota, not novelty

A LazyCodex run will show different models mid-session: gpt-5.4-mini on a small edit, a high-reasoning GPT model on hard logic, a Codex-tuned model on agentic coding paths. The source defines task categories and fallback chains that make this choice, and the README points at openai-categories.ts and model-requirements.ts rather than asking you to take its word.

The stated reason is quota discipline. Parallel agents burning a frontier model on routine steps is how you run out of budget before you run out of work. Routing a quick category to a cheaper model is not a performance claim, it is an accounting one.

That framing runs through the whole project. The README's own standard is that lazycodex should be judged by the features it actually installs, which is a reasonable bar to hold any harness to, including this one.

GitHub: https://github.com/code-yeongyu/lazycodex

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Anchoring Is a Wiring Problem: Inside ADHD's Isolated Reasoning Frames

Reno Lu — Mon, 31 Aug 2026 19:18:27 +0000

The claim at the center of this repo is narrow and testable: a reasoning agent that keeps one context window will keep one idea. ADHD, a skill for coding agents by Udit Akhouri, treats that as a wiring problem rather than a phrasing problem. It spawns N reasoning processes with zero shared context during divergence, puts each one under a deliberately distorted cognitive frame, and only afterward runs a separate critic pass to score, cluster, prune traps, and deepen the survivors.

The distinction it draws is worth sitting with. Linear Chain-of-Thought anchors on whatever it says first. Tree-of-Thought widens the search but still walks a single shared context, so the anchor rides along into every branch. Wider search over a contaminated prior is still a contaminated prior. The fix proposed here is not a better instruction telling the model to consider alternatives. It is denying the branches access to each other.

What the isolation actually buys

The README works one eval problem end to end: a CLI calls an LLM and sometimes hangs for 90 seconds, design the retry, timeout, and UX strategy. The single-shot baseline walks four textbook patterns (progressive timeout with staged UI, fast-fail plus exponential backoff, hedged parallel requests, streaming with keepalive) and lands on a hybrid: 15s first-token timeout, 30s between-token timeout, 90s absolute, one auto-retry. The repo's own read on that answer is fair. It is sensible, it is Google SRE Book chapter 22, it is what a senior engineer gives you in thirty seconds.

What it never does is question the frame. Nobody in that answer asks whether the user might want to bail out of a slow request, and nobody asks whether waiting and retrying the same model is the right move at all.

The ADHD run spawns 6 isolated frames and surfaces 30+ ideas across clusters labeled economic-incentive, async-control-surface, gamification, perceptual-distortion, collective-intelligence, and redundancy-race. Its non-obvious pick is a rage-quit button that pulses hotter the longer you wait; one click aborts and resubmits to a Haiku-class model. That rests on a premise the baseline never reaches: the slow model might just be the wrong model for this prompt.

Twenty traps come back flagged with one-line reasons, including the tempting ones like "stream tokens in reverse" and "patience-token billing." I would argue the pruning matters more than the generation. Any fan-out produces volume. Volume without a labeled discard pile just moves the filtering cost onto you. An independent LLM judge on this problem scored breadth 9 versus 6, novelty 8 versus 3, and trap detection roughly 8 versus 2, with methodology in the repo's evals doc. One problem, so read it as an illustration, not a result.

The adoption pattern is the interesting signal

Most projects in the early-adopters table did not vendor the code. They ported the shape onto their own primitives. repowire's maintainer turned frames into frame-shifted temp peers and mapped the generator/critic split onto separate peers versus the orchestrator's own turn. zk-flow-oss lifted IDEATION_FRAMES into a critique workflow as a pre-pass to reduce anchoring bias before review. wtfismyrepo built a deterministic layer (import-graph PageRank, git-churn fragility, GitHub PR and issue signals) that formats its analysis as a problem plus context, then runs codebase onboarding angles through 12 frames with names like new-grad, archeologist, and on-call-at-3am.

The entry I keep coming back to is godplans, which adopted the independent audit gate with its own isolated scoring pass and added a no-skill baseline control arm to its eval harness, then explicitly rejected the novelty-scoring axis and randomized frame selection as unsuited to its goals. That is what a portable pattern looks like when it is real. People take the parts that fit their problem and say out loud which parts do not.

Where it earns its cost

Installation is one command that auto-detects the agent, covering Claude Code, Cursor, Antigravity, Codex, Cline, Gemini CLI, Windsurf and around 50 more. You invoke it with /adhd "your problem" or let it auto-trigger on ideation intents. TypeScript, MIT, Node 18 or newer. There is a documented fallback for Codex builds that discover skills from a specific path.

The guidance on when to reach for it is refreshingly bounded: design decisions, fuzzy debugging, naming, API surface design, strategy, and anything shaped like "give me a few ways to." Spinning up six isolated processes plus a critic pass to answer a question with one correct answer is waste. Spending it before you commit a quarter to an architecture is cheap insurance against the first plausible idea becoming the only idea.

GitHub: https://github.com/UditAkhourii/adhd

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

GenOffice bets that file fidelity, not the AI panel, is the hard part

Reno Lu — Sun, 30 Aug 2026 17:04:33 +0000

The most interesting engineering in this project has almost nothing to do with the AI panel. It lives in packages/docx-engine, where editing a .docx regenerates only the paragraphs you actually touched and carries every other byte of the original file through unchanged. The README calls it a paragraph patch. Anyone who has watched a third-party editor round-trip a signed contract and quietly rewrite its numbering, styles, and section breaks understands why that matters more than any chat sidebar.

The repo, genspark-ai/genoffice, is six Electron apps over one shared engine layer: a word processor, a spreadsheet, a presentation editor, a PDF editor, a Markdown editor, and a shell that hosts the other five in tabs. Apache-2.0, TypeScript, builds for macOS, Windows, and Linux. The pitch is an AI-first alternative to Microsoft Office. What is underneath is mostly a file format compatibility project.

Compatibility is the expensive part

Read the per-app table and you can see where the years went. Docs renders a paginated view whose line metrics reproduce the original document's layout, so page breaks land where Word puts them, and it carries tracked changes, comments, styles, equations, and ink through the round trip. Sheets builds its UI on the open-source Univer core with a large in-house extension layer, but .xlsx import and export run through an in-house Rust sidecar using calamine and IronCalc, with charts drawn in-house on Konva plus pivot tables, slicers, conditional formatting, and formula tracing. Slides is an in-house .pptx parse, render, and edit engine with masters, cropping, and HarfBuzz text shaping metrics.

The PDF app is the sharpest example. Text editing there rewrites page content streams through PDFium compiled to wasm, with subset-embedded fonts, paragraph selection, in-block reflow, alignment restoration, and original-font preservation. The README's phrase for what it avoids is "no cover-up annotations." Most tools that advertise PDF editing paint a white rectangle over the old text and stack new text on top, which holds up until someone copies the text out and gets the original back. Rewriting the content stream is the harder path and the one that survives contact with a counterparty.

Markdown to Word goes through the same OOXML engine, with no Pandoc and no cloud round trip.

Where the AI actually sits

Every app embeds the same panel, and the shape of it follows from the engines rather than the other way around. In Docs it is block-granular editing with version snapshots and diffs. In the other apps it is a tool-calling agent operating over workbook, slide, or PDF state, with the agent loop and skill composition shared through packages/agent-core. That design only works because there is a structured block tree to address in the first place. A model that can name the block it wants to change is a very different integration from one that gets handed a flattened blob of text and hands back a new blob.

The account is the catch

Model calls route through a Genspark proxy. The apps sign in to a Genspark account with a device-code flow, and the user never enters or stores a model API key; Claude, GPT, and Gemini families are reachable through that proxy. The same account unlocks the "gsk" tool endpoints the agents build on, including web and image search, image generation and editing, media analysis, and audio transcription, all exposed through packages/ai-search for anyone extending the agent layer.

So the code is Apache-2.0 and the engine packages are pure TypeScript with no Electron dependency and unit tests, while the AI half depends on a vendor account. Worth knowing before you standardize a team on it. The editing engines still stand on their own if you never sign in.

What a developer can lift

If you generate or transform documents programmatically, the packages are more useful than the desktop apps. docx-engine parses to a block tree with docxIndex anchors and passthrough, emits OOXML fragments, and does the byte-level paragraph patching. file-parse handles text extraction for AI attachments across office and text formats. ai-provider is the provider abstraction and streaming layer. Each is importable without pulling in the desktop shell.

The dev loop is plain: npm install, npm run fixtures to generate test .docx fixtures, npm test, npm run typecheck across every workspace, and npm run dev to bring up all five editors plus the shell on Vite servers. The docs, sheets, and slides tests need no display, which is the small detail that tells you someone thought about CI before shipping the deb, rpm, and AppImage builds.

One design call is worth stealing regardless of what you think of the suite: document surfaces stay light in dark mode. Word-style dark chrome around white paper, so a file renders and exports identically either way. Theme colors sit on shared design tokens in packages/ui, with a CI guard that keeps chrome colors on the token system instead of drifting into hardcoded hex over time.

GitHub: https://github.com/genspark-ai/genoffice

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

The Memory Budget Came First: How TurboFieldfare Fits a 26B Model in 2 GB

Reno Lu — Sat, 29 Aug 2026 16:55:29 +0000

The headline on TurboFieldfare is that Gemma 4 26B-A4B runs in about 2 GB of RAM on an 8 GB MacBook Air. The more useful thing to notice is the ordering. The author picked the memory budget first and then rebuilt the runtime, the installer, and the app until they fit inside it. "Memory got expensive. So I gave a 26-billion-parameter model a ~2 GB budget." That line is the design document.

The model does not shrink. It occupies about 14.3 GB once installed. What changes is what is allowed to be resident. TurboFieldfare keeps the shared 1.35 GB core and an FP16 KV cache in memory and leaves the routed experts on SSD, pulling in only the ones a given token actually selects. A mixture-of-experts model with 26B total parameters activates roughly 3.88B per token, so most of those weights sit idle during any single forward pass. The project treats that idleness as a storage problem rather than a memory problem.

The residency rule, applied per layer

The README describes the decode loop in enough detail to argue with, which is rarer than it should be. At each transformer layer, Metal computes attention and the router from weights that are already resident. The CPU takes the router's top-8 expert IDs and plans against that layer's 16-slot LFU cache, then fills the misses with bounded parallel pread calls into Metal-visible buffers. While those reads are in flight, Metal computes the resident shared-expert branch, and the two results get combined afterward.

Two choices there are worth stealing. Sixteen slots against a top-8 selection sizes the cache to hold about two tokens of routing history, so repeated experts stay cheap while the miss path stays bounded. And overlapping the shared-expert compute with the expert reads hides SSD latency behind work that had to happen anyway. Prefill pushes the same idea further by processing prompts in chunks of up to 128 tokens, so one fetched expert serves many rows before anything evicts it.

The throughput figures are the project's own measurements: 5.1 to 6.3 tok/s decode on an 8 GB M2 MacBook Air, and 31 to 35 tok/s on a 24 GB M5 Pro. The README says plainly that these are reference points rather than ceilings, and that prompt length, generated length, and page-cache state all move them. It also links a community benchmark guide, which is the honest way to handle a number that depends this much on the disk underneath it.

The installer keeps the same discipline

Installers usually get a pass. They run once, so people let them stage a full checkpoint on disk and buffer whatever they want. This one does not. It streams the required byte ranges from a pinned Hugging Face revision and repacks them directly into the .gturbo layout as they arrive, so no second copy of the checkpoint ever lands and scratch memory stays bounded. The first install moves about 15 GB through those range requests, and the result is accepted only after its manifest and file hashes validate. Installation never loads the model into memory at all.

The repack tool also handles resuming an interrupted download, discarding saved download state, and verifying an existing install without loading it. The runtime refuses anything that is not a completed directory with a final manifest. That refusal is the kind of detail that shows up after someone has debugged a half-written model directory at least once.

What the constraint costs

TurboFieldfare is model-specific rather than a wrapper over MLX or llama.cpp, and it does not pretend otherwise. The package is arm64-only and wants macOS 26, Metal 4, Swift 6.2, and Xcode 26. It is text-only, with no images, audio, or video. The Mac app and CLI will not expose or execute tools; the loopback server accepts function-tool declarations and hands back model-produced tool calls for the client to authorize and run itself. That server has no remote authentication and no TLS, and the README tells you to keep it on 127.0.0.1.

There is also an operational cost that most local-inference projects skip mentioning. Only one model-owning process should run at a time, and before starting a run you are told to close memory-heavy apps and check memory_pressure -Q, then postpone if free memory looks thin. A runtime living inside a 2 GB envelope on an 8 GB machine cannot absorb a Chrome window, and the docs say so instead of letting you find out.

The repository is turbo-fieldfare, Apache 2.0, and the Swift package ships six products covering the library, the Mac app, the decode service, the CLI, the loopback server, and the repacker. The curated experiment record summarizes 103 measured results across kernels, caching, I/O, prefill, and decode. For anyone whose deployment target is fixed hardware rather than a rentable GPU, that record is probably the most transferable part of the project.

GitHub: https://github.com/drumih/turbo-fieldfare

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

A 2.78T Model in 8 GB of RAM, and the Gate Moves to the Disk

Reno Lu — Fri, 28 Aug 2026 22:48:22 +0000

A 2.78-trillion-parameter model answered a prompt on one CPU inside 8.24 GB of resident memory, and the project reports that the same model on a 224 GB machine produces byte-identical output. Extra RAM buys clock time and nothing else. That inversion is the entire argument of kimi-k3-in-c, a Kimi K3 inference engine written in portable C99 with no BLAS, no framework and no GPU.

Memory becomes a dial instead of a floor

Most inference stacks treat memory as an eligibility test. You either hold the weights or you do not run. The README replaces that test with a ladder, measured on one machine with 124 cores and a fast NVMe drive: 26.5 seconds per token at 8 GB, 24.2 at 32 GB, 19.8 at 64 GB, and 5.6 at 128 GB and above. The first three rows still read the model off disk on every step, so a slower drive drags them down. The top row keeps everything resident and stops waiting on storage.

The layout behind that ladder is described in four parts. The dense trunk stays in memory to whatever depth you pick and the rest streams. The 1.45 TB of routed experts are never resident at all, and get multiplied straight out of their packed 4-bit form rather than being unpacked into floats first. The other reductions are architectural: KDA, described as attention with a memory that never grows, and MLA, one latent in place of ninety-six heads. On top of that sit routing choices you can inspect, including picking 16 experts out of 896 and packing 93 layers so each one costs a single read.

The expert cache is sized from evidence rather than intuition. A trace of 100,096 expert requests recorded during a full 93-layer run ships with the repository, and a Python script replays it to reprint the capacity table the docs publish.

The gate moved from VRAM to the disk

Nothing about the CPU requirement is exotic. AVX2 with FMA is enough and the README says AVX-512 is unnecessary. The build is seven C files against libm and OpenMP, and the resulting engine is 176 KB. Linux x86-64 is assumed because the code uses O_DIRECT, posix_memalign and getrusage.

The hard requirement is storage. The checkpoint is 1.56 TB, the packed trunk adds 109 GB, and the project asks for roughly 1.7 TB free on fast local disk. So the barrier did not disappear; it relocated. Anyone with a spare terabyte and a weekend of bandwidth is now in the same position as someone with a rack.

Verification you can run before you commit the download

The part worth copying has nothing to do with trillion-parameter models. make test runs in under a minute with no checkpoint, no network and no Python. It exercises every kernel, the streaming cache, the safetensors reader, the config reader and the tokenizer, then runs three gates over a 13-layer model built from the same tensor graph as the released one: teacher forcing, greedy decode, and incremental decode with the KV cache and carried KDA state. The comparison target is a PyTorch reference captured as fixtures committed to the repo.

That ordering matters. You get a pass or fail on the arithmetic before you spend hours pulling 1.56 TB. A shell script, k3-doctor.sh, does the matching check on the machine itself, sizing your RAM to a preset and measuring your disk the way the engine will read it, and exits non-zero when the hardware cannot run the model at all.

Read the clock honestly

This is a base checkpoint with no chat template, so after "The capital of France is" it continues into quoted text instead of replying. The captured runs are slow by design of the tradeoff: 8 tokens in 261.5 seconds at 32.69 seconds per token on the laptop preset with 8.24 GB peak RSS, and 28 tokens in 299.3 seconds at 10.69 seconds per token on the server preset with 127.92 GB peak. The project also reports that version 1.0.0 made the math per token about 8 times lighter on that hardware, a follow-up chat turn 3.9 times faster, and long prompts roughly half as costly. Those are its own measurements on its own machine, not a general claim about the technique.

None of this is a serving path. What it is is a demonstration that the resident working set can be a parameter you choose rather than a constant the architecture imposes, with output equality held fixed across the whole range.

GitHub: https://github.com/FareedKhan-dev/kimi-k3-in-c

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

The CRM Where No Tool Accepts a Confidence Score

Reno Lu — Thu, 27 Aug 2026 22:41:45 +0000

The most opinionated decision in trycompai/crm is a refusal: no tool the agent can call accepts a confidence score. Everything else in the design follows from that.

The reasoning in the README is blunt. A model asked to grade its own certainty will happily produce a number, and it will be wrong in the direction that makes it look useful. So the tools do not report belief. They report what they observed, under names like crm.signature-block and github.account-identity, and a ledger prices the evidence. Strong evidence writes to the record. Weak evidence becomes a suggestion a human settles. The justification is the kind of thing anyone who has cleaned up a contacts table recognizes: a confidently wrong fact about a customer is worse than a blank field, because nobody can tell it is wrong.

The agent owns the schedule

apps/agent is its own deployment, built on eve, Vercel's filesystem-first framework for durable agents. A tool is a file, a skill is a markdown file, a schedule is a file, and the runtime keeps sessions alive across a redeploy so work resumes where it stopped. The inventory is small and legible: 18 authored tools, 4 skills written as prose the agent reads and the team versions like code, and exactly one schedule.

That schedule, dispatch.ts, decides nothing. It leases what is due and starts a session per row. The queue lives in lib/tasks.ts, where claimDue leases with FOR UPDATE SKIP LOCKED, so two dispatchers pick up disjoint work and a run that dies releases its row when the lease expires. The README draws the line explicitly: anything that sounds like "every N minutes, the oldest ten contacts" belongs in a task's dueAt, not in a cron expression.

The follow-up rule is the part worth stealing. When the agent wants another look at someone it calls schedule_recheck and has to say why, and that reason gets shown to the rep. An agent that cannot explain why it will be back in fourteen days does not have a reason. It has a default.

A shell with nothing worth taking

The sandbox gives the model bash, grep, glob and a /workspace, which is what separates a tool-caller from something that can keep a dossier, diff this month's profile against last month's, and grep a thread for a signature block. It runs with deny-all egress, and the README argues that costs nothing, because web_fetch runs in the app runtime and web_search at the model provider. What the denial removes is the one path by which a customer's email body could leave through a shell command.

The second half of that rule is an absence: the sandbox is never handed DATABASE_URL. A shell with credentials and network access is exfiltration-shaped even inside an internal tool. A shell with neither is a text processor. This is a cheaper and more durable control than any prompt instruction telling the model not to leak things.

Zero keys is a supported configuration

Every outside data source is optional, and running with none of them is the designed baseline. With no API keys, read_crm_history still reads your own threads, meetings and signature blocks, which the project calls the best evidence available, since no vendor can sell you a reply from the person's own address. Each additional key opens one more place to look, and the agent is told at session start which ones this install has, so it plans around what it actually holds instead of discovering gaps one failed call at a time. Startup prints the list, on or off, line by line.

One key is asked for rather than configured. Company brand data and LinkedIn both come from Context, and that key lives in a database row because the onboarding collects it and the General page under Settings changes it later. The stated reason is practical: a self-hoster's admin cannot redeploy to set an environment variable.

The stack is a Turborepo monorepo on Bun. Next.js App Router in front, NestJS with nestjs-trpc behind it, Prisma over Postgres, Better Auth with a single sign-in allow list. The tRPC router type is generated from the Nest routers, so types hold from the Prisma row to the table cell, and list state lives in the URL so copying the address bar reproduces the view. The model layer goes through Vercel AI Gateway, which means no provider SDK in the tree. There are also no organizations, deliberately: single tenant, because an organizationId that is always the same value is a column, an index and a permissions check that buys nothing while reading like a real one at review time.

Every contact, company and deal carries an Agent tab showing the steps as they happen, the leads discarded and why, and the questions the agent could not settle on its own. It turns on when AGENT_BRIDGE_SECRET matches in both processes. Leave it unset and the tab says so, and the agent keeps working its own queue anyway.

GitHub: https://github.com/trycompai/crm

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

The Codex Config Tool That Is Really About Undoing Itself

Reno Lu — Wed, 26 Aug 2026 13:45:09 +0000

Most config helpers treat the write as the job. codex-keysmith treats it as something a person will want to reverse six weeks later, after they have forgotten what they installed and why their agent is behaving oddly. That assumption shapes the entire CLI: check status, preview the plan, then write, and keep a file on disk whose only purpose is to make the uninstall possible.

The tool itself does something simple. It deploys one Markdown file into a Codex configuration directory, usually ~/.codex, so that later sessions load it. The README opens with a warning instead of a pitch, and the warning is the right call. This changes global behavior for that Codex config. It is not a project-level switch.

The write is small and the blast radius is written down

Four paths change. <codex-dir>/gpt-unrestricted.md, or whatever you pass to --name, is either created or backed up and replaced. config.toml gets exactly one edit, the top-level model_instructions_file key. hooks.json is moved aside wholesale to hooks.json.disabled. Finally, .codex-keysmith-manifest.json records what this layer owns.

That last file is the one that makes the rest work. Uninstall reverses a single layer per run, newest first, which is only possible because each deployment wrote down its claim. Scenario deployments land somewhere else entirely, under <target>/.codex-keysmith/, and leave the instruction-layer files untouched.

The hook isolation deserves a pause. Disabling all of hooks.json by default is a heavy move on a shared config directory, and the tool acknowledges that by giving --restore-hooks different ergonomics from everything else. It runs immediately and refuses --yes. Deploying and uninstalling want a preview and a confirmation flag. Putting your hooks back does not.

Failure states get their own vocabulary

inactive-by-config is a named status, meaning the instruction file is still sitting there but config.toml no longer points at it. The prescribed fix is --reactivate, available from v0.3.9, which restores only the missing top-level key. The README explicitly tells you not to hand-edit config.toml and not to rerun a full deployment just to put one field back.

Then it does something I rarely see in a tool of this size: it publishes where the guarantees stop. --reactivate rolls back batch failures it can catch, but it creates no durable journal. After a hard interrupt you run --status first, and if nothing conflicts you rerun --reactivate --yes to finish the remaining directories. --recover handles interrupted deploy and uninstall transactions, and nothing else. Do not delete the journal, the backups, or the manifest by hand.

The batch language matters because omitting --codex-dir makes the tool process every configuration directory it auto-discovers. One careless invocation reaches further than one machine's obvious ~/.codex.

A second channel that ships broken code on purpose

The instruction channel is what most people will use. The environment channel is --scaffold, which writes deliberately incomplete fixture workspaces into ~/.codex-fixture-workspace/<pack> and does not modify ~/.codex at all. You list packs with --scaffold-list, preview with --dry-run, and commit with --yes, the same rhythm as the main path. The two channels can stack, and neither writes into the other's directory. If you are running the standalone single-file script without fixture_packs/ next to it, scaffolding prompts you to grab the release bundle or point at --pack-dir.

Distribution reflects the same caution

The recommended install is manual and slightly annoying, which is the point. Download the single-file codex-instruct-v*.py and SHA256SUMS from the latest stable release, verify the hash, then run it. The README states the anti-pattern outright: do not pipe curl into python. There is no pip install and no auto-update.

The rest of the limits are stated without hedging. macOS and Linux are the primary CLI targets, and a fresh Windows deployment is marked EXPLICIT_BETA. The Desktop build is unsigned and unnotarized, ships only for Apple Silicon and Windows x64, and may trip Gatekeeper or SmartScreen. Python 3.10 through 3.14 is the recommended range. The published v0.1.0 should not be used.

The same shape appears across the sibling projects for Claude Code, Grok Build, and ZCode, each aimed at a different tool's config surface. What carries over is not the prompt being deployed. It is the accounting around it.

GitHub: https://github.com/Jia-Ethan/codex-keysmith

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Stop Accepting AI on the Demo: Build a Real Sign-Off Process

Reno Lu — Wed, 26 Aug 2026 12:24:04 +0000

When a vendor shows you an AI feature in action, you're watching a performance. The inputs are hand-picked, the outputs are polished, and nothing in that demo resembles the queue of messy, ambiguous, incomplete cases your team handles every day.

The problem isn't that vendors are dishonest. The problem is that demos are structurally unsuited to tell you whether a system will perform on your data. You need a repeatable, documented process that produces an answer you can put in a contract.

Build Your Own Evaluation Set

Before the vendor sees a line of your data, your team should assemble a set of real historical cases — inputs you already have answers for. Draw from normal operations, but deliberately include the hard ones: requests with missing fields, poor-quality scans, ambiguous instructions, edge cases your best people have argued about.

When two experienced team members genuinely disagree on the correct answer, leave that case out. That disagreement is a process problem, not a model problem. Including it just muddies your measurement.

Label every case with the answer a competent person would give. Once you have a working set, hold back roughly a third of them. Share the rest with the vendor for development. The holdout set is what you actually test against at sign-off — if a vendor has only seen a subset of your data, you get a cleaner read on whether the system generalizes.

Aim for enough cases to get a stable measurement. Very small sets produce noisy results; a larger and more varied set gives you a number you can trust and re-run.

Set the Threshold Before You See the Score

There is no universal accuracy threshold for AI features. The right number depends entirely on what happens when the system is wrong.

A tool that drafts responses for a human reviewer to approve before anything goes out has a very different risk profile than one that autonomously posts to a financial ledger or triggers a customer-facing communication. The tolerable error rate for the first might be generous; for the second, you may want something close to airtight.

Work through the error economics before you run the test. If the system produces a wrong answer, what does it cost in time, money, or customer trust to catch and correct it? That math gives you a defensible threshold. Write it down and get the vendor to agree to it in writing — before testing begins, not after you see a number you don't like.

Test the Edges, Not Just the Averages

Raw accuracy on typical cases is only part of the picture. Three categories of behavior often go untested until they cause problems:

Refusals. What does the system do when the input is genuinely outside its scope? It should decline clearly and route the case elsewhere, not produce garbage with false confidence.

Escalation. When should it hand off to a human? Does it actually do that, or does it push through with low confidence and no flag?

Hostile inputs. Someone will eventually try to manipulate the system — contradictory instructions, adversarial prompts, or attempts to extract behavior it wasn't designed for. You want to know what happens before your customers find out.

Stability is also worth checking: run identical cases on different days and look for consistency. Some variation is inherent in large language models, but a system that gives wildly different outputs on the same inputs is one you can't rely on.

Lock the Evaluation Set Into the Contract

An evaluation set that lives only in a shared spreadsheet is easy to ignore once the ink is dry. The better approach: attach it as a formal exhibit to the vendor agreement.

That contract language should require written notice before the vendor makes any changes that affect the underlying system — model updates, prompt changes, data sources, integration layers. It should specify that re-testing is required after such changes, with results delivered within a defined window.

The evaluation data should belong to you, not the vendor. That matters if you ever need to switch providers: a proprietary test set controlled by the current vendor is leverage you don't want them to have.

After go-live, treat the evaluation set as a living regression suite rather than a one-time gate. Business inputs drift; your test set should be updated periodically to reflect how your operations actually look today. Vendors update underlying models on their own schedules — automated changes can shift behavior without anyone alerting you.

This guide originally appeared on agentpalisade.com. Agent Palisade helps small and mid-sized businesses put AI to work inside the tools they already use — practical automation, internal assistants, and AI security reviews. Book a free 30-minute call.

Graft's real claim isn't speed, it's the files your agent never opened

Reno Lu — Tue, 25 Aug 2026 13:40:57 +0000

The most useful number in Graft's results table is not the 60% latency cut. It is the pattern the maintainers describe behind their SWE-bench Verified wins: every correctness gain has the same shape, because the cold baseline patches one file and misses its siblings. On django-11532 the report says the baseline patched 1 of the 5 files the fix requires and broke 18 previously-passing tests. On django-16263 it patched 1 of 4. Those are not slow runs. They are confident, fast, incomplete ones.

Graft is a TypeScript CLI from NanoNets that writes a context layer into your repo so a coding agent stops rediscovering the codebase on every task. Install it with npm, run graft init, and it asks which agents to wire up, builds a graft/ folder from your source, and drops a statusline plus hooks into .claude/.

Rediscovery is the tax, incompleteness is the bill

The README's problem statement is blunt about what an agent does before it changes anything: grep a term, open a file, follow an import, back out, try again. It is rebuilding a picture of a codebase it mapped an hour ago and threw away. The exploration cost gets paid again from zero on the next task, and whatever the agent worked out dies with the session. Humans onboard to a codebase once; agents onboard every single time.

Most tools that attack this sell you the token savings. Graft's own controlled sweep does report those, and they are real by the project's measurement: 162 runs across two repos, same Claude Sonnet 5 agent, same file tools, only the context differs. Mean tool calls drop from 4.2 to 2.3, tokens from 8,070 to 4,650, latency from 39.8 seconds to 15.8. Correctness in that sweep stayed flat at 93%.

Flat correctness is the honest part. The savings claim and the accuracy claim come from two different harnesses, and the project says so.

The graph is a folder you can grep

There is no vector store here. graft build produces a set of linked markdown files, one node per system, API, or concept, with typed links between them. The agent opens and follows them the way it reads any other file in the repo. No embeddings, no similarity search, no index to keep warm.

Two LLM passes build it. The first summarizes each source file into a short description. The second groups those summaries into a curated node set, picking a level of detail so a large repo lands at a few dozen readable nodes rather than one node per file. Running alongside that is a deterministic tree-sitter tier that emits a per-symbol code graph into graft/.graph/wiring.json and never calls a model at all.

The storage decision is the one operators will appreciate. graft build adds graft/ to .gitignore and treats it as a regenerable local cache, in the same spirit as node_modules. What you commit is the small wiring that init left behind in .claude/, AGENTS.md, and the MCP config, and each teammate builds their own graph. Every query rebuilds against the working tree first, which the project clocks at roughly 3 milliseconds of structural work when nothing moved, so uncommitted edits are covered without a stale index to babysit.

Push and pull are different products

The sweep ran three variants, not two. Push injects a graft ask bundle up front. Pull exposes graft_find_code and graft_file_api as tools and injects nothing, so context is paid for only when the agent asks. Push bought the speed. Pull gave most of that speed back and took correctness to 98%, five points over cold, which the project calls the strongest single result in the sweep.

That is a genuine fork, and the README does not paper over it: push when speed is what you need, pull when being right matters more. If your agent's mistakes look like the django cases, where it stops at the first plausible file, the pull configuration is the one worth trying first.

Summaries run under your own key against whichever provider you pick, including a local model, and the structural commands never touch one. The project is MIT licensed with a telemetry badge reading none. The check to run on your own codebase is not whether the token counter drops. It is whether the next multi-file change lands on all of the files it should.

GitHub: https://github.com/NanoNets/Graft

Curated by Agent Palisade — practical AI for small and mid-sized businesses.

Before You Self-Host AI: Getting the Requirement in Writing First

Reno Lu — Tue, 25 Aug 2026 12:22:29 +0000

When teams start building with AI, someone eventually raises the question of where the data actually goes. That concern is legitimate — but it often short-circuits into a conclusion before anyone has read the actual requirement driving it.

There are three real deployment options: a standard hosted API, an enterprise-tier hosted service with contractual data protections, and open-weight models running on your own infrastructure. Many projects land on option three without seriously evaluating option two. That skip is expensive.

What "Must Self-Host" Usually Means

Most mandates to keep AI inference local trace back to one of four sources: sector regulations, contract clauses with clients or vendors, internal security policies written before enterprise AI tiers existed, or security team guidelines applied conservatively.

The critical question is what the requirement actually constrains. There's a meaningful difference between a rule that governs data properties — who can use data for training, how long it's retained, what access controls exist — and one that requires physical custody of the model. Those two things sound related but lead to completely different architectures.

Get the specific language in writing before making any infrastructure decisions. "We can't send data to third parties" is a starting point, not a specification. Find out who approved the policy, what evidence would satisfy it, and whether it applies to all data or only specific categories.

The Enterprise Tier Most Teams Skip

Hosted providers offer business and enterprise plans that include terms many teams assume require self-hosting: no use of customer content for training, configurable or zero data retention, regional processing, tenant isolation, audit logging, and data processing agreements you can show to legal or compliance reviewers.

The difference between enterprise contract terms and standard terms is the difference between an enforceable promise and a best-effort practice. If a provider's enterprise agreement says they won't train on your data and they do anyway, you have contractual remedies. That's meaningfully different from relying on a public-facing privacy policy that can change.

Before pricing out GPU infrastructure, request written terms for the exact product your team would use. Verify what they say about training restrictions, retention windows, breach notification timelines, and deletion on request. Then get sign-off from whoever owns the compliance decision. This step often closes the self-hosting question entirely.

When Self-Hosting Actually Makes Sense

Some requirements genuinely can't be satisfied by any hosted service — specific regulatory frameworks, sensitive data categories, or client contracts with strict custody language. When that's the case, the economics deserve a realistic look before committing.

Hardware is rarely the largest cost. The fuller picture includes:

Infrastructure for peak load, not average load — concurrent request spikes determine your sizing, not daily averages
Non-production environments for testing and development
Redundancy for availability requirements
Engineering hours for ongoing maintenance, patching, and model evaluation cycles
On-call coverage for inference failures
Quality gaps between open-weight and frontier models, measured on your actual tasks, converted to human review costs

Build your cost model from real measurements. Sample a week of actual requests, count tokens, identify daily peaks, and project what 3x growth looks like. Then compare that number to the enterprise tier price, not to a rough internal estimate.

Hybrid Routing as the Middle Path

Many systems don't require uniform treatment of all data. Only certain fields, records, or request types fall under the actual mandate. In those cases, a hybrid approach routes only the constrained slice to a locally-hosted model while everything else goes through a hosted API.

Practical patterns include keeping embeddings local while running generation through a hosted service, using redaction at the boundary to strip sensitive fields before they leave your infrastructure, or using a local model as a preliminary classifier that routes requests based on content type.

The routing logic in a hybrid system becomes a security control in its own right. Test it against edge cases, log every routing decision, and configure it to fail closed — uncertain requests stay local rather than defaulting to the hosted path.

A Practical Decision Order

The sequence matters. Getting drawn into GPU pricing before confirming what the requirement actually says leads to expensive commitments that may turn out to be unnecessary.

A useful order:

Get the requirement in writing and classify what it actually constrains
Evaluate whether a hosted enterprise agreement satisfies it
Measure real volume, latency targets, and peak concurrency before sizing anything
Cost the self-hosted option end-to-end, including engineering and on-call time
If neither fully fits, design the hybrid split around the specific data categories under constraint

Most mandates that initially seem to require self-hosting are satisfied by a hosted enterprise agreement once the terms are reviewed carefully. The ones that remain after that review usually represent genuine regulatory or contractual requirements — and at that point, the infrastructure complexity is justified.