# lodos vs Linear

Source: https://lodos.md/en/compare/linear
Language: en

Linear tracks the work. lodos runs it.

---

Let us get the honest part out of the way first, because you will check it anyway. Linear is a better issue tracker than lodos and will stay one: cycles, triage, SLAs, insights, saved views, custom fields, and a sync engine its own team treats as a security-grade invariant. lodos has five fixed statuses, tags, and no issue search at all. What lodos has instead is a board where the work runs. A repeated job becomes a parameterised procedure the agent executes and parks in review. A schedule calls your own APIs at eight in the morning with a credential the model never sees, and pins the number to a dashboard you asked for in a sentence. Closing a card can draft the document that explains it. The question is not which board is better. It is whether you need somewhere to record the work, or somewhere it happens.

## The ticket was never the hard part

A well-run board tells you what is in flight and what is blocked. Linear does that better than anything else, and if that is your problem, this page is going to end with us telling you to stay.

But a solo founder’s bottleneck is rarely the tracker. It is that the ticket says “migrate the billing webhook” and nowhere in the tool is the reason you chose that architecture, the runbook for the rollback, the key the migration needs, or the note from March explaining why the obvious approach does not work. Those live in four places, and you are the only index.

lodos is the smaller board with the other three attached, and with an engine underneath it, so the ticket is not the end of the sentence.

## What Linear does better than lodos

This is not a courtesy paragraph. Linear wins the category this page is nominally about, and the list is long and specific because pretending otherwise would waste your time.

- The tracker itself, comprehensively: cycles that schedule themselves and roll over, capacity from the trailing three cycles, a triage inbox with on-call rotation and SLAs, Insights, saved views, custom fields, custom workflows, and a sync engine so good they list its integrity in the top tier of their bug bounty. lodos has none of this.
- Speed and a real keyboard grammar, on web, macOS, Windows, iOS and Android, at any scale. lodos’ board has one shortcut, no issue search, loads every task into memory, and has been used in anger by one person with a few dozen tasks. Nobody has tried it at your size.
- SOC 2 Type II, ISO 27001, HIPAA business associate agreements, a paid bug bounty that explicitly scopes their own MCP authorization, and published incident post-mortems. lodos has none of that paperwork.

## lodos is not a better tracker. It is the company the tracker sits inside.

Seventy-three tools, twenty-three workflow step types, twenty-four built-in procedures and forty-one build-breaking invariants, in one local binary with no account. Everything below is a consequence of the board, the wiki, the vault and the agent being the same program rather than four subscriptions.

### A board where the work actually runs

This is the part Linear has no equivalent of, so it goes first. A job you do more than once becomes a template with typed inputs: a body of up to sixteen thousand characters, the placeholders it expects, and a snapshot of which tools it is allowed to touch, narrowed only, never widened. Running it fills the placeholders, executes, and lands as a work item in review. The gate is structural: a work item can only reach done from awaiting review, so nothing an agent produced is ever silently finished. Queue them with a priority tier and a duplicate rule so a nightly run reuses the open item instead of stacking a fifth copy. Before any of it executes, the rendered text is checked for credential shapes and refused if it carries one. And hand the agent an epic instead and it proposes the whole breakdown as a dependency graph, cycle-checked, which you approve in one diff; after that the graph is plain host logic with no model in it, so when the last blocker closes the next task wakes up by itself.

### The task, the page and the reason, pointing at each other

A task carries references to the wiki pages behind it, and each of those pages shows the open tasks still running against it. Not a pasted link that rots: a live projection in both directions, structure only. And the wiki on the other end answers rather than lists, with [[wikilink]] citations, over material written once to a raw layer and hash-checked at the database level so any claim traces back to its source. A nightly pass runs five checks in plain SQL at no AI cost: orphaned pages, dead links, claims older than ninety days, unanswered TODO markers and pages nobody filed. Linear has Documents, and good ones, with real-time editing, version history and hybrid semantic search. What they do not have is backlinks, a graph, nesting, or any notion of a claim going stale.

### Ask your editor what is on your plate

lodos is an MCP server. Point Claude Code or Cursor at it and “what am I working on?” comes back from your actual board, in the editor, without a browser. Linear ships an MCP server too, and a good one, so the difference is not the protocol: it is what sits behind it. Theirs is hosted and covers issues, projects and comments. Ours runs locally over stdio and exposes seventy-three tools across the board, the wiki, the vault, the workflows, the documents and the analytics, as one surface. Reads return immediately. Every write raises an approval modal on your desktop first, whether the caller is the built-in chat or an editor across the room, and is refused outright if the app is not running. The guard is the same code; the caller does not get to choose.

### Work that happens while you are asleep

A workflow is a declarative file with twenty-three step types: call an HTTP endpoint, ask the model, query your database or an external Postgres, read and write files, propose a wiki edit, open a task, wait, branch on a closed set of comparators, loop over a concrete list. Triggers are a cron expression, an interval, a calendar rule, a one-shot, an inbound webhook, a poll against your mailbox, or a row changing in your own task table, which is how closing a card can draft the document that explains it. Sixteen ready blueprints cover the ones every founder writes anyway: the morning brief, the weekly review, the renewal warning, the stale pull request, the runway number. The agent drafts these through constrained edits while the host assembles the file, so a prompt cannot smuggle a step past you, and credentials are injected at the moment of the call and never enter its context.

### A team layer that never hands the server a key

Shared boards with assignment, a reviewer separate from the doer, accept-or-decline with a reason so nothing lands in a silent assignment black hole, per-criterion check-off attribution, swimlanes and soft WIP limits. Underneath, the part that is unusual: every member holds their own sealed copy of a section key, the coordinating server relays addressed envelopes it cannot open and has no delete endpoint to censor with, and removing someone rotates the key and re-encrypts so the envelope they kept opens nothing written afterwards. Every action lands in a signed, hash-linked record that says whether a human or an agent did it.

### It remembers, and it remembers correctly

Long-term memory is an encrypted store, add-only, where a later fact supersedes an earlier one instead of overwriting it and a correction outweighs a repetition. Facts carry a confidence and the date they were last seen, and they arrive as a frozen block at the start of a session, so the assistant knows your business before you have finished the sentence. Then the part that matters: a turn that touched untrusted content, a web page, an inbound message, a document, cannot write to memory at all. A poisoned page can waste one answer. It cannot become a permanent belief about your company. This is the difference between an assistant with a long context window and one that has actually been working here.

### Your own numbers, your own documents, in the same app

Ask for a dashboard card in a sentence and you get one: the query is written for you, run read-only against a live connection to check it works before anything is saved, and the result lands as a number, a chart or an overdue flag. Underneath, analysis runs on your own database with window functions and common table expressions and an eight-table denylist that keeps the vault and the audit log out of reach, with no egress at all. Drop in a PDF, a contract or a spreadsheet and it becomes searchable knowledge, converted in an isolated process that cannot see your vault; a spreadsheet also becomes a real view you can query by its sheet name. Ask for an investor update and get a rendered deck, offline. And twenty-four procedures ship in the box, from weekly metrics and refunds to ADRs, post-mortems, spec writing and security review.

### Free, local, and what that costs

The app is free with no account and works with no network: board, wiki, graph, workflows, skills, documents, charts and the agent. Nine dollars a month for the whole install, not per seat, buys an encrypted snapshot that restores a machine in minutes, and our servers hold ciphertext they cannot open. Linear starts at ten dollars per user per month on Basic, billed yearly, with a free tier capped at two teams and two hundred and fifty issues. The AI runs on your own Claude account, so there is no credit meter on the work itself. The trade you are making for that price is real and it is the next section.

## Coming from Linear, or living beside it

1. There is no importer. Nothing reads a Linear export into lodos, and given the board is deliberately smaller, a bulk import would mostly produce a backlog you cannot search.
2. The realistic move is to start with the pages, not the tickets. Point lodos at wherever your markdown already lives, put the handful of credentials your work actually touches into the vault, and open tasks as they come up.
3. Or keep Linear where it is. lodos ships a Linear connector, so the agent can read your issues, cycles and projects from Linear while the wiki, the vault and the workflows live locally.

That third option is the honest recommendation for most teams reading this, and it is not a consolation prize: the two products barely overlap once you stop treating both as trackers.

## What can it see?

Both products are described with the same four answers. There is no kinder phrase available for the same behaviour, so neither column can be graded on a curve.

| What can it see? | Linear | lodos |
| --- | --- | --- |
| Where your data lives | On their servers | On your device, sync optional |
| What the vendor can read | Everything you write | Only ciphertext it cannot open |
| What its AI can read | Your whole workspace | Structure, never a secret value |
| Who holds the key | The vendor | You |
| Starts at | $10 per member, per month | $0 |

Read from the vendor on 2026-08-03: https://linear.app/pricing

## Who can see my issues?

On our side, nobody, ever. If you turn on sync, the server receives an encrypted envelope, stores it, and cannot open it. Neither can we as the people operating it, because the key is derived from your master password and never leaves your machine. Not the vendor, not an employee, not a subpoena served on us. Even the billing boundary is drawn narrowly: an email address and a payment cross it, and nothing about your work does.

On your own machine, the honest answer is different and you should have it before you decide. Your issues live in a plain SQLite file so that search, sorting and filtering work at all. They are protected by your operating system account and your disk encryption, not by your lodos master password. Your secrets are separately encrypted and are never plaintext anywhere, but the issue text itself is not encrypted at rest locally, and that was a deliberate trade for queryability. Linear made the same trade for the same reason. The only difference is where the trade happens: theirs on their servers, ours on your disk.

## What happens when your editor asks about your work

This is the part the owner uses every day and the one worth being concrete about, because the interesting bit is not that it works but what happens on a write.

1. Your editor launches the lodos MCP server as a local process and talks to it over stdio. Nothing goes to a network. The app has to be running, because the server is a thin bridge to it and holds no data of its own.
2. A read runs immediately. “List my in-progress tasks”, “what is blocking this”, “what does the wiki say about the billing migration” all return without interrupting you, because those tools are read-only.
3. A write does not. Creating a task, transitioning one, saving a procedure or approving a run raises the same approval modal in the desktop app that the built-in chat would raise, with a forty-five second timeout and a refusal if the app is closed. The vault key never crosses that bridge, and a reference like `{{secrets.stripe.sk_live}}` stays a reference the whole way through.

One thing to be precise about, since precision is the point: the board itself refuses illegal transitions, but that check lives on the app path rather than the tool path. If an agent moves a card straight from To Do to Done, today it will let it.

## Three questions, both ways

Same founder, same week, same three things you actually ask.

### What is on my plate?

- **Linear:** Open the app, or ask through their MCP server from your editor. Either way you get the issues, which is exactly what you asked for and usually enough.
- **lodos:** The same question in the same editor, and the answer comes back with the pages behind each task attached, because the board and the wiki are the same store.

### Why does this task exist?

- **Linear:** The description, plus whichever document someone remembered to link. If the reasoning is in a doc, semantic search will probably find it; nothing tells you it went out of date eight months ago.
- **lodos:** The task carries its wiki references, the page shows what is still open against it, and last night’s pass already flagged the claim that has not been checked in ninety days.

### Run the refund for this customer

- **Linear:** Open the ticket, then leave Linear to do the actual work in Stripe and your admin, then come back and write down what happened.
- **lodos:** The refund procedure is a template. Fill in the order, the agent runs it against your own API with a key it never sees, and the result waits in review before anything is marked done.

## So what should you actually do?

- Stay with Linear if you are tracking work with a team. Cycles, triage and insights are real advantages and lodos does not have them, is not building them this year, and would not do them as well.
- Take lodos if you are one person and the tracker is the smallest part of the problem: when what slows you down is the runbook, the credential and the reason, not the column the card is in.
- Or use both. lodos ships a Linear connector precisely because this is the common answer: your issues stay where they work, and the agent reads them alongside the wiki and the vault that Linear was never meant to hold.

## Questions people actually ask

### Is lodos a Linear alternative?

Not as an issue tracker, no, and we would rather say so on the page than in a support email. lodos is a company operating system with a small board in it: the wiki, the knowledge graph, the encrypted vault, the workflows and the agent are the product, and the board is where they meet. If you want a better tracker, Linear is the better tracker.

### Does lodos have cycles, sprints or velocity?

No. There are no cycles, no sprints, no estimates, no story points, no velocity, no burndown, no triage inbox, no SLAs and no insights dashboards. There are five fixed statuses, priorities, tags, acceptance criteria and dependencies. If your process runs on iteration planning, this will feel like a downgrade because it is one.

### Can I search my tasks?

Not today, and it is the first thing a Linear user reaches for. The wiki has full-text search; the board does not, and the command palette does not know about tasks. You can filter by status and read the columns. This is the sharpest missing piece and we are not going to bury it in a footnote.

### Can Claude Code or Cursor see my lodos tasks?

Yes. lodos runs an MCP server over stdio, so any MCP client on the same machine can list, read, create and transition tasks, and read the wiki alongside them. Reads are immediate. Every write raises an approval modal in the desktop app first, and is refused outright if the app is not running. The vault key never crosses that boundary and no tool anywhere returns a secret value.

### Does dragging a task to Done really update the wiki?

The mechanism is real and it is worth being exact about. A task status change can trigger a workflow, that workflow can draft a page update and file it as a proposal, and the proposal shows up as a diff you approve. What is automatic: the trigger, the draft, the filing, and the deduplication so a nightly run cannot spam you. What is not: the workflow is a declarative file you write once, and the page write itself always waits for one click, by design.

### Can I import my Linear issues?

No. There is no importer from Linear or anywhere else. What lodos does ship is a Linear connector, so the agent can read your issues, cycles and projects from Linear directly. In practice that is the better arrangement anyway: the tickets stay where the tracking is good, and what moves here is the knowledge that had nowhere to live.

### Is lodos free?

The app is free with no account: board, wiki, graph, workflows, twenty-four built-in skills, documents, charts and the built-in agent, all working with no network. The only paid part is encrypted cloud backup at nine dollars a month for the whole install, not per seat. The AI runs on your own Claude account, so we are not reselling you tokens.

## The rows that actually differ

The first row is a loss and it is at the top on purpose. Everything in the Linear column comes from their own documentation, read on 3 August 2026.

| | Linear | lodos |
| --- | --- | --- |
| The tracker itself | Cycles, triage, SLAs, insights, saved views, custom fields, custom workflows. | Five fixed statuses, priorities, tags, acceptance criteria, dependencies. No cycles, no insights, no issue search. |
| Work that runs, not just work that is listed | Loops can draft and delegate on the Business tier, metered per run. | Templates the agent executes into a review queue, and twenty-three step types calling your own APIs on a schedule. |
| Long-form knowledge | Documents attached to work, collaborative, version history, hybrid semantic search. | A wiki with citations, backlinks, a graph, and a nightly linter that flags stale claims. |
| What an editor can reach through MCP | Issues, projects and comments, through a hosted server. | Seventy-three tools across board, wiki, vault and workflows, through a local one, with a modal before any write. |
| Where the issue text lives | Their servers, AES-256 at rest, keys held by the vendor. No end-to-end claim. | Your disk, in plaintext, so search works. Encrypted only when it leaves for sync. |

If this page describes Linear incorrectly, that is a bug. Tell us and we will fix it.