Most model launches come with a livestream, a benchmark chart, and a pricing page. ox-alpha got none of that. No announcement post. No model card with an org logo. If you go looking for the team behind it, you will not find one, because the developer is undisclosed.

The model simply exists, it works, and the people using it found it more or less by word of mouth.

This piece is two things at once: a short guide for getting ox-alpha running inside DeepSeek Harness (DSH), and an honest accounting of what we know — and do not know — about the model itself.

Let us start with the mystery, because it is the fun part.

What We Actually Know About ox-alpha

Here is the complete public footprint, as far as anyone can tell:

• It identifies itself only as “ox-alpha,” developed by an undisclosed organization. Ask the model directly who made it and that is the answer. It does not deflect creatively or roleplay an origin story; it just states it and moves on. Whatever the reason — stealth testing, licensing, an acquisition in progress, or pure brand discipline — the anonymity appears deliberate rather than accidental.

• It is a stealth-model generation release. ox-alpha behaves like the models that show up anonymously before their official reveal: strong tool use, long coherent multi-step sessions, and unusually good judgment about when to stop and ask a human a question instead of guessing.

• It is agentic by design, not by bolt-on. The model is clearly built for environments with tools — file editing, shell access, background tasks, subagent delegation. Its responses read like an operator’s log, not a chatbot’s reply. It plans, acts, verifies its own work, and reports back concisely.

That is genuinely most of it. There is no confirmed parameter count, no training-data disclosure, no context-window spec sheet — and, somehow, no bill. At time of writing, stealth/ox-alpha is listed as a free model on OpenRouter, which makes it the strangest bargain in AI: frontier-flavored output, anonymous provenance, zero dollars. In a year when every frontier lab publishes a system card the size of a novella, a model with no paper is either a red flag or the last remaining novelty in AI. I lean toward the second, but hold that loosely.

The Setup: Five Minutes and One API Key

If you already have DSH installed and running, you are most of the way there. If not, start with my earlier walkthrough on setting up DeepSeek Harness itself — this guide picks up right where that one ends.

Adding ox-alpha is almost comically easy. There is nothing to clone, compile, or configure by hand. It is one API key, one provider, and two fields.

Step 1: Create an OpenRouter API key

ox-alpha is served through OpenRouter, so that is your access path. Sign in at openrouter.ai, head to Keys, create a new API key, and copy it somewhere safe. No credit card required: at time of writing, stealth/ox-alpha sits on OpenRouter’s free tier, so there is nothing to fund before your first session. Free models are rate-limited, so very heavy all-day use may eventually want a topped-up account — but for getting started, zero dollars works.

Step 2: Add OpenRouter as a provider in DSH

Open your DSH web console and go into Settings → Models → Add Provider. Select OpenRouter from the list, paste in your API key, and save. This single connection also unlocks every other model on OpenRouter later, so it is worth doing properly even if ox-alpha is all you care about today.

Step 3: Register the model

Now for the moment of truth. In the provider’s customized settings, add a new model with exactly these two values:

• Model ID: stealth/ox-alpha

• Display name: ox-alpha

Click Add Model. Done.

That is genuinely the entire integration. Type the ID carefully — lowercase, one slash, no spaces. The stealth/ prefix is exactly what it sounds like: an anonymous model slot, the same convention used for unreleased models being tested under wraps. There was no handshake, no approval gate, no config file editing. The first time I did it, I kept waiting for a second step that never arrived.

The Vibemark: One-Shot Games and a Portfolio

Benchmarks tell you almost nothing about how an agent feels to use, so I ran my own informal gauntlet — the same starter prompts I throw at every new model.

First up: “clone Flappy Bird.” One shot. Complete, playable game on the first pass — physics, pipes, scoring, collision detection all wired correctly — and it needed only minor tweaking before I was happy with it. Then a Mario-style platformer, another notorious one-shot stress test. Same story: everything came out good on the first attempt, and my entire contribution was small adjustments rather than fixing broken fundamentals.

But the result that actually surprised me was a different kind of build. I used ox-alpha to create a portfolio site, and it came out surprisingly good — the UI is genuinely awesome. Layout, spacing, typography: the design decisions felt considered rather than templated, which is exactly where most agent-generated frontends fall apart. Getting correct logic from a model is expected in 2026. Getting taste is not.

That combination — correct on the first shot and pleasant to look at — changes the shape of the work. Instead of long debugging loops against a stubborn agent, you spend your time nudging. The iteration cycle shrinks from hours to minutes, and that is the whole ballgame for vibe-coding.

Quick Gotchas

Four things that bit me, so they do not bite you:

• The model ID must match exactly: stealth/ox-alpha. If the model does not show up in the picker after adding it, the ID string is almost always the culprit.

• Free means rate-limited. ox-alpha costs nothing right now, but free-tier routing comes with usage caps. If requests start erroring partway through a busy day, you have probably hit the limit — wait it out or top up your account.

• Your workspace choice matters. It defines where the agent is allowed to read and write, so pick your project root when creating the session.

• Keep approvals on. DSH’s permission prompts rarely fire with this model — it tends to route risky actions through explicit requests on its own — but you want the fence up before the first incident, not after.

Should You Bother?

If you enjoy being an early user of things that have not been explained yet — yes. Five minutes of setup and exactly zero dollars buys you an anonymous but conspicuously capable model, running inside a harness whose guardrails you control, working in your own folders on your own machine.

If you need a vendor to sue when something goes wrong, wait. There is no roadmap, no SLA, and no support forum. Stealth cuts both ways: nobody can take ox-alpha’s promises away from you because nobody has made any. The model’s work is the only claim it makes, and so far, on my repos, the claims are holding.

AI coding has already moved beyond model-only comparisons. The harness—the tools, context management, permissions, memory, and agent loop surrounding the model has become one of the field’s biggest talking points.

Against that backdrop, I tried DeepSeek Harness—or DSH—with DeepSeek V4 Flash through OpenRouter. It is one of the clearest examples I have encountered of why the pairing matters as much as the individual components. More bluntly: DeepSeek V4 Flash and DSH are a killer combination.

The model matters. But the harness may matter almost as much.

My early experience with this combination has been genuinely excellent. DSH gives the model a coherent environment in which to inspect a project, use tools, maintain a plan, make changes, and keep working through a task. DeepSeek V4 Flash supplies the speed and reasoning. OpenRouter makes the model easy to route into the setup.

Connecting a provider is also refreshingly straightforward. For a supported provider—or a custom OpenAI-compatible service such as OpenRouter—you mainly provide the API key and select the models you want to use. DSH keeps the harness separate from the model backend, so experimenting with another provider does not require rebuilding the rest of the agent.

This is not a formal benchmark, and I am not claiming that a few good sessions settle the coding-agent leaderboard. DSH is also explicitly labeled a developer preview. But it already demonstrates something important: raw model intelligence is only one part of an effective agent.

The model is not the product

A language model can propose code. A useful coding agent has to do much more.

It needs to understand the workspace, decide which files matter, call tools, inspect their results, recover from mistakes, preserve state, ask for approval when an action is risky, and continue until the task is actually complete. It needs a loop—not just a prompt.

That surrounding system is the harness.

An easy analogy is that the model is an engine. Benchmarks tell us something about horsepower. The harness supplies the steering, transmission, brakes, dashboard, and road connection. A more powerful engine in a weak vehicle can still be frustrating. A well-designed vehicle can make an efficient engine feel remarkably capable.

DSH makes that surrounding layer unusually visible because its central design principle is simple: everything is a plugin.

According to the project’s architecture documentation, even the model adapter, tool registry, session log, and agent loop are plugins. There is no sacred core that must be patched every time somebody wants to change the behavior. Components are mounted into a shared Cordis context and can be replaced through configuration.

That is more than an extensibility slogan. It is a bet on how agent software will evolve.

“Everything is a plugin” is the real story

Most coding agents let you add a tool or connect an MCP server. DSH goes deeper: the agent itself is assembled as a tree of replaceable capabilities.

The default base layer includes model adapters, tools, persistence, sandboxing, approval policy, settings, credentials, and telemetry. A web bundle adds the browser-based interface. A headless bundle adds a one-shot runner without a server. Profiles compose these pieces, while configuration patches can replace individual rows in the resulting tree.

In practical terms, this means the model provider is not welded to the rest of the product. Neither is the filesystem, subprocess runner, terminal, sandbox, subagent implementation, or UI.

That separation matters for three reasons.

First, it makes experimentation much easier. You can keep the working environment and change the model, or keep the model and change the tools and policies around it. That is a much cleaner way to learn what is actually responsible for an improvement.

Second, it creates room for specialized agents. A security-review profile does not need the same tools or approval rules as a rapid prototyping profile. A remote sandbox should be swappable without rewriting every tool that depends on it.

Third, it reduces dependence on a single model vendor. DSH includes catalog providers and supports custom OpenAI-compatible endpoints, which makes a service such as OpenRouter especially useful. Add the provider, enter the API key, select the available models, and they appear in DSH’s model picker. The surrounding tools, workspace, permissions, and agent loop stay in place while you change the model behind them.

The architecture also treats the session log as the source of truth. Model-visible context must be reconstructable from durable events. Forking, resuming, transcripts, replay, and persistence can all derive from that stream. This is the sort of plumbing users rarely celebrate, but it is exactly what makes a long-running agent feel dependable rather than magical and fragile.

Why DeepSeek V4 Flash and DSH are a killer combination

I connected DSH to deepseek/deepseek-v4-flash through OpenRouter. OpenRouter describes V4 Flash as the efficiency-oriented member of the V4 family, with a mixture-of-experts design, 13 billion active parameters out of 284 billion total, and a one-million-token context window.

At the time of writing, OpenRouter lists the headline price at just $0.06 per million input tokens and $0.13 per million output tokens, although the provider selected and effective caching can change the final rate. At that price, DSH can afford to use the model as an agent rather than treating every request as a precious one-shot answer.

That distinction is crucial. A harness consumes tokens while it explores files, reasons about the next action, reads tool results, revises a plan, and verifies its work. With an expensive model, those loops can turn a modest coding task into a surprisingly large bill. V4 Flash changes the economics: the iterative behavior that makes DSH useful is also behavior you can afford to use freely.

Those specifications are useful, but they are not what made the setup click for me.

What stood out was the balance. The model felt quick enough that the tool-use loop did not become tedious, yet capable enough that the loop remained productive. That matters because agentic coding is not one giant answer. It is a sequence: inspect, decide, act, observe, correct, verify. Latency compounds across every step.

A fast model that constantly needs rescuing is not cheap. A brilliant model that makes every iteration feel heavy is not always pleasant. In my early use, V4 Flash inside DSH landed in a compelling middle ground: fast, capable, and remarkably inexpensive.

Again, that is an experience report, not a controlled comparison. Different repositories, providers, prompts, and permission settings can produce different results. OpenRouter may also route across providers, so performance and availability can vary. But the combination was good enough that I stopped thinking about whether the model could use the harness and started thinking about what I could build with it.

That is usually the sign that a tool is working.

Getting the same setup running

The official quick start is refreshingly small. With a current Node.js installation, launch the web interface with:

npx @deepseek-ai/dsh web

DSH serves the interface locally at

http://127.0.0.1:3080

by default.

For a direct DeepSeek connection, Settings → Models accepts a DeepSeek API key. Other supported providers follow the same basic pattern: add the provider, supply its API key or native credential, and select the models you want. Model changes take effect on the next request without restarting DSH.

After saving, choose deepseek/deepseek-v4-flash from the model picker. That is essentially the whole connection process: API key in, models selected, and the provider is ready to use.

Then choose a workspace and start a new session. DSH can read and edit workspace files, run commands, delegate work, and maintain a plan. Its web interface asks for approval when an operation requires it under the active permission policy.

The official model configuration guide is worth keeping nearby because DSH is changing quickly and configuration details may move.

What I would be careful about

DSH is promising, but “developer preview” should be taken literally. DeepSeek warns that compatibility-breaking changes will happen. This is a project to explore and build on, not yet a tool I would quietly insert into a critical production workflow and forget.

I would also start with a disposable branch and conservative permissions. Any coding agent that can edit files and run commands deserves the same operational caution as a capable new collaborator: constrain its workspace, review important diffs, protect credentials, and keep destructive actions behind approval.

Finally, do not confuse a flexible provider layer with identical results across providers. The model name may be the same while latency, caching, tool-call behavior, and uptime differ. If the setup matters to your work, measure the route you actually use.

The bigger shift: from model selection to system design

DSH arrives at the right moment. Open models are improving quickly, and access to them is becoming interchangeable. That makes the surrounding system more valuable, not less.

The next useful question may not be, “Which model is best?”

It may be:

Which combination of model, tools, memory, permissions, context policy, and agent loop is best for this job?

DeepSeek Harness is an attempt to make that entire combination editable.

That is why I find it more interesting than another model-specific coding interface. DSH is not merely a shell around DeepSeek. It is a proposal for how agent software should be composed: small capabilities, explicit seams, durable state, and replaceable parts.

And increasingly, motion is what matters.

DeepSeek Harness is open source under the MIT license. It is currently in developer preview and evolving rapidly.

The most important AI infrastructure announcement of the month might not be a new model, a new benchmark, or another “agent platform.” It might be a folder full of Markdown files.

On June 12, Google Cloud introduced the Open Knowledge Format, or OKF, a draft specification for turning organizational knowledge into plain-text files that both humans and AI agents can read. The pitch is almost aggressively unsexy: Markdown files, YAML frontmatter, normal links, ordinary folders.

And that is exactly why it is interesting.

The agent boom has created a strange bottleneck. Models are getting better. Tool-calling is getting more reliable. Protocols like MCP are making it easier for agents to connect to external systems. But the knowledge those agents need — what a metric actually means, which table joins to which, how an internal process works, why a dashboard number changed last quarter — is still scattered across wikis, data catalogs, shared drives, code comments, Slack archaeology, and the heads of senior employees.

Google’s bet with OKF is simple: before every company builds yet another proprietary knowledge layer for agents, maybe we should agree on a boring file format first.

What Google Actually Announced

Google Cloud published OKF v0.1 as an open, vendor-neutral specification for representing knowledge as a directory of Markdown documents with YAML metadata at the top.

The official Google Cloud blog describes OKF as a way to formalize the “LLM-wiki” pattern popularized by Andrej Karpathy: a living library of Markdown files that language models can read, update, cross-reference, and maintain over time. If you have seen AGENTS.md, CLAUDE.md, Obsidian vaults connected to coding agents, or internal “metadata as code” repos, you already understand the shape.

OKF tries to make that shape interoperable.

A compliant OKF bundle is basically:

• Just Markdown — readable in any editor and renderable on GitHub.

• Just files — shippable as a repo, tarball, zip, or mounted folder.

• Just YAML frontmatter — a small structured metadata block for fields agents may need to filter or route on.

There is no required SDK. No hosted runtime. No central schema registry. No Google account required to read the files. The spec is available in the public GoogleCloudPlatform/knowledge-catalog GitHub repository, under Apache-2.0, and the parent repository had 5,496 stars and 420 forks at the time I checked.

Google also shipped more than just a PDF-style proposal. The repo includes:

• The OKF v0.1 draft specification.

• A reference enrichment agent that can walk a BigQuery dataset and generate OKF concept documents.

• A static HTML visualizer that turns an OKF bundle into an interactive graph.

• Three sample bundles: GA4 e-commerce, Stack Overflow public data, and Bitcoin public datasets.

• Integration work showing Google Cloud’s Knowledge Catalog ingesting OKF and serving it to agents.

That last bullet matters. Google is not only saying “here is a neat open format.” It is also making OKF legible to its own data/agent stack.

The Problem: Agents Are Context-Starved

The easiest mistake in AI right now is assuming the model is the product.

In practice, the model is often the least company-specific part of the system. The real value lives in context:

• What does “active user” mean in this company?

• Which BigQuery table is the source of truth?

• Which dashboard is deprecated but still indexed by search?

• What API endpoint should an internal agent call for refunds?

• Which incident runbook applies when the data freshness alert fires?

• Why should nobody join table A to table B without filtering deleted records?

Humans learn these things through onboarding, tribal knowledge, scars, and long-running Slack threads. Agents do not. They need the knowledge written down in a form they can consume.

Today that context is fragmented across systems with different permissions, formats, exports, and APIs. Every agent builder ends up solving the same context-assembly problem: scrape the wiki, query the catalog, chunk the docs, index the PDFs, ask a senior engineer, pray the answer is current.

Google’s framing is useful here: the missing piece is not necessarily another knowledge service. It is a format.

If knowledge can be represented in a stable, portable way, then producers and consumers can separate. A data catalog can export OKF. A documentation team can maintain OKF. An agent can consume OKF. A visualizer can render OKF. A search system can index OKF. None of them have to be the same vendor.

That is the dream, at least.

How OKF Works in Plain English

An OKF bundle is a folder. Inside that folder are Markdown files. Each Markdown file represents one “concept.”

A concept can be a table, dataset, metric, API, playbook, runbook, policy, business definition, or any other unit of knowledge worth naming.

Each concept file starts with YAML frontmatter:

---
type: BigQuery Table
title: Customer Orders
description: One row per completed customer order across all channels.
resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders
tags: [sales, orders, revenue]
timestamp: 2026-05-28T14:30:00Z
---

# Schema

| Column | Type | Description |
|---|---|---|
| order_id | STRING | Unique order identifier. |
| customer_id | STRING | Links to the customers table. |
| total_usd | NUMERIC | Order total in US dollars. |

# Joins

Joined with [customers](/tables/customers.md) on `customer_id`.

# Citations

[1] [BigQuery table schema](https://console.cloud.google.com/)

The only required field is type. Everything else — title, description, resource, tags, timestamp — is recommended but optional.

That is a subtle but important design choice. Google is not trying to define a universal taxonomy for every kind of business knowledge. It is saying: every concept should at least identify what kind of thing it is, but producers can invent their own types, sections, and fields.

Consumers are expected to be tolerant. Unknown types should not break a bundle. Missing optional fields should not break a bundle. Broken links should not break a bundle. That permissive model makes OKF feel less like a strict enterprise schema and more like a web-native convention.

The folder can also include two reserved filenames:

• index.md — a directory listing that helps humans or agents browse progressively instead of loading everything at once.

• log.md — an optional chronological history of updates.

Concepts link to one another with ordinary Markdown links. Over time, those links create a lightweight knowledge graph without requiring a graph database.

That is the whole trick.

Why “Just Markdown” Is Not a Cop-Out

It is tempting to dismiss OKF as too simple. Markdown plus frontmatter? We have had that forever. Obsidian users are already doing this. Static site generators have done this for years. Developer docs have lived this way since before “agentic AI” was a job title.

But that is also the point.

The most successful infrastructure standards often look obvious in hindsight. They win because they reduce coordination cost, not because they are technically exotic.

OKF’s appeal comes from a few practical properties:

1. It is human-readable. An engineer, analyst, or technical writer can open the file without special tooling. That matters because agent knowledge should not become an invisible embedding soup nobody can audit.

2. It is version-controllable. Put OKF in Git and suddenly knowledge has diffs, reviews, blame, rollback, and pull requests. “Why did the agent think weekly active users excluded trial accounts?” becomes a reviewable knowledge-change question, not a mystery inside a vector database.

3. It is portable. A folder can move between systems. A proprietary catalog export often cannot.

4. It is agent-friendly. Markdown gives models headings, lists, tables, code blocks, citations, and links. YAML gives tools enough structure to filter and route without over-engineering the content model.

5. It keeps prose and metadata together. This is underrated. Many enterprise systems split structured metadata from the explanation humans actually rely on. OKF puts the machine-readable and human-readable layers in the same artifact.

For AI agents, this matters because the hard part is rarely “can the model read a paragraph?” The hard part is “can the model find the right paragraph, understand its relationship to other concepts, and update the knowledge without destroying the structure?”

OKF is trying to make that boring workflow normal.

The Bigger Pattern: AI Needs Shared Knowledge Surfaces

OKF fits into a wider shift in agent infrastructure.

Over the past year, the industry has started separating three layers that were previously jammed together:

• Tools: What can the agent do?

• Protocols: How does the agent access tools and communicate?

• Knowledge: What does the agent know before it acts?

MCP helps with the “how does the agent access tools?” question. Agent-to-agent protocols try to answer “how do agents coordinate?” OKF is aimed at a different layer: what portable knowledge representation should agents consume?

That distinction is useful. OKF does not replace MCP. It complements it. An MCP server could expose an OKF bundle. A coding agent could read an OKF bundle before touching a repo. A data assistant could consult OKF documents before generating SQL. A governance tool could scan OKF for stale resources or missing citations.

The interesting possibility is not that Google owns the agent knowledge layer. It is that Markdown-based knowledge bundles become a shared artifact across tools.

If OKF catches on, a company could maintain one curated knowledge base and let many agents consume it: Gemini, Claude, Cursor-style coding agents, internal assistants, BI copilots, search systems, and visualizers.

That is the part worth paying attention to.

The Honest Caveats

OKF is promising, but it is not magic.

First, v0.1 is a draft, not a mature standard. Google explicitly calls it a starting point. The spec is short, permissive, and intentionally minimal. That is good for adoption, but it also means teams will still make many local decisions: naming conventions, type taxonomies, body sections, review workflows, freshness policies, and permission models.

Second, Markdown does not solve knowledge quality. If your internal docs are stale, contradictory, or politically contested, OKF will faithfully preserve that mess in a nicer folder. A portable wrong answer is still a wrong answer.

Third, security and access control are outside the format. A folder of Markdown files is easy to move, but enterprise knowledge often contains sensitive data, internal URLs, customer context, and operational runbooks. OKF can fit into a secure workflow, but it does not provide one by itself.

Fourth, “no SDK required” does not mean “no tooling needed.” At small scale, humans can maintain OKF manually. At enterprise scale, you will want exporters, validators, link checkers, review policies, freshness checks, and probably agents that draft updates. Google’s reference agent and visualizer are useful proofs of concept, but they are not a full knowledge-management product.

Fifth, the Google Cloud connection is both a strength and a risk. Google publishing OKF in the open gives it credibility and distribution. But for a vendor-neutral standard to become truly neutral, it needs adoption outside Google’s ecosystem: other clouds, catalog vendors, agent frameworks, documentation tools, and open-source communities.

The good news: the spec is licensed openly, designed around ordinary files, and explicitly welcomes alternative implementations. That gives it a real chance.

What This Means for Builders

If you are building agents, OKF is worth studying even if you never adopt the spec directly.

The underlying lesson is that agents need curated, navigable, reviewable context — not just a bigger context window and a pile of embeddings.

A practical OKF-style workflow might look like this:

1. Start with one painful domain: analytics definitions, incident runbooks, product APIs, customer-support policies, or repo-specific engineering knowledge.

2. Create one folder of Markdown concept files.

3. Add only the metadata that matters: type, title, description, tags, source URI, timestamp.

4. Link related concepts with normal Markdown links.

5. Store the bundle in Git.

6. Review knowledge changes like code changes.

7. Let agents read from the bundle before acting.

8. Add automation only after the human-maintained version proves useful.

That last point matters. The fastest way to ruin a knowledge system is to over-automate before the structure is trusted. OKF is most compelling when it starts as a readable wiki and gradually becomes an agent-maintained knowledge substrate.

The Takeaway

Google’s Open Knowledge Format is not flashy. It will not demo like a new image model or trend like an autonomous coding agent. It is a draft spec for Markdown files with YAML frontmatter.

But in the agent era, boring standards may be where the leverage is.

Models are improving fast. Agents are getting tools. What they still lack is a shared, portable, inspectable way to carry organizational knowledge across systems. OKF is one serious attempt to define that layer before every vendor locks it into their own platform.

The claim is modest: knowledge should be readable by people, parseable by agents, versioned like code, and portable across tools.

The implication is much bigger: the next competitive advantage in AI may not be who has the biggest model. It may be who has the cleanest, most current, most agent-readable knowledge base.

And if that knowledge base is just a folder of Markdown files, maybe that is not boring at all.

Sources: Google Cloud’s announcement, “How the Open Knowledge Format can improve data sharing”; the public GoogleCloudPlatform/knowledge-catalog OKF repository; OKF SPEC.md; coverage from Search Engine Journal

Claude Design is the shiny new tool everyone is talking about. Launched by Anthropic in April 2026, it turns conversation into polished visuals: pitch decks, landing pages, prototypes, social assets. It is slick. It is also locked behind a Claude Pro subscription and locked to Anthropic models. If you want to use a cheaper model, a local model, or even just keep your design files on your own machine, you are out of luck.

I wanted an alternative that gave me the same creative power without the walls. So I downloaded OpenDesign, connected my own Kimi API key, and used it to prototype Pulse — a personal finance and subscription tracking app. No terminal commands. No IDE plugins. Just a desktop app, an API key, and a brief.

The results were genuinely promising.

What Is OpenDesign?

OpenDesign is a free, open-source desktop app that turns AI agents into design collaborators. It is built by the team behind open-design.ai and licensed under Apache-2.0, which means anyone can use it, fork it, or extend it without paying a license fee.

At the time of writing, the latest stable release is v0.9.0 (released June 2, 2026). The app is available for macOS (both Apple Silicon and Intel), Windows, and Linux. There is no subscription required. You download it, install it, and bring your own API keys. That is it.

Here is what ships inside the box:

• 155 built-in skills — these are file-based instruction bundles the agent loads mid-task. They cover everything from copywriting and color theory to creative direction, brainstorming, code migration, and exporting your work to Next.js, React, or Vue.

• 150 portable design systems — think Linear, Vercel, Stripe, Apple, Cursor, Figma-style systems, all packaged as portable DESIGN.md files. Drop one in and your agent knows your brand rules instantly.

• 17 agent adapters out of the box — the app connects to Claude Code, Codex, Cursor, Gemini CLI, Kimi, DeepSeek, Qwen, GitHub Copilot CLI, Grok, Hermes, Devin for Terminal, OpenCode, Pi, Mistral Vibe, Kiro, Kilo, and Qoder. If you already use one of these, OpenDesign plugs right in.

• 5 deterministic visual directions — when you start a project, the app surfaces five structured visual routes. You pick the palette, typography, density, and layout posture up front so the agent is not guessing.

• Export to HTML, PDF, PPTX, ZIP, or Markdown — whatever you generate is a real file on your machine, not a hosted document in someone else’s cloud.

Setting Up OpenDesign in Under 10 Minutes

Getting started is surprisingly simple. I downloaded the macOS DMG directly from open-design.ai. It is a 238 MB download for Apple Silicon. Double-click, drag to Applications, and launch.

When the app first opens it asks you to connect an agent. This is where OpenDesign differs from Claude Design. Instead of forcing you into one provider, it shows a list of adapters and asks you to drop in your own API key.

I already had a Moonshot Kimi API key from a previous project. I pasted it into the OpenAI compatible adapter field, hit save, and the daemon connected immediately. There was no credit card required for OpenDesign itself. The only cost is whatever the LLM provider charges you for tokens.

If you prefer DeepSeek, Qwen, Claude, or even a self-hosted model running on your own server, the process is identical. OpenDesign speaks the standard OpenAI-compatible API format, so any provider that supports that protocol works. You can even switch models mid-project by swapping the adapter in settings.

Building Pulse: From Idea to Prototype

Pulse is a smartphone app concept I have been kicking around for a while. The idea is simple: a clean, personal finance dashboard that tracks subscriptions, upcoming renewals, and monthly burn rate. I wanted something that felt modern, mobile-first, and genuinely useful.

In OpenDesign, I started a new project and selected the Prototype use case. Turn one is a short question form: surface, audience, tone, scale, and brand context. I filled it out in about thirty seconds — mobile app, personal finance, calm and trustworthy, high fidelity, no existing brand.

Using the interactive prototype skill, it built a working, clickable HTML prototype that behaved like a real app. The output included:

• A dashboard view with upcoming subscription charges and countdown timers

• Category breakdown cards for spending visualization

• A monthly burn rate summary with color-coded urgency flags

• Settings and profile views accessible through tab navigation

• Touch targets sized properly for actual thumbs (minimum 44px)

The entire prototype was a self-contained HTML file I could open in any browser, share via a link, or hand off to a developer as a reference. Because OpenDesign runs the agent locally and writes files directly to my project directory, I owned the output from minute one.

What impressed me most was the taste. The agent did not default to generic rounded-corner cards with gradient overload. Instead it matched the visual direction I selected and held the palette and typography consistent across every screen. When I asked for a second variant with lighter tones, it preserved the component structure and just swapped the CSS variables

Why I Connected Kimi Instead of Claude

The obvious question: why not just use Claude Design with Claude? Three reasons, and they all come down to flexibility and cost.

Price. Kimi charges a fraction of what Claude costs for the same design-generation workload. For prototyping and exploration, where you might iterate ten or twenty times before landing on a direction, that gap adds up fast. OpenDesign passes your API costs straight through with no markup, so the savings are real.

No lock-in. With Claude Design, you are tied to Anthropic. If they change pricing, sun a feature, or experience an outage, you have no alternative. With OpenDesign, I can switch from Kimi to DeepSeek to Qwen to a local model without reinstalling anything. It is a settings change, not a platform migration.

Local models. OpenDesign supports self-hosted endpoints. If you are running vLLM, SGLang, or any OpenAI-compatible server on your own hardware and generate designs without ever sending a prompt to the cloud. For sensitive projects or air-gapped environments, that is a game-changer.

If you are curious about the Kimi workflow specifically, has a practical walkthrough on getting the most out of Kimi for design and coding tasks: How to Use Kimi K2.6 — The Best Open-Source LLM in the World (And Why Most Knowledge Workers Should). It is what pointed me toward using Kimi as a creative agent in the first place.

The Numbers That Matter

When I compare tools I like to look at hard figures. Here is how OpenDesign stacks up in my experience:

• Setup time: Under 10 minutes from download to first generated artifact.

• Skills available: 155 file-based skills, auto-loaded when the daemon boots.

• Design systems: 150 portable DESIGN.md systems, including major tech and editorial brands.

• Agent adapters: 17 first-party BYOK adapters, plus any OpenAI-compatible provider.

• Supported models: 20+ flagship models via the optional AMR gateway, including GPT, Claude, Gemini, DeepSeek, and Kimi.

• Export formats: HTML, PDF, PPTX, ZIP, Markdown.

• Cost: The app is free (Apache-2.0). You only pay for the API tokens you consume.

How the Workflow Actually Feels

OpenDesign follows a four-step loop: Detect, Discover, Direct, Deliver.

Detect. The daemon scans your system for installed agents, loads all 155 skills and 150 design systems, and presents them in the web UI. Everything is local. Nothing phones home to an OpenDesign server.

Discover. Turn one of any project is a structured intake form. Instead of throwing a vague prompt at a black box, you answer specific questions about audience, tone, fidelity, and brand. It takes under a minute and eliminates the “make it look professional” ambiguity that usually wastes three rounds of revision.

Direct. You pick one of five deterministic visual directions. Palette is defined in OKLch color space. Font stack, layout posture, and density cues are locked in. The agent now has a concrete brief instead of a guessing game.

Deliver. The agent writes files to disk. You preview them in a sandboxed iframe inside the app. When you are happy, you export. There is no waiting for a cloud render, no export watermarks, and no file format restrictions.

Who Is This For?

OpenDesign is built for solo builders, designers, engineers, product managers, and marketers who want AI-generated design without giving up ownership. If you fit any of these descriptions, it is worth a look:

• You want to prototype fast without learning a new design tool.

• You already use Claude Code, Cursor, Codex, or Kimi and want a visual layer on top.

• You care about cost and want to use cheaper models for exploration.

• You need to keep your work local for privacy or compliance reasons.

• You want editable files (HTML, PPTX, PDF) instead of locked cloud documents.

Getting Started Yourself

If you want to try OpenDesign, the path is simple:

1. Go to open-design.ai and download the desktop app for your platform.

2. Launch it and connect your preferred agent adapter. Kimi, DeepSeek, Claude, Qwen, or a local endpoint all work.

3. Start a new project, answer the intake form, pick a visual direction, and let it run.

4. Preview the output, iterate in chat, and export when you are done.

No terminal required. No IDE plugin. No subscription.

The Bottom Line

Claude Design proved that AI-driven design generation is ready for mainstream use. OpenDesign proves that you do not need to rent that capability from a single vendor.

Building Pulse with OpenDesign was the first time I felt like I had a professional design collaborator on my machine, working with the model I chose, generating files I owned, at a cost I controlled. The prototype came out clean, cohesive, and ready to hand off.

If you are currently paying Claude Pro just to access design features, or if you want to experiment with cheaper models like Kimi and DeepSeek without platform lock-in, OpenDesign is the most credible open alternative available today. Download it, plug in your API key, and see what you can build in the next ten minutes.

MiniMax M3, launched June 1, 2026, is more interesting than the usual launch cycle. It combines three things that normally do not arrive together in an open-weights release: strong coding and agentic benchmarks, a 1 million token context window, and native multimodal input across text, images, and video.

The careful wording matters. At launch, M3 was not yet downloadable as weights. MiniMax said it would release the technical report and model weights within roughly ten days, and its Hugging Face organization still did not list an M3 model in the first week. So the right claim is not “open weights have shipped.” It is: MiniMax has launched the hosted M3 API and made a near-term open-weights commitment.

That is still a big deal if the promise lands cleanly.

Here is the story, with the caveats left visible.

What M3 Actually Is

MiniMax M3 is a hosted, natively multimodal model that accepts text, image, and video input and outputs text. MiniMax positions it as the first open-weight model to combine frontier coding, efficient 1M-token context, and native multimodality in one system.

The headline spec is the 1 million token context window, but the more important engineering claim is how MiniMax makes that window usable.

The key feature is MiniMax Sparse Attention (MSA). Previous MiniMax M2-series models, including M2.7, leaned away from sparse attention because the production infrastructure was not mature enough. M3 brings sparse attention back with a block-selection design: a lightweight index path scores incoming tokens, identifies the key-value blocks most relevant to each query, and runs the expensive attention computation only on those selected blocks.

Simple analogy: instead of rereading an entire 1,500-page book every time you answer a question, MSA first checks the index, finds the 20 pages that probably matter, and reads those carefully.

MiniMax says this preserves attention over real, uncompressed key-values rather than compressing the key-value cache into a latent representation. The intended tradeoff is straightforward: keep much of the precision of ordinary attention, but cap how many tokens each query must attend to.

At 1M context, MiniMax claims M3 reduces per-token compute to roughly one-twentieth of the prior generation, with more than 9x faster prefill and more than 15x faster decode. Those are MiniMax numbers, not yet independently reproduced at scale, but they are central to why M3 is worth watching. A 1M window on a spec sheet is not the same thing as a 1M window you can afford to use interactively.

Together AI, MiniMax’s preferred cloud partner for M3, published an engineering deep dive on what it took to serve the model. Their work included a KV-Block-Major sparse attention kernel, a paged-attention integration for MSA, a Rust-based multimodal preprocessing gateway, and an optimized index-scoring kernel. Together reports 81-125% throughput improvements across concurrency levels versus its unoptimized baseline.

That is partner-authored evidence rather than neutral verification, but it is still useful: it shows M3 is not just a model-card announcement. There is real serving work behind it.

The Three-Frontiers Claim

MiniMax markets M3 as the first open-weight model to bring together three frontier capabilities:

1. Coding and agentic performance competitive with strong closed models

2. 1M-token context made practical through sparse attention

3. Native multimodality across text, image, and video input

The coding claim is the easiest to scrutinize, because it has benchmarks and public evaluations. The long-context and multimodal claims are harder, because they depend heavily on serving infrastructure, latency, reliability, and real workloads.

The Benchmark Numbers, Carefully Read

MiniMax’s launch reporting puts M3 at:

• SWE-Bench Pro: 59.0%

• SWE-Bench Verified: 80.5%

• Terminal-Bench 2.1: 66.0%

On MiniMax’s own comparison, the SWE-Bench Pro score puts M3 behind Claude Opus 4.7, close to GPT-5.5, and ahead of Gemini 3.1 Pro. That is a serious result for an open-weights-designated model.

But this is where the squint belongs. MiniMax discloses that several evaluations were run on internal infrastructure, often with agent scaffolding such as Claude Code, Mini-SWE-Agent, or Terminus. Some baselines were taken from official leaderboards, while others were tested by MiniMax. That does not make the numbers fake. It does mean they are not the same as a clean, independent, apples-to-apples leaderboard run.

Independent coverage is starting to appear. Artificial Analysis now lists MiniMax-M3 at 7th on its Intelligence Index, with a score of 55, while also noting that the model is unusually verbose and expensive to evaluate. That is an important outside signal, but some vendor-claimed benchmark results remain marked as not yet independently verified. LMArena and other neutral boards are still worth watching over the next few weeks.

One more caution: M3 should not be treated as proven across all reasoning domains. Early third-party and community feedback points to familiar risks for reasoning-heavy agent tasks: verbosity, slow loops, and token-heavy self-correction. That does not erase its coding performance, but it does suggest the model is better described as a strong coder and agent than as a general novel-reasoning breakthrough.

The Pricing Disruption

Here is the number that changes the economics: $0.60 per million input tokens and $2.40 per million output tokens at standard pricing, with a 50% launch discount visible through some providers in the first week.

OpenRouter and Qubrid list M3 at $0.30 per million input tokens and $1.20 per million output tokens during the promotional period. OpenRouter shows a 1M context window. Qubrid also exposes M3 through an OpenAI-compatible endpoint with image input examples.

Compared with closed frontier models, the gap is large. OpenAI lists GPT-5.5 at $5 per million input tokens and $30 per million output tokens. Anthropic lists Claude Opus 4.7 and Opus 4.8 at $5 per million input tokens and $25 per million output tokens. On raw token price, M3 is dramatically cheaper.

The catch is effective cost per task. A model that loops, over-plans, or emits long reasoning traces can burn a lot of tokens even if each token is cheap. For agentic workloads, you should measure completed task cost, not just input and output rates.

The other pricing caveat is context length. MiniMax says requests up to 512K input tokens use the standard rate, while longer requests are billed at a higher long-context rate. The 1M window is real as a capability claim, but the cheapest advertised rate may not apply to every 1M-token workload.

How to Access MiniMax M3

MiniMax API – direct from the source.
MiniMax’s official examples use https://api.minimax.io for M3. This is the right path if you want direct access to MiniMax’s own hosted model and native multimodal features.

OpenRouter – fastest testing path.
OpenRouter lists minimax/minimax-m3 with promotional pricing, a 1M context window, and OpenAI-compatible access. If you want to test quickly without adding another vendor integration, this is the cleanest route.

Together AI – production serving once weights are public.
Together AI says it is MiniMax’s preferred cloud partner and will host the open-weights model as a developer endpoint after public release. Given the amount of inference engineering Together has already published, this is the infrastructure path to watch for scale.

Qubrid AI – another hosted endpoint.
Qubrid lists MiniMaxAI/MiniMax-M3, OpenAI-compatible access, image input examples, and promotional pricing. It is a viable hosted option if Qubrid already fits your stack.

OpenCode / Pi – free trial lane, with limits.
MiniMax M3 Free appears in the OpenCode/Pi ecosystem, but the listed free model has a 200K context window, not the full 1M window. It is useful for trying the model, not for validating the full long-context claim.

Quick integration checklist:

• Start with OpenRouter if you want to test in minutes.

• Use MiniMax directly if you need first-party multimodal behavior.

• Watch Together AI once the weights are public and you need optimized serving.

• Treat OpenCode/Pi free access as a limited trial lane, not a full 1M-context evaluation.

The Strategic Implication

The important thing M3 suggests is that the capability gap between closed and open models may be narrowing faster than the pricing gap.

If MiniMax releases the weights on schedule, if the license is usable, and if independent benchmarks broadly support the launch numbers, M3 becomes an obvious candidate for hybrid AI stacks: route cost-sensitive, long-context, bulk coding and document work to M3, then reserve GPT-5.5, Claude Opus, or Gemini for tasks where their last few quality points are worth the premium.

That is a real threat to closed-model pricing, but not because M3 has conclusively beaten the closed frontier. It has not. The threat is subtler: once an open-weights model is close enough on valuable work, the premium model has to justify every extra dollar.

The Bottom Line

The combination of coding quality, 1M-context architecture, native multimodality, and low token pricing is genuinely unusual. If the weights and license arrive cleanly, MiniMax will have done more than publish another strong model. It will have made open-weights routing a serious production question.

For years, the open-weights conversation was mostly about catching up. M3 suggests the next phase may be about allocation: which model you use for which job, based on latency, modality, context length, license, and total task cost.

The frontier did not get overthrown this week. But it did get a much cheaper neighbor with a very large context window.

Have you run M3 through your own tasks? Share your real-world results in the comments.

What feels more important is the philosophy behind it.

Mellum started as a model focused on code completion inside JetBrains IDEs. Mellum 2 is broader: it can help with code generation, debugging, editing, tool use, routing, and agent-style workflows. But JetBrains is not trying to pitch it as the biggest, most magical model on the market.

Instead, the pitch is more grounded: make a model that is fast, efficient, open, and useful inside real developer workflows.

That feels right to me. A lot of AI tooling still behaves as if every problem should be sent to one giant model. But software work is full of smaller tasks: summarize this context, choose the right tool, check this change, explain this function, help an agent take the next step. Those jobs do not always need the largest model. They need something quick and reliable.

That is where Mellum 2 is interesting. It points toward a future where developer AI is not one big chatbot sitting next to the IDE, but a system of smaller, specialized pieces working quietly inside the tools we already use.

JetBrains has always cared about the shape of a developer’s day: autocomplete, refactoring, navigation, inspections, tests. Mellum 2 feels like an extension of that same instinct. Not AI as theater. AI as part of the workflow.

And honestly, that might be the version of AI developers actually keep using.

Sources: JetBrains’ Mellum2 announcement

“Upload a PDF and ask questions.”

But anyone who has tried to build that locally knows the truth: the hard part is not always the LLM. Very often, the hard part is getting clean, useful text out of messy documents.

PDFs are especially annoying. They come with headers, footers, page numbers, tables, scanned pages, broken lines, and strange spacing. And real life is not only PDFs either. People have Word files, PowerPoint decks, spreadsheets, CSVs, images, notes, and manuals.

That is why I wanted to try LiteParse.

LiteParse gives the project a fast local document parsing layer. It can handle PDFs and other common document types without needing to send files to a cloud service. That matters a lot if you care about privacy, speed, or just having a workflow that runs on your own machine.

Once the documents are parsed, the rest of the app becomes much easier to reason about. The text can be split into smaller pieces, embedded, stored locally, and searched when a user asks a question.

For storage and search, I used Zvec. It keeps the project lightweight because I do not need to run a separate vector database server.

For answers, I used Gemma 4 through Ollama.

I like this setup because each tool has a clear role. LiteParse handles the messy documents. Zvec handles local retrieval. Gemma 4 turns the retrieved context into a readable answer.

The result is a small local RAG app that feels practical instead of overbuilt.

What It Feels Like to Use

The workflow is simple.

Put documents in the docs folder, ingest and then run in CLI:

That is the whole idea. No hosted API. No cloud document parser. No separate vector database service.

Why LiteParse Makes a Difference

Parsing is one of those steps that sounds small until it slows everything down.

If parsing is slow, re-indexing becomes annoying. If parsing is messy, retrieval gets worse. If retrieval gets worse, the LLM has poor context and starts giving weaker answers.

LiteParse helps because it makes document parsing feel like a normal part of the workflow instead of a heavy preprocessing chore.

That is especially useful when documents change. If I replace a file and run ingestion again, the app replaces the old embeddings for that file path. So the local index can stay fresh without me manually cleaning up old entries.

Why I Like This Stack

This stack feels good because it stays small.

LiteParse is fast and local.
Zvec is lightweight.
Ollama makes local models easy to run.
Gemma 4 gives the app a useful answer layer.

For personal notes, manuals, textbooks, PDFs, slides, spreadsheets, and other everyday documents, this is enough to build something genuinely useful.

Not every RAG app needs to become a platform.

Sometimes the best version is a local tool that reads your files, builds a searchable index, and lets you ask questions without sending your documents anywhere.

You can check out the repo here: aiplainandsimple/rag-with-liteparse-zvec-ollama

Suggested links:

• LiteParse GitHub

• Gemma 4 model reference

There is a boring sentence hiding inside almost every AI product:

First, we parse the document.

It sounds like plumbing. It sounds like the thing you do before the real work begins.

The model will reason. The agent will plan. The retrieval system will surface context. The workflow will take action.

But anyone who has built with real documents knows the unpleasant truth: parsing is where the system either earns the right to be intelligent or quietly poisons everything downstream.

If the parser drops a table header, the agent answers from the wrong column. If it mangles reading order, the summary sounds confident and wrong. If it loses page position, you cannot trace a number back to where it came from. If every document lookup requires a remote service call, latency creeps into the loop until the agent feels less like a collaborator and more like a batch job with a typing animation.

That is why LiteParse v2.0 is worth more attention than a typical library release.

It is not a new model. It is not a shiny agent demo. It is the less glamorous layer underneath: a fast local parser that can turn PDFs and office documents into usable text, page structure, screenshots, and spatial information without sending the file to an LLM.

And in v2.0, LlamaIndex rebuilt that layer in Rust.

That one decision changes the shape of the project. LiteParse is no longer just a Node package sitting in one corner of the ecosystem. It now has a portable core that can show up in Python, Node/TypeScript, Rust, the command line, and WebAssembly.

In other words: the parser wants to run wherever the agent runs.

Why Parsing Became an Agent Problem

Document parsing used to feel like ETL work.

You took a file, ran OCR or conversion, dumped the result into text or JSON, stored it somewhere, and moved on. That is still fine for plenty of pipelines.

Agents behave differently.

An agent may not know what it needs from a document until halfway through a task. It might skim the file, then zoom into page 17, then compare a table cell against a footnote, then ask for the original screenshot because the plain text looks suspicious. It might need text most of the time and visual evidence some of the time. It might need to do this again and again inside one reasoning loop.

That changes parsing from a preprocessing step into an interactive capability.

This is where LiteParse is interesting. It is designed for the common path: fast local extraction, spatial text, bounding boxes, screenshots, JSON or text output, and enough layout awareness that an agent is not forced to treat every document as a flat string.

That spatial layer matters more than people like to admit.

Documents are visual objects pretending to be text files. A PDF invoice, policy document, government form, scientific paper, slide deck, or financial table often communicates meaning through placement. A number in a column is not just a number. Its meaning comes from the header above it, the section around it, and sometimes the tiny note sitting below the table.

Flatten the page badly and the model has to guess.

Keep enough structure and the model gets to reason.

LiteParse’s sweet spot is not “understand every possible document perfectly.” It is: make the cheap local pass good enough, fast enough, and portable enough that developers can use it constantly.

That is a powerful place to sit.

What Actually Changed in v2.0

The headline is the Rust rewrite.

The old version had a practical ceiling: it came from the Node/TypeScript world. That was fine if your app lived there, less fine if you wanted the same parser inside Python workflows, Rust services, desktop apps, browser contexts, edge runtimes, or agent tools.

Rust gives LiteParse a more durable center of gravity. Instead of wrapping one runtime from another, the project can expose the same parsing core through several surfaces:

# Node library + CLI
npm i @llamaindex/liteparse

# Python library + CLI
pip install liteparse

# Rust library + CLI
cargo install liteparse

# Browser / edge WASM package
npm i @llamaindex/liteparse-wasm

The same lit command can be used from native installs. Python users get a normal library. TypeScript users get their package. Rust users get a crate. Browser and edge developers get a WASM path.

That distribution story is the real product move.

A parser that only works in one runtime is a library. A parser that works in the places developers already build starts to look like infrastructure.

The browser piece is especially telling. LiteParse can parse file bytes locally in WebAssembly. OCR is handled through a callback there, because the browser cannot simply bundle the same native system dependencies as a desktop or server environment.

That is not a weakness so much as a sign of serious portability. Native environments can lean on PDFium and Tesseract-backed OCR. Browser environments can still parse locally and bring their own OCR strategy.

This is what “runs everywhere” tends to mean in real software: not that every environment is identical, but that the core abstraction survives the trip.

The Speed Part

The number everyone will notice is “up to 100x.”

Small files benefit the most because the old path paid runtime startup costs. Bigger files still get a meaningful improvement. One of the benchmark examples floating around the release is a 457-page, 100 MB document parsed in under a second.

Do you need to believe every document you touch will be 100x faster?

No.

That is not the useful question.

The useful question is what becomes possible when parsing is fast enough that you stop designing around it.

When parsing is slow, developers avoid it. They pre-parse everything. They cache aggressively. They send files to specialized services. They limit how often an agent can inspect source material. These choices are often reasonable, but they also make the agent less adaptive.

The agent cannot cheaply say, “Wait, show me the original page again.”

Fast local parsing changes that product feel. Suddenly it is more reasonable to:

• Parse a document immediately when a user uploads it.

• Give an agent text first, then let it request screenshots for tricky pages.

• Keep sensitive documents on-device for first-pass extraction.

• Run parsing in a desktop app, browser app, server process, or edge workflow.

• Use local parsing as the default and escalate only the hard cases.

That last point is the architecture I find most compelling.

LiteParse does not need to replace heavier document AI systems. It just needs to make the default path cheaper.

For clean PDFs, straightforward office docs, basic screenshots, page ranges, and common extraction jobs, local parsing should be boring. For dense tables, handwriting, scanned messes, charts, multi-column layouts, and high-stakes extraction, you can still reach for a stronger parser like LlamaParse.

That is not a contradiction. It is a stack.

Local First Is a Product Feature

There is a privacy story here, but it is not only about privacy.

Yes, local parsing is useful when documents are sensitive. Contracts, invoices, medical records, financial statements, internal decks, customer files. Not every first pass should require uploading the file somewhere.

But local also means fast iteration.

It means an agent can inspect a file as part of its working memory, not as a separate cloud job. It means a developer can build a tool that feels immediate. It means a desktop app can parse documents without inventing a backend. It means a browser app can do useful work before a file ever leaves the machine.

Local is not just a compliance posture. It is a user experience.

When tools move closer to the user, they become available in more moments. And agents need tools that are available in the moment.

The Boring Commands Are the Point

LiteParse is not trying to make parsing feel magical.

That is part of the appeal.

You can use the CLI:

lit parse document.pdf
lit parse document.pdf --format json -o output.json
lit parse document.pdf --target-pages "1-5,10,15-20"
lit parse document.pdf --no-ocr
lit batch-parse ./input-directory ./output-directory
lit screenshot document.pdf -o ./screenshots

You can use Python:

from liteparse import LiteParse

parser = LiteParse()
result = parser.parse("document.pdf")
print(result.text)

for page in result.pages:
    print(page.page_num, len(page.text_items))

And you can install it as an agent skill:

npx skills add run-llama/llamaparse-agent-skills --skill liteparse

None of this is cinematic. Good.

The best infrastructure usually looks boring from the outside. It gives you simple commands, predictable outputs, and a few sharp options when you need them: page ranges, screenshots, OCR control, batch parsing, JSON output.

That is exactly the kind of tool an agent should be able to call without drama.

The Bigger Lesson

The AI world keeps rediscovering that models are not enough.

For a while, it was tempting to imagine that bigger multimodal models would swallow document processing whole. Just hand the PDF to the model. Let it see everything. Let it extract the answer.

Sometimes that is exactly the right move.

But it is not always cheap. It is not always private. It is not always fast. And it is not always necessary.

The better pattern is layered:

1. Use deterministic local tools for the easy parts.

2. Preserve layout and provenance so the model gets better context.

3. Escalate to heavier parsing or multimodal reasoning only when the document demands it.

4. Keep visual access available so the agent can recover when plain text is not enough.

That is the world LiteParse v2.0 fits into.

It is not trying to be the one parser to rule them all. It is trying to be the parser you can afford to use all the time.

And that distinction matters.

Why Rust Matters Here

Rust is easy to overhype, so let me put it plainly: Rust matters here because distribution matters.

If your parser is fast but trapped in one ecosystem, adoption gets awkward. If your parser is portable, embeddable, and exposed through the languages and runtimes developers already use, it can disappear into products.

That is the kind of success infrastructure wants.

Nobody wants to think about the parser every day. They want to trust that when a user uploads a PDF, the system can quickly produce usable text, page structure, and evidence. They want the agent to have enough context to avoid silly mistakes. They want the easy documents to stay easy.

Rust gives LiteParse a shot at being that kind of quiet layer.

The Caveat

Parsing is still hard.

“Local” does not mean “perfect.” “Model-free” does not mean “magical.” Anyone who has fought a scanned table, a sideways invoice, a weird two-column report, or a chart embedded in a slide knows the pain.

So the right question is not:

Should I use LiteParse or LlamaParse?

The better question is:

Which parts of my workflow deserve a fast local first pass, and which parts need heavier document understanding?

For a lot of products, the answer will be both.

LiteParse for the common path. LlamaParse or a stronger multimodal workflow for the hard path. The model for reasoning. The parser for giving the model something sane to reason over.

That is a much healthier architecture than throwing every document directly at the most expensive layer and hoping the bill, latency, and audit trail work themselves out later.

The Quiet Takeaway

AI agents do not just need better brains. They need better hands.

They need tools that are fast enough to use repeatedly, local enough to trust with sensitive files, portable enough to run wherever the workflow lives, and structured enough to preserve the evidence behind an answer.

LiteParse v2.0 is one of those tools.

It is easy to underestimate because it lives below the model layer. But the best agent systems are not built from models alone. They are built from small, sharp, reliable tools that make the model’s job easier.

Parsing documents is one of those jobs that looks boring until it breaks.

LiteParse v2.0 is LlamaIndex trying to make it boring again.

Further Reading

• LlamaIndex: LiteParse v2.0 Runs Everywhere

• GitHub: run-llama/liteparse

• PyPI: liteparse

• GitHub: run-llama/ParseBench

I have been playing with a small local RAG project: a command-line chatbot that reads a folder of documents, retrieves the most relevant chunks, and asks a local model to answer from that context.

The stack is intentionally small:

• Zvec for local vector search

• Ollama for local embeddings and answer generation

• Rich for a nicer terminal experience

The goal was not to build a giant production platform. I wanted something simpler:

Can I build a useful RAG loop that runs on my own machine, with my documents staying local?

The answer is yes. And the nice part is that the system is understandable. Each piece has one job.

The Shape of the App

RAG stands for Retrieval-Augmented Generation. The idea is simple: before asking a language model to answer, first retrieve the pieces of your data that are likely to matter.

In this project, the flow looks like this:

1. Read `.txt`, `.md`, and `.pdf` files from a local folder.

2. Break the documents into chunks.

3. Use Ollama to create embeddings for those chunks.

4. Store the chunks and vectors in Zvec.

5. When I ask a question, embed the question too.

6. Ask Zvec for the closest chunks.

7. Send those chunks to a local Ollama model.

8. Print the answer with citations.

That is the whole loop. No hosted embedding API, no remote vector database, no document text leaving the machine.

Why I Used Zvec

Zvec is the retrieval layer in this project. The Zvec is a lightweight, in-process vector database built for high-performance semantic search. That caught my attention because most RAG examples quickly become a pile of services: one thing for embeddings, one thing for vector storage, another thing for generation, sometimes a web server on top.

For this project, I wanted the vector database to feel more like a local library than an infrastructure project.

Zvec fits that nicely. It runs inside the Python process and persists its data locally under:

./rag_store

For each document chunk, I store:

• the chunk text

• the embedding vector

• the source filename

• the chunk id

• a content hash

• the file modification time

The metadata matters. It lets the CLI cite where an answer came from, and it gives the ingestion step enough information to replace stale chunks when a file changes.

When I ask a question, the CLI embeds the question, queries Zvec, and gets back the top matching chunks. Only those chunks go to the LLM.

That is the part of RAG I like most: the model is not being asked to magically know everything. It is being given a small packet of relevant context and asked to answer from that.

Why I Used Ollama

Ollama is the local model runtime. It gives the app a simple local API for model calls.

That means Ollama handles model inference, while Zvec handles retrieval.

I like that split because it keeps the project easy to reason about:

• If retrieval is bad, inspect the chunks Zvec returned.

• If the answer is bad, inspect the prompt and model response.

• If documents change, re-run ingestion.

There is no mystery service in the middle.

In practice, retrieval is fast. Generation is the slower part, as expected, because the local LLM has to actually write the response.

What I Learned

The biggest lesson is that local RAG becomes much easier to understand when the architecture is small.

Zvec keeps retrieval close to the app. Ollama keeps model calls local. Rich makes the terminal less painful to look at. Together, they make a compact loop that is easy to test, break, inspect, and rebuild.

The current version is still simple, but that is the point. It is a local RAG system that fits in one small Python project.

Final Thoughts

I like tools that have a clear shape.

There is plenty that could be added later: better chunking, reranking, hybrid search, a small web UI, document watchers, or model selection per session. But the core loop already works:

local documents —> local retrieval —> local generation —> cited answer

That is a satisfying place to start.

Links

• Zvec: https://zvec.org/en/

• Ollama docs: https://docs.ollama.com/

• Project repo: https://github.com/aiplainandsimple/rag-with-zvec-ollama