DEV Community: Reno Lu

The Proxy That Documents Its Own Memory

Reno Lu — Sat, 22 Aug 2026 13:24:19 +0000

The most telling part of the opencodex README is a collapsed details block most readers will never open. Inside it, the author lists 36 categories of process-retained state and the bound on each one: 12 byte-accounted stores under a 256 MiB budget, 4 buffers watched for in-flight byte pressure, 24 state-store registrations swept every 60 seconds. That is not how people document a weekend project. That is how people document something they expect to leave running for a month.

The headline pitch is much simpler. Install the npm package, run ocx start, and Codex, Claude Code, Claude Desktop, and Grok Build will talk to Anthropic, Gemini, xAI, Kimi, DeepSeek, Ollama, or any OpenAI-compatible endpoint you point them at. The proxy listens on localhost:10100 and translates Codex's Responses API into whatever the provider speaks, in both directions, carrying streaming, tool calls, reasoning tokens, and images across. The client UI never changes. As the README says under the Claude Code demo, the picker is stock Claude Code, the brain behind it is not.

Translation is the easy half

Anyone who has written an API shim knows the shape of that work. Map the request fields, map the response fields, handle the streaming format, ship it. What separates a shim from something you leave running in your shell is everything after that.

Look at what this process accumulates while it lives. A request log for the dashboard. Debug ring buffers. An image cache. A model cache per provider. Vision descriptions produced by the sidecar. Cursor blobs and responses-continuation state, because the Responses API is stateful and the provider underneath usually is not. Every one of those is a map that grows. The README's claim is that no unbounded Map or Set survives a config reload, and that GET /api/system/memory, behind the admin token, reports live retained bytes, eviction counters, and watchdog samples. You can argue with the specific budgets. You cannot say the author skipped the question.

The health surface reads the same way. /healthz answers whether the process is alive. /readyz answers a different question, post-sync readiness, returning 503 with Retry-After: 1 while status is pending or terminally failed, and a sanitized identity payload of service, version, uptime, pid, port, and status when it is ready. Two endpoints because liveness and readiness are genuinely different states, a distinction most local dev tools never bother to draw.

Account pooling is a scheduling problem

The ChatGPT account pool is where the design gets opinionated. Add several ChatGPT or Codex logins, refresh their 5h, weekly, and 30d quota from the dashboard, and under quota routing new sessions go to the lowest-usage healthy account. Round-robin and fill-first policies are there too. Existing Codex threads keep affinity to the account that started them, so a long SSH, tmux, or mobile-connected session does not change identity halfway through a conversation.

Then the README does something unusual. It lists the cases where that pin breaks: quota re-evaluation, failover, account exclusion, affinity expiry, and 401/403 or 429 recovery. Affinity is a preference, not a guarantee, and saying so plainly is the difference between documented behavior and a future bug report. You can also give the accounts a selection order for the case where one login, usually your Codex Desktop account, should only be reached for once the others are drained.

A note on who gets to decide

Buried in the agent-facing quickstart is a rule worth stealing. An interactive ocx start may ask once whether to star the repository. The CLI suppresses that prompt for agent-driven runs, and the API refuses it outright with 403 agent_consent_required.

Starring a repo is a trivial action. Treating it as something only a human may authorize, and enforcing that at the API boundary instead of in a comment, is a real position on what an agent may do while wearing its owner's credentials. If you build anything that runs unattended, copy the pattern: decide which actions carry the user's identity, then make the code refuse to take them on a machine's say-so.

Everything else here is a proxy. A carefully kept one, which is the rarer thing.

GitHub: https://github.com/lidge-jun/opencodex

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

What to Do When Your AI System Fails: A Practical Incident Response Framework

Reno Lu — Sat, 22 Aug 2026 12:14:40 +0000

Something went wrong with your AI system. Maybe it disclosed data it shouldn't have. Maybe an automated agent took an action nobody intended. Maybe a user found a way to manipulate it in ways you didn't anticipate. Whatever the specifics, the next few hours matter more than most teams expect.

Most organizations reach for their standard IT incident response procedure—and quickly discover it doesn't fit. AI systems fail differently than traditional software. A conventional bug reproduces reliably; an AI output is non-deterministic. Running the same prompt twice often yields different results, which makes verification awkward and confirms nothing. This isn't a theoretical concern. It shapes everything from how you collect evidence to how you write your post-incident review.

The First Hour: Triage With a Clear Head

Designate one person as incident lead before anything else. Multi-person decision-making without a single owner produces delays and conflicting actions at the worst possible moment. The lead's first job is documentation: when was this discovered, by whom, and through what mechanism. That timestamp is evidence.

Next, classify what actually happened. AI incidents generally fall into one of three categories: data exposure (the system shared something it shouldn't have), real-world action (an agent took a step with external consequences—sent an email, made an API call, modified a record), or output inaccuracy (the model produced something wrong in a way that caused harm). The classification drives your containment approach.

Also check whether external content entered the model's context—uploaded documents, scraped websites, email threads. If so, prompt injection is a possibility, and the scope of the incident may be wider than the initial report suggests.

Containing the Damage

The guiding principle is to use the smallest intervention that actually stops the problem. Revoking API credentials is often cleaner than disabling at the application layer, because application-level toggles can leave cached responses and queued jobs still executing. If an API key was exposed, that credential needs to be invalidated everywhere it's stored—not just in the affected service.

Before you consider anything contained, check for pending scheduled actions. An AI agent that was mid-workflow may have queued downstream steps that will execute regardless of whether you've switched off the front-end interface.

Preserving Evidence Before It Disappears

This is where many smaller teams make a costly mistake: they clean up or restart services before they've documented anything. AI systems generate evidence that vendors retain for limited and often short time windows, and those windows close fast.

Capture: full conversation transcripts with timestamps, session and trace IDs, the exact model version in use, the active system prompt at the time of the incident, any documents retrieved by the model, every tool call with its inputs and outputs, and the identity of the acting account. Once collected, disable automatic log deletion, instruct anyone involved not to remove related messages or communications, export everything you can access directly, and send a formal written log preservation request to your vendor.

Legal hold language matters here. A casual support ticket asking them to "keep the logs" is not the same as a formal written request tied to a potential legal proceeding—and the difference can be significant if this ends up in dispute.

Deciding Who to Notify and in What Order

Notification sequencing is as important as the content of what you say. Brief leadership before customers. Loop in your insurer before making any public statement. Business customers generally need to hear from you before affected individuals, and both before regulators.

Before you decide that disclosure isn't required, talk to legal counsel. The notification threshold under most data protection frameworks is lower than operators typically assume. Keeping communications factual and scoped to confirmed information is essential—speculation during an active investigation creates liability and erodes exactly the trust you're trying to protect.

What Comes After: Fixing the Gaps

The post-incident review, ideally completed within two weeks, should focus on systemic improvements rather than assigning individual blame. The most common finding is a logging deficiency: teams discover they captured only final model outputs, not the system prompts, retrieved context, tool calls, and user identifiers that would have answered their questions immediately.

Build the logging infrastructure you wish you'd had. Set explicit retention periods with intention. Reduce permissions to the minimum each component actually requires. Write at least one repeatable test case that would have caught this incident—so future deployments can be checked against it before going live.

AI incidents will happen. The difference between teams that handle them well and teams that don't usually comes down to one thing: whether they thought through the response before they needed it.

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.

DeepSeek Harness Puts Its Breaking-Changes Warning Before the Install Steps

Reno Lu — Fri, 21 Aug 2026 13:37:43 +0000

The loudest sentence in the DeepSeek Harness README is set in all caps: "THERE WILL BE COMPATIBILITY-BREAKING CHANGES." That is not a footnote buried in a changelog. It sits in its own section, second from the top, ahead of the install instructions. Read the rest of the file with that framing and the document stops looking like a user manual and starts looking like a recruiting pitch aimed at plugin authors.

The plugin claim is the architecture, not a feature

DeepSeek Harness ships as dsh, an open-source agent harness from DeepSeek AI, built on an architecture where everything is a plugin and powered by Cordis. The README links Cordis to a paper on spatiotemporal composability and then stops explaining. Notice what it skips: no feature list, no benchmark table, no comparison against other harnesses. It names a composition runtime, points at the theory, and moves on to install steps.

For anyone who has maintained an agent framework, that is the fork in the road that matters. Extension-point designs accumulate special cases. The tool registry gets a hook, then the model router gets a hook, then someone needs a hook that fires between the two, and six months later the extension surface is the product. A uniform plugin model pushes all of that into one mechanism. You either learn it or you fight it. The README does not describe how Cordis handles lifecycle, teardown, or reloading, which is what the linked architecture doc exists for. The useful thing to know before committing time: your mental model of this harness will be a Cordis mental model.

Getting it running is deliberately boring

Install Node.js, run npx @deepseek-ai/dsh web, and the Web UI comes up at http://127.0.0.1:3080 and opens in your default browser.

The most operationally honest line in the whole file covers SSH. A remote launch only prints the host URL rather than trying to open a browser, because the SSH client or editor owns the forwarded local address. Nobody writes that sentence down unless someone already filed the bug. There is a documented no-open switch for running the server without opening a browser at all. If you have ever started a dev server inside a container behind port forwarding and watched it try to launch a browser that does not exist, you know why the detail earned its place.

The source path is clone, pnpm install, pnpm run build, pnpm dsh web. The README is specific that the build step prepares repository artifacts and that pnpm dsh web consumes those artifacts without rebuilding. Small clarification, real time saved: when you edit something and the web command does not reflect your change, that is the documented behavior, not a broken cache.

What the README leaves out

Plenty. There is no description of what an agent session looks like, which models it talks to, what surface area a plugin actually gets, how state persists between runs, or whether anything is sandboxed. Every one of those answers lives behind a docs link: the Web UI guide, the development guide, the architecture documentation, and an AGENTS.md for agents working inside the codebase. Evaluating deepseek-harness from the README alone is not possible. The README is a routing table.

Two details do say something about the intended audience. The project asks plugin authors to tag their repositories with the dsh-plugin GitHub topic, which is an attempt to seed discovery for an ecosystem that has barely started. And it maintains a separate AGENTS.md, which assumes coding agents will be reading and modifying the repo alongside people.

The practical read

It is MIT licensed, written in TypeScript, with third-party dependency licenses disclosed separately. Feedback and bug reports route to GitHub Discussions rather than Issues, with a Discord alongside. Sending bugs to Discussions during a preview is a triage decision: it keeps the tracker from filling up with reports against code that will be rewritten anyway.

If you are writing a plugin against dsh this month, pin the version, keep the plugin small, and read the Cordis paper before the API docs. The all-caps warning at the top is the part of the README with the shortest half-life and the highest cost of ignoring.

GitHub: https://github.com/deepseek-ai/deepseek-harness

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

Before You Sign: How to Audit an AI Vendor's Data Practices

Reno Lu — Fri, 21 Aug 2026 12:21:01 +0000

When an AI vendor hands you a trust page, you're looking at a statement of intent with no remedy attached. The questionnaire answers on their website and the data processing addendum you can negotiate are entirely different instruments. Knowing the difference is where due diligence actually begins.

This is a working framework for software teams and the business operators who rely on them — not a theoretical checklist, but the specific questions that expose the gap between a vendor's marketing copy and what their contracts will actually commit to.

Start by Separating Documents from Claims

Before asking any questions, request three specific documents: a SOC 2 Type II report (read the scope section and any listed exceptions, not just the badge), a data processing addendum, and their current subprocessor list. These documents tell you what's been tested and what remedies are contractually available. Trust badges without scope context mean very little.

Once you have them, sort every vendor claim into one of three buckets: marketing (no remedy), questionnaire answer (recorded but not contracted), or contract language (enforceable). The goal of this process is to move the claims that matter into the third bucket before you sign.

Follow Your Data Through the Entire Stack

The architecture diagram a vendor shows in a sales call typically traces the happy path. The real question is where a realistic record — say, a customer support ticket that includes personal data — actually ends up across logs, caches, analytics pipelines, vector indexes, support tools, and backups.

Ask vendors to name their model providers and inference locations explicitly. Many SaaS products route requests to a mix of foundation model providers and self-hosted fine-tunes. Each of those hops is a data location that belongs on their subprocessor list. If a vendor can't name all storage locations for prompts, outputs, uploaded files, and derived data like embeddings, that's a gap worth pressing on before any contract gets signed.

For teams with regional compliance obligations, confirm not just where data is stored but where it's processed — and whether support staff in other regions can access production data to handle tickets.

Break Data Retention Into Three Separate Questions

Retention, deletion, and training are often bundled into a single policy clause that vendors present as straightforward. They're not.

Training and fine-tuning: Confirm whether your inputs and outputs are used to train or fine-tune any model. Many vendors offer opt-outs or make this a contract term — but the default may be permissive unless you ask.

Retention periods: Get specific numbers. "We retain data for the minimum necessary period" is not a retention period. Ask separately for live systems, abuse-monitoring windows, and backup schedules — "deleted within N days" almost always refers to live systems only.

Derived data: Embeddings, indexes, and cached representations of your data often survive primary record deletion. A deletion commitment is only complete if it explicitly includes derived representations and requires written confirmation upon completion.

Tenancy, Access Control, and Incident Terms

For multi-tenant SaaS products, the isolation model matters as much as the encryption story. Shared database tables with logical separation carry different risk profiles than separate schemas or dedicated instances. Ask whether tenant isolation has been explicitly scoped in recent penetration tests.

Retrieval-augmented systems introduce a specific risk: if a user's query can surface records from another tenant's data because of a permissions bug, that's a cross-tenant exposure event. Confirm that source-system permissions are enforced per user at query time, not only at ingestion.

For incident notification, replace vague language with specific windows in writing. "Without undue delay" is not a commitment. Define what counts as an incident broadly — cross-tenant data access and unauthorized agent actions should qualify alongside system intrusions.

Finally, before committing, confirm what you can actually take with you: data export formats, ownership of any prompts or fine-tuned models, and how you'll be notified if subprocessors change.

A Practical Closing Test

Pick the three data-handling terms your organization cares most about — training use, regional processing, retention limits, whatever they are — and verify each one is covered by contract language, not questionnaire answers. Anything a vendor will not commit to in writing is a preference, not a control.

PenEcho puts the AI on a canvas and runs it off your CLI login

Reno Lu — Mon, 10 Aug 2026 14:13:29 +0000

PenEcho makes a bet that the chat box is the wrong shape for thinking. Its interface is a 20,000 by 20,000 canvas where you write by hand, sketch a diagram, or drop half an equation, pause, and get an answer placed next to your marks. The model reads not only what you wrote but where you wrote it, because spatial relationships are part of the input.

Anyone who has tried to work through a derivation in a chat window knows the tax being removed here. You either translate every step into prose, or you rebuild the picture in a rigid diagram tool. PenEcho's claim is that the marks themselves are enough of a prompt.

The canvas is the interaction model

Answers, hints, explanations, continuations, formulas, plots, and diagrams all land on the canvas rather than in a transcript. Drafts the model returns behave like objects: you drag them, resize them by group or by axis, copy the text or the formula out, and then accept or discard them before they become part of your work. A freehand lasso selects what you want to hand over.

That accept-or-discard step is the detail I would point at. Output that arrives as a suggestion sitting beside your work, rather than as a message in a thread you now have to reconcile, keeps the document yours. Input is stylus or mouse, and you pan and zoom across a canvas sparse enough that "somewhere else on the page" is a real option.

No API key for the CLI paths

PenEcho can drive three kinds of model source: an authenticated Claude Code CLI, an authenticated Codex CLI, or a direct API endpoint in either OpenAI-compatible or Anthropic-compatible format. The CLI paths are the notable ones: PenEcho uses the selected CLI locally and needs no API key of its own for that source. What that costs you then depends on how the CLI account itself is billed.

The integration is careful rather than shallow. Canvas requests through Codex use codex exec --json, and PenEcho returns as soon as Codex emits its final message and turn.completed, terminating any lingering process in the background instead of making you wait for it. Claude requests run as one isolated claude -p turn with tools, agents, MCP, prompt suggestions, and session persistence disabled, and any attempted tool use aborts the request. For a canvas that should answer a question and nothing else, disabling the agent machinery is the correct call.

Reasoning effort is exposed where you actually want it. A toolbar menu next to Auto AI switches per request between the configured value, none, low, medium, high, and the provider's highest practical level, which maps to xhigh for Codex and the OpenAI API and to max for Claude. Selecting none disables thinking. Support stays provider-dependent, and an endpoint can reject a level its model does not implement. The configured default initializes the control, and a toolbar change overrides it for later requests without rewriting the config file, so a cheap sketch and an expensive derivation do not have to share a setting.

Setup is npm install -g penecho, then penecho configure, then penecho, with Node 20.3 or newer, or a desktop build from the releases page. Every LLM configuration page ends with Test and Save, and PenEcho saves before it checks, so a failed verification never loses what you entered. The Codex check is offline: it verifies the executable and login and reads the bundled model catalog rather than spending tokens on a test request.

Read the credential note before you deploy it

Configuration lives at ~/.penecho/config.env. API credentials are stored there in plaintext, with owner-only permissions on POSIX systems, and the project states they are never sent to browser code. That is an honest disclosure and also a constraint: on a shared or multi-user machine, that file deserves the same handling as any other secret, and a per-launch --config file is available when a particular session should not use the global one.

The project is AGPL-3.0 and is a member of Moonshot AI's Kimi Open Source Friends program, with API credits behind its development and Kimi K3 listed among the recommended models for demanding canvas work alongside newer Claude and Codex models. The configuration notes are specific about this: Opus 4.8 or newer is recommended for the Claude CLI, with Sonnet and Opus 4.6 able to respond but weaker on canvas work, and the Codex path wants GPT-5.5 or newer. That is a useful expectation to set for a tool whose whole job is reading your handwriting correctly.

GitHub: https://github.com/penecho/penecho

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

no-ai-slop names the patterns that make writing sound automatic

Reno Lu — Sun, 09 Aug 2026 13:41:22 +0000

The most useful thing in no-ai-slop is the naming. Everyone who reads a lot of model output can feel when a paragraph is machine-shaped, but very few people can say why in a way an editor can act on. This skill turns that feeling into a list of named patterns with an example of each, and then edits against them.

The README says 20 or more patterns are detected, and it prints eleven of them with an example each. Some are openings: throat-clearing ("Here's the thing..."), faux-insight setups ("What nobody tells you..."), colon reveals ("The best part: it learns."). Some are structures: binary contrasts ("It's not X. It's Y."), negative listing ("Not a X. Not a Y. A Z."), dramatic fragmentation ("That's it. That's the whole thing.").

The rest are the padding that fills a paragraph when there is nothing to say: superficial analysis ("...highlighting the team's commitment"), importance puffery ("marks a pivotal moment"), weasel attribution ("experts agree," "studies show"), fake-strong verbs ("serves as a centralized hub"), and synonym cycling, where the same thing becomes the agent, then the assistant, then the tool.

Read that table next to anything you have shipped recently. The synonym-cycling entry in particular is the kind of tell that can survive several rounds of self-editing, because each individual sentence looks fine.

Two modes, and the second one is the interesting one

Editing works the way you would guess: invoke the skill with a draft and you get the edited draft back plus a short section describing what changed. The stated policy is the minimum effective edit, which matters, because the failure mode of automated line editing is a rewrite that removes the author along with the slop.

The detection mode is the one I would reach for more often. Ask whether a piece reads as AI and you get back every pattern it found, each with the quoted line. The judgment stays with you, which is what you want when the writing is yours. It is also the mode that works on someone else's draft without the awkwardness of handing back a version you rewrote.

Beyond the pattern list, the skill enforces a handful of fundamentals: lead with the point when it helps, use active voice, untangle hard-to-follow sentences, and prefer concrete numbers over abstractions. My own editing bias is that the last one earns its place, because a sentence forced to carry a real number has nowhere to hide.

It checks its own edit

The workflow centers on two files. SKILL.md holds the editing rules and workflow, and eval.md holds pass and fail checks the skill runs on its own edits. So the loop is edit, then grade the edit against a fixed rubric in the repo, then report.

That is a small design decision with an outsized effect on trust. A style guide an agent reads once at the start of a long task tends to fade by the end of it; a check that runs on the finished output is harder to overlook. If you maintain house voice rules for model-written copy, the pattern is worth stealing whether or not you install this skill: keep the rules and the acceptance checks in separate files, and make the checks run last.

Installation is deliberately low-ceremony. You paste a line into Claude Code, Codex, or another harness asking it to install the skill globally from the repository, and the agent does the rest. License is MIT.

What it does not tell you

The README is short and does not pretend otherwise. There is no before-and-after example longer than the table entries, no measurement of how often detection fires on human writing, and no statement of which model it was tuned against, which matters because these patterns can shift from one model generation to the next. The author presents it as one skill extracted from a larger personal library, so its rules reflect one person's ear rather than a consensus style guide.

Even so, the pattern list is short enough to read in two minutes and specific enough to argue with, which is more than most style guidance manages. Install it or copy the table into your own review checklist; either way the naming is the part that transfers.

GitHub: https://github.com/petergyang/no-ai-slop

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

video-shotcraft hands your agent shot cards, not a video model

Reno Lu — Sat, 08 Aug 2026 13:37:54 +0000

video-shotcraft is not a video model. It gives a coding agent a catalogue of shot recipe cards, 161 motion previews, and a finished Remotion project, then lets the agent write the animation as code. The output is a render from a real codebase.

The distinction matters because of what you can do afterward. A clip from a video model usually arrives without the composition behind it. A Remotion project is source: you can change a duration, swap a screenshot, retime a cut, and render again. video-shotcraft is built for exactly that loop, aimed at web and desktop product promos, with the individual cards reusable in feature demos, brand films, and launch videos.

Recipe cards instead of prompt roulette

Each shot card carries purpose, energy, suggested duration, parameters, implementation notes, and known pitfalls, and the repository ships tuned TSX demos holding the actual easing and timing values. Count the cards yourself before quoting a number: the README says 104 and the repository description says 106. The 161 motion previews cover 161 styles and are searchable and filterable in a public gallery, where you can compare variants and copy the card names you want.

That structure is the antidote to the usual failure mode of asking an agent for motion design. Rather than "make it feel cinematic", you say the shot you want: use the deck-deal-flyin and row-embed cards to present this feature, or design a product close-up inspired by spotlight-hero-card. The card names are the vocabulary, and the parameters inside them are the part an agent would otherwise have to invent.

If you name no card at all, the skill introduces its built-in template first and asks whether to use it, which is a reasonable default for someone who does not yet know what they want.

The template is the fast path

The bundled Ink Press template is a validated 36.2-second promo at 1920 by 1080 and 30fps: 10 shots in a paper-ink-amber style, with 2.5D camera moves over real page captures, title cards, transitions, and a fully pinned cinematic SFX pass. The workflow the README suggests is to have the agent swap in your product's screenshots, copy, and branding, reproducing the same structure with your material in it.

The project also eats its own cooking. The 38-second gallery intro was produced with the skill, with storyboard, shot implementation, and sound design all done by an agent following the toolkit's methodology. That is the most useful kind of demo, because the artifact and the claim are the same thing.

Installation is one line handed to the agent, or npx skills add Vincentwei1021/video-shotcraft, or a manual clone symlinked into ~/.claude/skills or ~/.codex/skills. License is Apache-2.0.

The headless notes are the part I would keep

Buried under the showcase is a short section on rendering from a headless Linux box, and it reads like it was written after a bad afternoon. Three walls, each with a fix. On a low-core box, remotion still and remotion render fail with "Maximum for --concurrency is 2", and the setting documented as working is --concurrency=1. Recent Chrome and Chromium dropped old headless mode, so pointing Remotion at the system chromium fails to launch and you want a chrome-headless-shell binary instead. If remotion.media is unreachable, the automatic headless-shell download is rejected, so you pass --browser-executable with a local path.

None of that is glamorous, and all of it is what stands between a working local demo and frames that render on a build box: with those three flags, the README reports that renders from the bundled template work. A toolkit that documents its own failure modes alongside the flags that resolve them is telling you where it has actually been run.

What the README does not claim is worth noting too: there are no numbers on render times, no comparison against video models, and one template rather than a library of them, with more described as on the way. The bet is that structured shot vocabulary plus real code beats one-shot generation for product video, and the gallery is there so you can judge that yourself before installing anything.

GitHub: https://github.com/Vincentwei1021/video-shotcraft

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

open-connector keeps the credential out of the agent process

Reno Lu — Fri, 07 Aug 2026 14:05:30 +0000

The headline numbers in open-connector are 1,000 providers and 10,000 prebuilt actions, but the count is not the design. The design is a boundary: provider secrets stay inside the gateway, and the agent gets metadata, safe account labels, and results. An agent that can call your Gmail or your BigQuery never holds the credential that makes the call work.

OpenConnector, from oomol-lab, describes itself as an open-source connector gateway for AI agents and an alternative to Composio. A user connects an app account once, and after that the same catalog is reachable from application code through a TypeScript SDK, from a local agent relay through the oo CLI, from agent hosts over MCP at http://localhost:3000/mcp, and from anything else over HTTP with a generated /openapi.json. Same provider IDs, same action IDs, same contracts across all four surfaces.

What the boundary actually buys you

Credential handling covers API keys, OAuth2, custom credentials, and no-auth providers, which is the boring part that every integration layer has to get right. The part worth copying is the set of runtime controls around it: connection identity, scopes, runtime tokens, action allow and block policies, temporary file transit, and redacted run logs.

Read that list as an answer to the question "what happens when the agent asks for something it should not have?" An allow and block policy is enforcement at the gateway rather than a hope pinned on the prompt. Redacted run logs reduce the chance that the audit trail becomes a second copy of the secret. Runtime tokens give you a credential to issue that is not the provider credential itself. All of this is the project's documented architecture rather than an audited one: the README describes no independent security review, so read the executor source before you rely on any of it.

The action contracts are inspectable by design: request and response schemas, required scopes, and lazy-loaded executor source. An agent can read what an action expects and what permission it needs before calling it, and a human can read the executor that will run. Compare that with a closed tool surface where the only way to learn what a call does is to make it.

Deployment is the other half of the pitch

A gateway that holds every provider credential your users connect to it is exactly the component teams do not want to hand to someone else. OpenConnector ships four paths: local Docker or Node, Fly.io with SQLite on a persistent volume, a Cloudflare-compatible deploy on Workers with D1 for state and R2 for transit files, and OOMOL's hosted runtime. The stated reason for the hosted option is honest: teams blocked on OAuth approval or facing a launch deadline take the hosted auth now, with the same provider and action contracts available later if they move to a private runtime.

The Cloudflare path is documented down to the steps, including copying wrangler.example.jsonc to a local variant, applying D1 migrations, and setting secrets before npm run deploy:cloudflare. Getting started locally is docker compose up against the published image, with a console at localhost:3000 and generated API reference at /docs. The README lists Node 22 or newer for the Node runtime, which the container path covers for you. License is Apache-2.0.

Where it fits, and what to check yourself

The README is clear about the intended users: agent products that need durable access to the work apps people already use, teams adding agent workflows that need stable action contracts, and teams that want hosted auth without giving up the option to self-host.

Two things to verify against your own provider list before committing. First, the provider and action counts in the badges are read live from OOMOL's hosted catalog, so confirm the providers you actually need are present in the deployment you plan to run. Second, a shared catalog is a shared shape: an action written for the common case may not expose the one field your integration needs, and because the executor source ships with the runtime you can read exactly why, then extend it or contribute the change. Both are fair trades for keeping OAuth complexity and provider tokens out of the agent process, which is the part most teams should not be rebuilding.

GitHub: https://github.com/oomol-lab/open-connector

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

img2threejs rebuilds the object in a reference image as code, not a mesh file

Reno Lu — Thu, 06 Aug 2026 15:06:55 +0000

img2threejs does not output a mesh file. Point it at a reference image and it rebuilds the object shown there as a THREE.Group factory written in TypeScript, built from primitives, procedural shaders, and generated geometry. What you get back is source: readable, diffable, and editable by hand when the render is nearly right.

The project calls this reconstruction-by-code, and it is explicit that it is not photogrammetry, mesh extraction, or a downloaded art pack. Every model in the public showcase gallery is generated code running in the browser, with the source linked next to it. You can orbit the model, inspect its reference image, and read the function that produced it.

The pipeline is a ladder of gates

The interesting engineering is not the code generation. It is the refusal to let a pass advance.

A run moves through a fixed order: blockout, structural-pass, form-refinement, material-pass, surface-pass, lighting-pass, interaction-pass, optimization-pass. A pass unlocks only after the previous one has been reviewed and accepted, and acceptance means something specific: a real render, a side-by-side comparison sheet against the reference, an agent-vision score at or above threshold, and every identity-defining feature clearing its own threshold.

Before any code is generated the pipeline enumerates a detailInventory of the small things that make an object recognizable: gloss, bevels and rounding, screws and rivets, engraved or painted linework, contours, stains and wear. Each detail has to map onto a real component or material entry. A strict-quality gate blocks generation until the inventory is complete, and blocks a single-root spec for a compound object.

The CS2 knife and Glock-18 routes go further, with family-specific component contracts plus component-coverage and map-stripped blockout gates, which exist to stop a convincing texture from standing in for structure that was never built. Those reviews record exactness tier, family identity, painted-region and projection coverage, and per-region confidence.

After each pass the agent picks exactly one action: continue, refine-spec, refine-code, request-input, or stop. The split between refine-spec and refine-code is a small design decision that pays off in debugging, because it separates "the plan was wrong" from "the plan was fine and the geometry missed it".

Animation-ready is a claim with a definition

Plenty of tools produce a static shape. img2threejs treats a runtime hierarchy as part of the acceptance criteria: the model exposes pivots, sockets, colliders, and destruction groups through root.userData.sculptRuntime, and an attachment-correctness gate makes child parts declare how they join their parent so handles, limbs, and tubes do not float in mid-air. That is what the project means when it says the output is ready to animate rather than an inert lump.

Subjects are classified as object, character, or hybrid, and characters route through an anatomy-aware track with head-unit proportions and facial landmarks. For likeness work there is an opt-in path that fits a parametric template to image landmarks, de-lights the photo, camera-matches the render, and projects the reference onto the mesh. The README does not oversell it: a single image cannot guarantee full likeness, so the pipeline reports per-region confidence and asks for more views when the image cannot show what matters.

Where it fits

It runs as a skill under Claude Code, Codex, or OpenCode, and it is deliberately agent-agnostic. Wherever the docs mention agent vision or an agent browser tool, it uses whatever the host provides: native image reading, a browser MCP, the project preview, or a screenshot you supply. The tooling itself is Python 3.10 or newer using only the standard library, so there is nothing to install beyond cloning the folder into a skills directory. License is Apache-2.0.

The project describes itself as deliberately token-efficient, though it publishes no measurement of that, so treat it as the authors' framing rather than a result. The part you can check by reading the repository is the review loop: the agent's own vision, scored against a side-by-side sheet, is the only thing allowed to approve a pass. For anyone who has watched an agent spend a long context window nudging a 3D asset it cannot see, that is the idea worth stealing.

GitHub: https://github.com/img2threejs/img2threejs

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

Open Code Review: Alibaba's AI reviewer that hands the LLM less work

Reno Lu — Wed, 05 Aug 2026 15:08:16 +0000

Alibaba's answer to unreliable AI code review was to give the language model less to do, not more. Open Code Review runs on the same LLM a general-purpose agent would use, yet its README reports it spends roughly one-ninth the tokens and lands higher precision and F1 on the same benchmark. The trick is architectural: the model no longer runs the whole review.

Why general-purpose agents fall short

The project is blunt about what it reacts to. If you have wired up something like Claude Code with Skills to review pull requests, the README names three failure modes you have probably hit. Coverage is incomplete: on larger changesets the agent cuts corners, reviewing some files and skipping others. Positions drift: reported issues point at the wrong line or the wrong file. Quality is unstable: natural-language Skills are hard to debug, and results swing with small prompt changes. The stated root cause is that a purely language-driven pipeline has no hard constraints on the review process.

Open Code Review, the alibaba/open-code-review repo, ships as an ocr CLI written in Go and treats that as an engineering problem rather than a prompting problem.

Deterministic scaffolding around a smaller agent

The core idea is a split of labor the project calls deterministic engineering combined with an agent. Steps that must not go wrong are handled by ordinary code, and the model is reserved for judgment calls.

On the deterministic side, file selection decides exactly which changed files get reviewed and which get filtered, so nothing important is dropped. A bundling step groups related files into one review unit, using the example of message_en.properties and message_zh.properties traveling together. Each bundle runs as its own sub-agent with isolated context, which keeps large changesets stable and makes concurrent review natural. Rule matching is done by a template engine rather than by asking the model to pick rules, matching a built-in ruleset (null pointer exceptions, thread-safety, XSS, SQL injection) to each file. Separate positioning and reflection modules then check where each comment lands and whether its content holds up.

The agent keeps the parts where dynamic decisions matter: reading full file contents, searching the codebase, pulling in other changed files for context. Its prompts and its toolset are tuned specifically for review, with the toolset distilled from tool-call traces in Alibaba's production data rather than borrowed from a generic agent kit.

The trade-off is stated plainly

The benchmark behind the token claim is worth reading closely. It draws on 50 popular open-source repositories, 200 real pull requests, and 10 programming languages, cross-validated by more than 80 senior engineers into 1,505 annotated ground-truth issues. Against a general-purpose agent on the same model, Open Code Review reports higher precision and F1, faster reviews, and about one-ninth the token cost.

It also reports lower recall, and does not hide it. That is the deliberate part: the tool would rather miss some real defects than bury you in false alarms. For a reviewer that runs in CI, where every noisy comment costs a human a triage, that is a defensible bet, though it does mean Open Code Review is not trying to catch everything.

The provenance is the other reason to take it seriously. This was Alibaba's internal code review assistant for about two years before the open-source release, serving tens of thousands of developers. Getting started is a matter of installing the binary, pointing it at an OpenAI or Anthropic compatible endpoint, and running it against a Git diff. There is also an ocr scan mode that reviews whole files, useful for auditing an unfamiliar codebase that has no meaningful diff to read.

The broader claim is worth sitting with: for a task like code review, wrapping a model in hard constraints beat handing that same model more freedom. Open Code Review is a fairly direct argument that the reliability of an AI feature can come from the engineering around the model, not only from the model itself.

GitHub: https://github.com/alibaba/open-code-review

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

PixelRAG retrieves over page screenshots instead of parsed text

Reno Lu — Tue, 04 Aug 2026 15:16:08 +0000

PixelRAG makes a blunt bet: for retrieval, a screenshot of a web page beats the text you would parse out of it. Instead of converting a page or PDF into text chunks and hoping the parser kept the table intact, the project renders the document to images and searches over the pixels directly.

That claim is the title of the paper behind the repo, "Web Screenshots Beat Text for Retrieval-Augmented Generation," from Berkeley SkyLab, BAIR, and Berkeley NLP. The README's own diagram makes the case with one example: a text-based pipeline parses a page, loses the table, and the reader model has nowhere to find the answer. PixelRAG renders that same page to screenshot tiles, retrieves the right tile, and the reader reads the number straight off the image.

What actually changes

Two pieces carry the idea. First, capture: the pixelshot command turns any URL, PDF, or local file into image tiles using headless Chromium over CDP. Second, embedding: a Qwen3-VL-Embedding model, LoRA-fine-tuned on screenshot data, maps those page images into a vector space where visual content is retrievable. Tables, charts, infographics, and layout survive, because nothing was ever flattened into text in the first place.

The rest is a conventional retrieval stack. pixelrag chunk, embed, and build-index turn tiles into vectors and then into a FAISS index. pixelrag serve puts a FastAPI search endpoint in front of that index on CPU or GPU. You install only the stages you need, and each stage runs standalone without the orchestrator, so you can render on one machine and embed on another.

You can also skip the build entirely. The team hosts an endpoint at api.pixelrag.ai with a pre-built index of 8.28M Wikipedia pages, no key and no setup, and it answers a POST with either a text query or an image query. If you want the index locally, it lives on Hugging Face, though the base Wikipedia index is about 217G, so plan disk accordingly.

Give a coding agent eyes

The part most people can try in a few minutes is the Claude Code plugin. The same renderer ships as a skill called pixelbrowse. Install the pixelshot CLI so it sits on your PATH, add the marketplace, install the plugin, and then Claude screenshots a page and reads the image instead of fetching raw HTML:

claude -p "screenshot https://news.ycombinator.com and summarize the top stories"

There is no MCP server and no backend. The skill just calls pixelshot (Playwright/CDP) on your machine, in an isolated throwaway Chrome profile, so it works even while you have Chrome open. For an agent, charts and dashboards that are invisible to a plain HTML fetch become readable.

Where it fits, and the fine print

The honest catch is hardware and disk. Embedding runs a vision-language model, so it wants a GPU on Linux or Apple Silicon on a Mac. The README's own smoke test indexes a single PDF and searches it locally, about three minutes on an M-series chip and about a minute on a GPU, which is a fair way to feel the whole loop before committing to anything large. Training is walled off in its own train/ uv project with a pinned CUDA stack, and you do not need it: the LoRA adapters and the full screenshot training set are both published, so adapting a larger backbone is a supported path rather than a rewrite.

PixelRAG is a research codebase with a working product attached: a paper, a live demo, a hosted API, and a plugin. The question it poses is not whether pixels can beat text on every corpus, but how much retrieval quality your current pipeline is quietly losing at the parse step.

GitHub: https://github.com/StarTrail-org/PixelRAG

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

Kun bets requirements-first coding only works if the models stay cheap

Reno Lu — Mon, 03 Aug 2026 15:37:40 +0000

Kun makes a bet most coding-agent apps avoid: that AI coding should begin with a written requirement, not a one-line prompt, and that this only holds up if the model bill stays cheap enough to run the whole loop dozens of times a day. The two ideas are connected on purpose, and the second is what makes the first survive as a daily habit.

Kun is a desktop workspace built on Electron and React, running on macOS, Windows and Linux. Instead of handing an agent a sentence and letting it edit code directly, you start by drafting a requirement. A requirement AI helps you fill in the open questions, do pre-implementation research and mark out the boundaries. That draft gets saved as .kunsdd/draft/.../requirement.md, with structured requirement blocks, acceptance criteria and a history you can trace. From there you move into design, then into a plan through /plan and create_plan, which writes a GUI-managed .kunsdd/plan/... file whose steps stay linked to the requirement. When the requirement changes, Kun can prompt you to re-plan so the two do not drift apart.

Three modes over one runtime

The workflow runs across three parallel modes. Code faces a real codebase: it reads project context, runs shell commands, edits files, and shows every change in an inline diff and a review panel before you commit. Design turns requirement fragments into UI mockups, infographics, interactive HTML prototypes and a shared DESIGN_SYSTEM.md, then hands the result to Code for implementation. Write is a standalone Markdown workspace with a file tree, Live, Source, Split and Preview views, selection-based inline editing, and export to HTML, PDF, DOC and DOCX. From a Markdown file you can also trigger PPT Master, which confirms an outline, page count, audience and visual direction with you first, then generates a native, editable .pptx into a presentations/ directory without touching the source file. That step needs Python 3.10 or newer on your machine.

All three modes share one thing: the same Kun runtime, provider configuration, approval mechanism and session handling. Kun ships its own local runtime, reached through kun serve, which exposes an HTTP and SSE boundary and runs a cache-first agent loop with an append-only event log, usage stats and context compression. Sessions, logs, preferences and runtime config stay on your machine by default, and model calls go out through your own provider credentials.

Why the model choice is the design

Kun does not treat its default models as ordinary optional providers. It ships around three Chinese cost-effective vendors: DeepSeek as the main text and reasoning model, Xiaomi MiMo for long-context text, vision input, speech-to-text and text-to-speech, and MiniMax for image, voice, music and video generation. The stated reason is economic. A requirements-first flow produces more rounds of clarification, research, structuring, planning, execution and validation than plain chat, and it leans hard on repeated model calls. If those calls cost too much, the whole approach never becomes something you reach for every day. So Kun organizes its first-run setup and settings around these three, routing light clarification to fast models and heavy code and reasoning to stronger ones. You can still add OpenAI-compatible, self-hosted or custom providers, but the default experience is built around keeping the running cost low.

The rest of the surface follows the same continuous-workflow idea: a visual "Create Loop" canvas for node-based orchestration in the style of n8n or dify, remote entry points through Feishu, Lark and WeChat plus local webhooks and scheduled tasks, MCP servers and Skills, and a .kunx extension platform with an SDK and Extension API v1. One caution worth naming: Kun is released under the PolyForm Noncommercial License 1.0.0, so it is for study and reference, and any commercial use needs separate written permission from the author.

Kun is young, created in May 2026, and the README reads more like a product manifesto than a track record. What it lays out clearly is a single coherent argument: tie requirements to plans to code to review, and pick the models that let you actually afford to run that chain.

GitHub: https://github.com/KunAgent/Kun

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