DEV Community: Sean

Skein: a knowledge graph that never overwrites a contradiction

Sean — Wed, 29 Jul 2026 20:16:16 +0000

I kept losing the thread across AI chat sessions. Ask about something, the idea evolves over three or four separate chats, and by the end I've got five overlapping conversations open and no clean record of which decision actually won, or why I changed my mind halfway through.

So I built Skein — paste a transcript in, it extracts the atomic claims (individual decisions and facts, not a summary), clusters them by topic, and when a new claim contradicts an old one, it chains onto it instead of overwriting it. Then you can actually query the result with real RAG.

Two things about the build turned out more interesting than I expected going in.

Claims chain, they don't overwrite

The core data model is almost embarrassingly simple. A claim looks like this:

{
  id, text, topic, label,
  status: "active" | "superseded" | "correction" | "discarded",
  supersedes: string | null, // id of the claim this one replaces
}

When a new claim comes in on a topic that already has an active claim, and the text actually differs, the old claim flips to superseded and the new one gets tagged correction with supersedes pointing back:

export function applyNewClaims(existingClaims, newClaims) {
  const claims = [...existingClaims];
  for (const incoming of newClaims) {
    const activeSameTopic = claims.find(
      (c) => c.topic === incoming.topic && c.status === "active"
    );
    if (activeSameTopic && activeSameTopic.text !== incoming.text) {
      activeSameTopic.status = "superseded";
      claims.push({ ...incoming, status: "correction", supersedes: activeSameTopic.id });
    } else if (!activeSameTopic) {
      claims.push(incoming);
    }
  }
  return claims;
}

Nothing gets deleted. Walking supersedes backward from any claim gives you the full decision history — Postgres, then Mongo, then back to Postgres because Mongo made relational queries harder than expected — instead of just the current answer with the reasoning stripped out.

It's naive on purpose: same topic, different text, is the whole conflict-detection heuristic. It'll misfire on any topic that legitimately holds multiple simultaneous active claims. I know exactly where the edges are and haven't hit them yet in real use, which felt like the right bar for shipping it rather than building a more sophisticated version speculatively.

Retrieval had to be decoupled from chat provider — Anthropic has no embeddings API

This one actually shaped the architecture. The app supports Anthropic, OpenAI-compatible (including local models via Ollama), and WebLLM running fully in-browser via WebGPU. Naturally I wanted embeddings to just come from whichever provider you'd picked for chat.

Anthropic doesn't offer an embeddings endpoint at all. Not a gap in my code — a gap in their API surface; they point people to Voyage AI. So if embedding were tied to chat provider, anyone using Anthropic (probably most people) would get zero real retrieval.

The fix was to stop treating "embedding provider" and "chat provider" as the same decision. Embeddings always run locally via WebLLM (a real embedding model, snowflake-arctic-embed-s, not a chat model pressed into service) regardless of what's answering the question. Free, no key, and it means retrieval quality doesn't depend on which chat provider happens to have an embeddings endpoint.

The retrieval layer has one more rule worth mentioning: semantic similarity has no concept of a correction. If the highest-scoring match for a query is a superseded claim — its old wording just happened to match more closely than whatever replaced it — the system resolves it to that topic's current head before it's used as context. Otherwise you'd get an embedding-powered way to confidently answer with outdated information, which would defeat the entire premise of the correction-chain model above it.

// One claim per topic in context, resolved to that topic's CURRENT head
const clusterByTopic = new Map(buildClusters(claims).map((cl) => [cl.topic, cl]));
const seenTopics = new Set();
const sources = [];
for (const { claim } of scored) {
  if (sources.length >= TOP_K) break;
  if (seenTopics.has(claim.topic)) continue;
  seenTopics.add(claim.topic);
  sources.push(clusterByTopic.get(claim.topic)?.head ?? claim);
}

Synthesis goes through whichever chat provider is selected, asked to answer strictly from the retrieved claims and cite them inline. If the claims don't contain enough to answer, it says so instead of guessing.

A CLI that shares prompts with the web app, not a copy of them

There's also a zero-dependency CLI doing the same extract → categorize → query pipeline with no browser involved — for anyone who wants to be fast and doesn't need to see a graph. It started as a hand-copied port of the web app's prompts. That lasted about a week before they drifted: a fix applied to the web app's extraction prompt never made it to the CLI's copy.

The actual fix wasn't "import everything from one side into the other" — the two have genuinely different provider layers (the web app supports three providers including a browser-only local model and passes around a settings object; the CLI is BYOK-only across two with flat params), and unifying that would mean papering over a real difference. Instead, just the prompt content moved into a shared module both sides import:

Skein/
  shared/prompts.js   <- the actual prompt strings, single source of truth
  src/lib/             <- web app, imports from ../../shared/prompts
  cli/src/lib/          <- CLI, imports from ../../../shared/prompts

One nice side effect: fixing the drift required rewording a sentence that referenced "the graph node" a label appears on — phrasing that didn't make sense from a CLI with no graph. Turned out the underlying advice (a label needs to read standalone, without the full claim text next to it) was equally true of the CLI's list output. It wasn't environment-specific after all, just narrowly worded. Once reworded generically, the whole prompt became shareable verbatim.

What it looks like

The graph clusters claims by topic using a real force-directed layout (not a canned graph library — dropped the bundle by about 400KB), with topic groups rendered as soft metaball blobs rather than one circle sized to the cluster's farthest node. Correction history shows on the node itself (a status ring, not a line back to a predecessor) — click any node, or query the graph, and the full chain shows in a compact popover.

Fully client-side. IndexedDB for storage, no backend, MIT licensed. Repo's at github.com/Virerra/Skein, live demo linked from the README. If you poke at it and something breaks, I'd genuinely like to know.

I built a no-code multi-agent orchestration platform — parallel execution, targeted feedback, runs in your browser

Sean — Mon, 29 Jun 2026 04:11:23 +0000

The problem with most agent builders

They're sequential. They fail without recovery.
They require code. They route your data through
their servers.

Parlance is built to fix all four.

What it is

A free, open-source, no-code visual workspace
for orchestrating multi-agent Claude workflows.
Build on a canvas, connect nodes with edges,
run with real API calls.

What the engine actually does

Parallel execution
Modified Kahn's algorithm computes topological
waves. Each wave dispatched with Promise.all.
A→B→C runs sequentially. A and B feeding into
C runs A and B simultaneously, then C. Automatic.

Three-tier retry
Self-retry → upstream escalation → Overseer
intervention. When an agent fails, the engine
tries to resolve it without user input.

Targeted feedback
Overseer evaluates output against your conditions.
On rejection: parses TARGET: [agent name], re-runs
only that agent and its downstream forward chain.
Agents upstream of the fix point untouched. Cost
savings proportional to where in the chain the
problem is.

Workflow chaining
Chain Input nodes pull output from other Parlance
workspaces. Optional caching avoids re-running
expensive upstream workflows.

Architecture

1,258-line execution engine (orchestrator.js, runEngine.js, claudeClient.js, mockClient.js, engineEventBridge.js)
React 19 + ReactFlow canvas
Single useReducer, 26 pure-function action types
Backend: 3 Vercel serverless functions (CORS proxy only — all orchestration runs client-side)
BYOK — key in localStorage, sent per-request, never written server-side

56 source files. 8,310 lines. MIT licensed.

The full suite

This is the fifth tool built in two weeks.
All free, all open source, all BYOK:

Reality Check: realitycheck-project.vercel.app
Singularity: singularity-workspace.vercel.app
LoopLens: looplens-project.vercel.app
Claude Batch: virerra.github.io/Claude-Batch
Parlance: parlance-project.vercel.app

Links

Live: parlance-project.vercel.app
Source: github.com/Virerra/parlance
License: MIT

I built a paced Claude API queue in a single HTML file — 29 tests, 10 bugs found and fixed

Sean — Sun, 28 Jun 2026 10:44:55 +0000

The problem

Rate limits on bulk API work are painful. You
start processing a spreadsheet row by row, hit
a 429 after a few requests, wait, continue,
hit it again. You end up babysitting an API
for hours.

What I built

Claude Batch is a paced request queue in a
single HTML file. No build step, no npm install,
no server. Open it in a browser and it works.

Two input modes:

Type prompts (one line = one request)
Upload CSV/Excel and write a {ColumnName} template — one request per row, only the columns you reference get sent (typically 70–80% fewer tokens)

Set an interval (1–180s), press Start, walk
away. Exports as JSON, CSV, or plain text.

Engineering details

Retry with exponential backoff (2s, 4s, 8s, cap 20s)
Respects retry-after header — server guidance overrides calculated backoff
AbortController on every fetch — cancels the actual HTTP connection on Stop
504 in the retryable set (gateway timeouts are transient)
sleepAbortable() polls isRunning every 100ms during backoff — Stop resolves immediately
29 tests across 95 assertions in a jsdom harness that loads the actual index.html and drives real UI events

10 real bugs found and fixed

Every bug has a regression test:

No retry on 429s — fixed with backoff logic
Timer leak on repeated start/stop — fixed with tracked setInterval
Stuck processing row after Stop — fixed with status reset sweep in stopRun()
Clear All orphaning in-flight rows — fixed by disabling during run
retry-after header ignored — now read and respected
No AbortController on fetch — added
504 missing from retryable set — added
Draggable state not synced with isRunning
stopRun() only re-rendered conditionally
Dead code currentRowTimer — removed

Links

Live: virerra.github.io/Claude-Batch
Source: github.com/Virerra/Claude-Batch
License: MIT

I built a pre-run cost simulator for agentic loops — 13 models, zero API calls, works offline

Sean — Sat, 27 Jun 2026 08:56:32 +0000

The problem

Agentic loops compound costs in ways that aren't
obvious until the bill arrives.

Iteration 1: $0.19. Iteration 30: $2.48. Same
agent, same task — the model re-reads full context
on every turn. By iteration 20 you're paying for
the same context 20 times over.

What I built

LoopLens is a pre-run cost simulator. Configure
your loop before you run it and get a full
per-iteration breakdown.

What it models:

4 context accumulation strategies (full, sliding window, summarization, stateless)
Tool call overhead (web search, code execution, RAG, browser, external API)
Multi-agent fan-out (orchestrator + N subagents)
Prompt caching break-even analysis
13 models across Anthropic, OpenAI, Google, DeepSeek — compared side by side

Real numbers from a test configuration

30 iterations · Claude Sonnet 4.6 · 4 parallel
subagents · web search + code execution:

Total: $39.96
Same loop on DeepSeek V4 Flash: $1.85 (95% less)
Caching break-even: 1 run, $23.33/month saved
Sliding window vs full accumulation: 85% savings

Architecture

Pure deterministic math — zero API calls, works
completely offline. Prices pulled live from the
LiteLLM community pricing JSON on page load,
session-cached 6 hours, hardcoded fallback updated
weekly via GitHub Actions. Status badge shows
which layer is active.

The gap: every other cost tool (Langfuse, Helicone,
Braintrust, Bifrost, W&B) is post-hoc observability.
LoopLens is the only pre-run simulator I'm aware of.

Links

Live: looplens-project.vercel.app
Source: github.com/Virerra/looplens
License: MIT

I built a four-view visual workspace with no external UI libraries and a 60fps drag system

Sean — Fri, 26 Jun 2026 14:22:52 +0000

The problem

Every workspace forces one paradigm. Singularity
lets you view the same dataset as a node graph,
kanban board, timeline, and table — simultaneously,
all in sync.

What it does

Six node types (Note, Task, Character, Event,
Research, Location) with labeled directed connections.
Four views of the same data. Change one, update all.

Engineering decisions

No external UI libraries. Every node, edge, panel,
modal, kanban column, timeline row, and table cell
is hand-crafted with inline styles and a shared
design token object.

60fps drag system using requestAnimationFrame with
pointer capture — no React re-renders on every
pointer move event.

Unique IDs via uid(prefix) combining Date.now() and
a monotonic counter — no external library.

Everything in localStorage. No backend, no cloud,
no accounts. Works offline. Ships as a Windows
desktop app via Electron + electron-builder.

Links

Live: singularity-workspace.vercel.app
Source: github.com/Virerra/singularity
License: MIT

I built a free, client-side fact-checker using Claude — BYOK, no backend, four structured checks

Sean — Thu, 25 Jun 2026 10:37:31 +0000

The problem

Most fact-checking tools give you a verdict without explaining the reasoning. That's not useful long-term — users get an answer but no framework for thinking about the next headline themselves.

What I built

Reality Check runs four independent checks on any headline using Claude with live web search:

Source Check — who created this, is the source credible?
Evidence Check — what evidence supports the claim, can it be verified?
Context Check — is this recent and in its original context?
Emotional Check — is the framing designed to manipulate rather than inform?

Each check returns a verdict and reasoning. An overall credibility score from 0–100 summarizes the full picture.

Architecture

Fully client-side. No backend server. No database. No serverless functions operated by me.

BYOK — users supply their own Anthropic API key. It lives only in React component state, never written to localStorage or cookies. Cleared on page close. API calls go browser → api.anthropic.com directly using the anthropic-dangerous-direct-browser-access header.

Stack: React 18 + Vite, Tailwind CSS, claude-sonnet-4-6 with the web_search_20250305 tool (capped at 2 searches per analysis).

Live example

Tested on: "Senate Passes Resolution Directing Trump to End Hostilities With Iran"

Score: 88/100 — Likely Reliable. Source and Evidence both Looks OK (confirmed by NBC, CBS, NPR, PBS, ABC, AP). Context and Emotional flagged as Use Caution — the word "Directs" implies legal compulsion but the resolution is actually symbolic and non-binding. Concept Spotlight: Clickbait.

Technically accurate. Deliberately misleading framing. The tool catches the difference.