DEV Community: Radial

Notion is a doc with an AI button. A tracker should stay a tracker.

Nico Acosta — Wed, 01 Jul 2026 13:14:17 +0000

If you searched "Notion alternative," you are probably one of two people. The first wants a better place to keep notes, wikis, and databases, and Notion got slow, sprawling, or too eager to put an AI button on every page. The second is an engineering team that started tracking work in a Notion database, watched it grow into a slow, half-structured tracker, and now wants something that actually tracks issues.

This guide serves both. The honest answer for the first is a knowledge-base tool. The honest answer for the second is a dedicated issue tracker, because a doc-first everything-app and an issue tracker are different categories, and Notion is very good at being the first and was never built to be the second.

If you want a better Notion: the honest shortlist

Notion is a block-based document tool that grew databases, wikis, and lately an AI layer bolted across the surface. People leave for a few concrete reasons, and the right alternative depends on which one is yours.

You want local-first and your data on your disk. If the pain is that everything lives in someone else's cloud, Obsidian stores Markdown files locally and builds a linked "second brain" with plugins. Anytype is local-first, peer-to-peer, and open-source with a Notion-like block structure. AppFlowy and AFFiNE are open-source workspaces in the same shape. The trade is you give up some of Notion's polish and hosted convenience.

You want powerful databases and formulas. If you used Notion mostly as a flexible database, Coda thinks like a spreadsheet with buttons and automations, and Airtable is the heavier database-first option with strong views and integrations.

You want a clean team wiki. If the job is a shared knowledge base for a team, Slite, Nuclino, and Confluence are built for that and stay in that lane.

You want less AI, not more. This is a real and growing search ("Notion alternative no AI" is a suggested query). If Notion's spreading AI features are the irritation, the move is a tool that does the document job and leaves the model out of it. Most of the local-first options above qualify.

If you are in this first group, pick from that list and stop reading. Radial is not a notes app and will not pretend to be one. But there is a second group the note-taking listicles never address.

If you're tracking engineering work in Notion: that's the wrong category

Here is the pattern. A small team needs to track some work. Notion is already open, so someone makes a database with a Status column, a few views, and a kanban board. It works at ten issues. At three hundred, with five engineers filtering and re-sorting all day, the seams show:

The board takes a beat to load, and every filter is a fresh query against a general-purpose database, not a tracker tuned for the job.
There is no real triage inbox, no sprint primitive, no estimates, no native concept of a cycle. You rebuild each of those out of properties and discipline, and the discipline erodes.
Issue IDs are page links, not stable short identifiers, so "the bug in RAD-219" is not a thing you can say in a commit or a CLI.
Your coding agents cannot drive it cleanly. Notion has an API, but it models a doc workspace, not an issue lifecycle, so an agent filing or closing issues is bending a documents API into a tracker it was not designed to be.

None of this means Notion is bad. It means a document tool is doing an issue tracker's job, and the impedance mismatch is the slowness and sprawl you are feeling. The fix is not a better Notion. It is moving the tracking out of the doc tool and into a tool built to track, while leaving the docs and wikis where they already work.

A tracker that stays a tracker

Radial is a fast, keyboard-first issue tracker, and that is the whole product. Instant search, a command palette, list and board layouts, Cycles (time-boxed sprints), estimates, triage, and projects. Issues have stable short IDs you can reference in a commit. It does the one job a tracker does, and it does not try to also be your wiki, your whiteboard, or your CRM.

Two things make it a deliberate counterpoint to Notion's direction.

There is no AI in the product, and a written pledge to keep it that way. Radial costs $50 per user, per year, flat, billed annually, locked at the rate you join. No AI credit balance, no usage meter, no overage line, because there is nothing AI in the product to meter. The Plain Software Pledge makes it binding: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

This is not anti-AI. AI is redefining plenty of products, and your agent doing real work is great. The point is the opposite of Notion's bet: the intelligence belongs to your agent, not baked into the tracker and billed back to you. Your agents ride free here. Every agent credential is a client of the API, not a billed seat, and Radial exposes a real CLI, REST API, and MCP server for them to drive.

That is the line a doc-with-an-AI-button cannot hold, because the AI is the feature it is selling.

And because what strands most teams is the export, moving the tracking out of Notion is meant to cost a command, not a project. An agent (or you) can file straight into Radial from the terminal:

npm i -g radial.build
radial create "Migrate issue tracking out of Notion" -t ENG -p high --json

Every command takes --json, so the same move scripts from CI, and your agent can do the equivalent over MCP at mcp.radial.build. Keep your notes and wikis in Notion, where they are genuinely good. Move the issues to a tracker.

Where Radial is honestly not for you

A fair comparison names the gaps. Radial is not a Notion replacement for documents, wikis, or databases, and it never will be. It has no pages, no doc editor, no whiteboard, no general-purpose database, no spreadsheet formulas. If what you actually want is a flexible workspace to write and organize knowledge, one of the tools in the first section is the right answer and Radial is not.

Radial is also not a whole-company work platform. No portfolio or initiative layer, no burndown or velocity dashboards, no roadmap timeline. It is built for engineering-led teams who want a fast tracker their agents can drive, not a planning suite. If those are load-bearing for you, we would rather say so now than lose your trust in a bake-off.

FAQ

Is there an app better than Notion?

There is no single "better," because Notion does several jobs and the better tool depends on which one you mean. For local-first notes, Obsidian or Anytype. For databases, Coda or Airtable. For a team wiki, Slite or Confluence. And for tracking engineering work, a dedicated issue tracker beats a Notion database every time, because tracking issues is a different category than writing docs.

Who are Notion's main competitors?

For the document and database job, Notion competes with Coda, Airtable, ClickUp, Obsidian, and Microsoft Loop. For the slice of Notion that teams misuse as a project tracker, the real competitors are dedicated trackers like Linear, Jira, GitHub Issues, and Radial, tools built around an issue lifecycle rather than a flexible page.

Why do people stop using Notion?

The common reasons are speed (it slows down as the workspace grows), sprawl (it does so many things that nothing is opinionated), data ownership (everything lives in Notion's cloud), and, increasingly, AI fatigue, the sense that AI features are being pushed into every corner. For engineering teams specifically, the reason is usually that a general-purpose database makes a poor issue tracker once the work scales.

Can I use Notion as an issue tracker?

You can, and at small scale it is fine. A Notion database with a Status property and a board view tracks a handful of issues without complaint. It breaks down as you scale: no native triage inbox, no real sprint or cycle primitive, no stable short issue IDs, slower boards, and an API built for documents rather than an issue lifecycle, which makes it awkward for coding agents to drive. At that point a dedicated tracker is the fix.

Is there a Notion alternative with no AI?

Yes, and it is a deliberate search now. Most local-first note tools (Obsidian, Anytype) keep AI optional or absent. For the tracking job specifically, Radial ships with no AI in the product at all, plus a written pledge that your subscription goes free if that ever changes, so the price is one flat locked number rather than a subscription with a meter attached.

The short version

Notion is an excellent document, wiki, and database tool, and it is adding AI to all of it. If you want a better version of that, pick a knowledge-base tool from the first section. But if you have been tracking engineering work in a Notion database and it got slow and sprawling, the problem is the category, not the configuration: a doc-first everything-app is doing an issue tracker's job.

Radial is the tracker for that case. Fast and keyboard-first, one flat locked $50 per user per year, agents ride free over a real CLI, REST API, and MCP server, and a pledge that pays you if we ever add an AI meter.

See the one number on pricing, or read the manifesto for why a tracker should stay a tracker. If you are weighing the fast trackers against each other, here is the honest Radial vs Linear breakdown.

Originally published on the Radial blog.

The best Jira alternative depends on what made you leave

Nico Acosta — Tue, 30 Jun 2026 13:14:26 +0000

Most "best Jira alternative" lists hand you the same shortlist and let you sort it out: Linear, ClickUp, Monday, Plane, GitHub Issues. That list is fine. The problem is it answers the wrong question. The right one is not "what else tracks issues," it is "what specifically drove you off Jira," because that is what decides which alternative actually fixes your problem instead of trading it for a new one.

So this guide sorts the field by the reason you are leaving. Then it names a lane the usual shortlist skips: a fast tracker with one flat locked price and no AI meter at all.

The honest shortlist, sorted by why you're leaving

Jira earned its place. It is genuinely powerful, endlessly configurable, and built to run hundreds of teams across engineering, support, and operations. If you need that breadth, none of these will match it, and you should stay. People leave Jira for one of a few concrete reasons, and the right alternative depends on which one is yours.

You're leaving because it's slow and heavy. The most common reason, and the one developers voice loudest. If a board that takes seconds to load and a workflow you spent a week configuring is the pain, the answer is a fast, opinionated tracker. Linear is the consensus pick here: keyboard-first, instant, built for engineering teams that want to move without administrative setup. The trade is flexibility, you do it Linear's way, and Linear's way is good.

You want to self-host or own your data. If the reason is data sovereignty or you simply don't want another SaaS bill, the open-source field is real. Plane is the popular modern option, a Jira/Linear hybrid you can deploy with Docker in minutes. OpenProject leans enterprise, with Gantt charts and classic planning. The trade is you now run the infrastructure.

You want the tracker glued to your code. If your team already lives in pull requests, GitHub Issues keeps tracking inside the repo, tied to your branches and CI. It is light by design. The trade is it stays light, when a flat list of issues isn't enough, you outgrow it.

You need cross-functional, non-engineering teams in the same tool. If marketing, sales, and ops have to share the workspace, ClickUp and Monday are the "Work OS" options, with docs, whiteboards, and heavy customization. The trade is weight and a learning curve that starts to rhyme with the one you're leaving.

That decision tree is correct, and for many teams it ends here. But there is one reason for leaving Jira that the shortlist above quietly skips.

The reason the shortlist skips: the bill that keeps moving

Look at what every option on that list shares. They are all per-seat per month, and most now bill AI work on top of the subscription.

Jira is per-seat per month, and its AI layer, Rovo, ships a monthly credit allowance per seat with overage billing announced. Rovo Dev is a further charge per developer. The base is a subscription; the AI is a meter.
Linear is per-seat per month, and its newer agent work (Coding Sessions) draws from a prepaid, USD-denominated AI credits balance. Same shape.
ClickUp and Monday sell AI as add-on credit pools layered onto the seat price. Monday's own announcement moved AI from free to metered.

None of that is wrong as a business model. But it means the number you sign up for is not the number you end up paying, and the gap widens exactly as your team leans into agents. If the thing that finally pushed you off Jira was the invoice creeping up, switching to another per-seat-plus-meter tracker is a lateral move. You changed the logo, not the trajectory.

That is the lane the shortlist doesn't name, because none of them sit in it.

The lane none of them name: flat, locked, no meter

Radial is a fast, keyboard-first issue tracker, and it took the speed side of the Linear argument seriously: instant search, a command palette, list and board layouts, Cycles (time-boxed sprints), triage, projects. The job a fast tracker does well, Radial does.

The difference is the price and the promise. Radial costs $50 per user, per year, flat, billed annually, locked at the rate you join. There is no AI credit balance, no usage meter, no overage line, because there is no AI in the product to meter. Your agents ride free: every agent credential is a client of the API, not a billed seat.

The part that makes it a commitment rather than a slogan is the Plain Software Pledge, written down: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

This is not anti-AI. AI is redefining plenty of products, and your agent doing real work is great. Your issue tracker is just not the place that intelligence should live or get billed. The agent is yours, the model is yours, the keys are yours. Radial's job is to be the fast system of record your agent writes to, over a real CLI, REST API, and MCP server, with no bill for the privilege.

And because the thing that strands most teams on Jira is the export, moving over is meant to cost a command, not a migration project. Radial deep-imports issues, projects, labels, comments, and history in one run. Run it dry first to see exactly what comes across before you commit:

npm i -g radial.build
radial import --from jira export.json --dry-run

Every command takes --json, so the same move scripts from CI, and your agent can do the equivalent over MCP at mcp.radial.build.

Where Radial is honestly behind Jira

A fair comparison names the gaps. Against Jira, Radial does not have its breadth: no portfolio or initiative layer, no burndown or velocity dashboards, no Gantt roadmap, no thousand-app marketplace, no cross-department workflow engine. If you genuinely run fifty teams with fifty different workflows and a compliance team that needs the audit suite, Jira is built for that and Radial is not.

If those are load-bearing for you, that is a real reason to stay on Jira, and we would rather tell you now than lose your trust in a bake-off. What Radial will not be behind on is the price and the pledge.

FAQ

What is replacing Jira?

There is no single replacement, because teams leave Jira for different reasons. Engineering teams chasing speed mostly land on Linear or a fast focused tracker. Teams that want to self-host go to Plane or OpenProject. Teams glued to their code stay in GitHub Issues. Cross-functional orgs pick ClickUp or Monday. The honest answer is to pick by the reason you're leaving, not by whichever tool tops a listicle.

Is there a free version of Jira?

Yes, Jira has a free tier for small teams, capped on seats and features. The catch is that "free" is the on-ramp, not the destination: the cost shows up as you scale seats and as the AI layer (Rovo credits, Rovo Dev) starts metering. A free tier that meters later is a different deal than one flat price that doesn't. Radial has no free tier and no meter, it is one flat $50 per user per year from the first user, which is the trade some teams prefer to make up front.

Who is Jira's biggest competitor?

Linear is the one named most in developer circles, which is why "Linear vs Jira" is the comparison people run. The quieter competitor is any tool that removes Jira's weight without adding a new tax. That is the lane Radial sits in: the speed of a modern tracker, plus a flat locked price and a binding pledge against a usage meter.

Is Jira being phased out?

No. Jira remains dominant in enterprise, and Atlassian is migrating Data Center customers to cloud rather than retiring the product. The shift is narrower: teams that adopted Jira for engineering work but never needed its enterprise breadth are increasingly moving to faster, focused trackers. That is a fit problem, not an obsolescence one.

Does Microsoft have a tool similar to Jira?

Azure DevOps Boards is the closest Microsoft equivalent for software teams, and Microsoft Planner covers lighter task tracking inside the Microsoft 365 stack. Both are reasonable if your org is already all-in on Microsoft. Neither is built around a terminal-first CLI or an MCP server your own agent can drive, which is the axis that matters if you run coding agents.

The short version

The best Jira alternative is the one that fixes the specific reason you're leaving. Slowness points to Linear. Data ownership points to Plane. Code-tight tracking points to GitHub Issues. Cross-functional sprawl points to ClickUp or Monday. But if the reason you're leaving is the bill that keeps moving, every one of those is a lateral step, because they all bill per seat and meter the AI on top.

Radial is the option for that last case: a fast tracker, one flat locked $50 per user per year, agents ride free, and a pledge that pays you if we ever add a meter.

See the one number on pricing, or read why is Jira so slow for the engineering reason the weight is not free. If you are weighing the two fast trackers against each other, here is the honest Linear vs Jira breakdown.

Originally published on the Radial blog.

The meter you didn't sign up for

Nico Acosta — Sun, 28 Jun 2026 13:12:20 +0000

You opened a tool you have paid for all year, and a small number was counting down. Credits left. Tokens remaining. Usage this cycle. You did not ask for the meter. It arrived in an update, attached to a feature you may never use, and now it sits in the corner of a product that used to just do its job.

That is the quiet shift of the last two years. Usage-based pricing started as a fairness pitch and became the default way software bills you for AI. This post is about how that happened, why it feels different from the cloud bill you signed up for, and the case for the opposite: one flat number that does not move.

What usage-based pricing actually is

Usage-based pricing, also called consumption-based or metered billing, is a model where you pay for the exact amount of a product you consume rather than a fixed fee. The vendor picks a value metric (API calls, gigabytes, AI tokens), meters your consumption in real time, and applies a rate. You watch a dashboard to avoid a surprise bill.

For some products this is genuinely fair. Cloud infrastructure is the honest version: AWS and Google Cloud charge for compute and storage you actively chose to provision, and the bill maps cleanly to a thing you turned on. Twilio bills per SMS. An LLM API bills per token. In each case the meter measures a real, variable cost the vendor incurs on your behalf, and you opted into the variability when you adopted the tool.

The model is not the problem. The problem is where it migrated.

How the meter ended up in your issue tracker

Usage-based billing did not stay in the infrastructure layer. As every category raced to ship AI features, the meter followed the feature in. A tool you bought as a flat seat now has an "AI" line item: a credit pool, a token allowance, a per-action charge for a copilot bolted into the sidebar. The related searches under "usage-based pricing" tell the story on their own. People are now typing "usage-based pricing Cursor" and "usage-based pricing Claude" and "usage-based pricing AI" into Google. The anxiety is specific, and it is about the tools developers use every day.

Here is the part that grates. Cloud metering is a cost you provisioned. AI metering inside a tool you already pay a seat for is a cost the vendor created by adding a feature you did not request, then handed to you to manage. You are now watching a balance drain on software whose whole job is to stay out of your way. The dashboard you check to "avoid unexpected bills" is itself the unexpected thing.

For an issue tracker, this is backwards. A tracker's job is to open fast, hold the work, and disappear. The moment it grows a meter, it stops being a system of record and becomes one more balance to babysit.

The flat number is a position, not a discount

The honest counter to a meter is not a cheaper meter. It is no meter. Radial charges $50 per user, per year. Flat, billed annually, everything included. No tiers, no credits, no usage line, no AI surcharge, no "Contact sales." The rate you join at is the rate you keep.

To be precise, because this is the whole point: we are not claiming to be the cheapest tracker. Some tools have a lower sticker price, and a few are free. The claim is narrower and more durable. The price is one number, you can predict it a year out, and it does not climb because you used the product more or because a feature you never asked for burned through an allowance. Predictability is the feature, not the dollar amount.

The reason the bill can stay flat is structural, and it is worth saying plainly. Radial does not host, meter, or bolt in a copilot. The intelligence in your workflow is real and welcome, but it belongs to your agent, your model, and your keys, driving the tracker through a real CLI, MCP server, and API. Agents are free clients of that surface, not billable seats. There is no per-request AI cost for us to pass back to you, because we are not running AI on your behalf. No meter to install means no meter to charge.

And it is not a vibe. The stance is written down as a binding pledge: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

What "no meter" looks like in practice

The tracker is the system of record. Your agent does the work against it, for free, through a real interface. Open a terminal and have your agent file an issue the same way it would in a script or in CI:

npm i -g radial.build
radial create "Audit every tool with a usage meter" -t ENG -p high --json

That is the real CLI, returning JSON your scripts and agents can read. The same call runs over MCP at mcp.radial.build or against api.radial.build/v1 with a scoped, revocable key. Run it once or ten thousand times. The invoice is the same flat number either way, because there is nothing in that loop we meter.

FAQ

What is an example of usage-based pricing?

The clean examples are infrastructure: AWS and Google Cloud bill for the compute and storage you provision, Twilio bills per SMS, and an LLM API bills per token generated. In each case the meter tracks a real, variable cost you actively chose to incur. The murkier examples are the ones that arrived recently: a tool you already pay a flat seat for adding an AI credit pool or per-action charge for a copilot you did not request. Same mechanism, very different fairness.

What is usage-based billing pricing?

It is billing where you pay only for what you consume in each cycle, also called metered or pay-as-you-go pricing. The vendor picks a value metric, meters your usage in real time, and charges a per-unit rate. It is the same model behind your electricity bill or an Uber fare. The question worth asking of any software vendor is whether the metered thing is a cost you chose to incur, or one the vendor added and handed back to you to watch.

How does usage-based pricing work?

The vendor selects a measurable metric (API calls, gigabytes, tokens, or copilot actions), tracks your consumption continuously, and multiplies usage by a predefined rate to produce the bill. You typically monitor a dashboard to avoid a surprise charge. The flip side, the one the marketing skips, is that the meter makes your cost variable and slightly unpredictable, which is exactly the thing a flat annual price removes.

What are the four types of pricing?

The common buckets are flat-rate (one fixed price), tiered (a few fixed plans), per-seat (priced by user), and usage-based (priced by consumption). Most modern SaaS blends them, and the AI era pushed many tools toward a hybrid: a per-seat base plus a usage meter for AI. Radial is deliberately the simplest version, flat per-user, billed annually, with no usage component to track.

Is usage-based pricing bad?

No. For infrastructure where cost genuinely scales with what you turn on, it is the fair model. It becomes a problem when it is grafted onto a tool you bought as a flat seat, to bill for an AI feature you did not ask for. The objection here is not to metering in general. It is to the meter showing up uninvited in the tools that are supposed to stay out of your way.

One number, the same every January

If you are tired of checking a balance on software whose entire job is to disappear, the answer is not a tool with a cheaper meter. It is a tool with no meter. One flat price, locked, with your agents riding free through real interfaces and a pledge that turns the promise into a commitment.

See the one number on pricing, or read why a tracker is boring on purpose and built to look the same next year.

Originally published on the Radial blog.

The Linear CLI Linear never shipped: driving your tracker from the terminal

Nico Acosta — Sat, 27 Jun 2026 13:12:33 +0000

If you searched for a Linear CLI, you already know the first surprise: there isn't an official one. Linear ships a hosted MCP server, a GraphQL API, and a TypeScript SDK, but no first-party command-line tool. What you find instead is a healthy little ecosystem of community CLIs, and a striking number of them were built specifically so an AI agent could drive Linear from the terminal.

That tells you something. The demand for a command line on top of an issue tracker is real, it is coming from engineers who live in the terminal, and increasingly it is coming from the agents those engineers run. This post is two things: an honest map of the Linear CLI options that exist today, and the argument for why the command line should be a first-class surface the tracker ships itself, not a wrapper you bolt on.

The Linear CLI options that actually exist

Linear's own developer surface is the GraphQL API and SDK. Everything below it on the command line is community-built. The well-known ones, as of mid-2026:

schpet/linear-cli: the most visible result, "Linear without leaving the command line." It ships a skill that helps AI agents use the CLI, which is a tell about who the audience is.
Linearis: a CLI "built for humans and LLM agents," with JSON output, smart ID resolution, and GraphQL queries tuned for agent use.
linctl: described by its author as "a Linear CLI purpose-built for agents like Claude Code."
Finesssee/linear-cli: a comprehensive CLI written in Rust, covering issues, projects, and cycles.
Composio's universal CLI: a connector layer that lets coding agents call Linear actions and triggers.

These are legitimate, and several are well made. If you use Linear and want a terminal workflow, one of them will probably get you most of the way there. The honest caveat is the one every community wrapper carries: it tracks an API it does not own. When Linear changes the GraphQL schema, the wrapper has to catch up, and you are depending on a maintainer's spare time for a surface that is load-bearing in your workflow.

Why "the CLI is community-built" is a structural fact, not an oversight

Linear is an excellent, GUI-first product. The keyboard craft is in the app: the command palette, the shortcuts, the speed of the interface. The command line was never the design center, so it landed in the community instead of in the box. There is nothing wrong with that choice. It is just a choice, and it has a consequence: the terminal is a second-class surface for Linear, supported by people who are not Linear.

Radial made the opposite choice. The CLI is a first-class surface, shipped and versioned with the product, sitting on the same REST API that everything else uses. It is not a wrapper around an API we reverse-engineered. It is the API, with a terminal on top.

What a first-class CLI looks like

The point of a command line on your tracker is that the work becomes scriptable. You file an issue without leaving the shell, you list your queue without a tab switch, and every command speaks --json so the same move pipes into anything:

radial create "Investigate 500s on checkout" -t ENG -p high --json

List what is on your plate the same way:

radial list --assignee me --status "in progress" --json

Because --json is on every command, the tracker stops being a place you visit and becomes a thing you script. CI can file an issue when a build breaks. A pre-commit hook can check what is assigned to you. And your agent can do all of it, because to the API there is no difference between you typing radial create and Claude Code calling the same endpoint over MCP. Every credential is a client of the API, not a billed seat, so the agents ride free.

That last part is the quiet through-line of the whole Linear-CLI ecosystem. Read the descriptions again: "built for LLM agents," "purpose-built for agents like Claude Code." People are not just asking for a terminal. They are asking for a surface their agents can drive. A tracker that ships the CLI and the MCP server itself, on one API, is meeting demand the community has been improvising against for two years.

Moving over is one command

If you are coming from Linear, the migration is a command, not a quarter. Export from Linear, preview the import dry first, then run it:

radial import --from linear export.json --dry-run

Drop --dry-run to bring your issues, projects, labels, comments, and history across for real. Your data is portable on the way out, too: one-command export is always available, so the CLI is not a trap, it is a door that swings both ways.

FAQ

Is there a CLI for Linear?

Not an official one. Linear ships a hosted MCP server, a GraphQL API, and a TypeScript SDK, but no first-party command-line tool. The community has filled the gap with several CLIs (schpet/linear-cli, Linearis, linctl, Finesssee/linear-cli, Composio), many of them built specifically for AI agents. They work, with the usual caveat that a community wrapper tracks an API it does not own.

Is a CLI outdated technology?

No, and the popularity of these agent-oriented Linear CLIs is the proof. A command line is the one interface a script and an agent can both drive without a human in the loop. As more of your workflow gets automated or handed to an agent, a scriptable, --json-speaking surface becomes more useful, not less. The GUI is for the human; the CLI is for everything else that needs to touch the tracker.

How is Radial's CLI different from a community Linear CLI?

It is first-party. The Radial CLI is shipped and versioned with the product, on the same REST API as the web app and the MCP server, so it does not lag behind a schema it does not control. A community Linear CLI is a wrapper a volunteer maintains against Linear's GraphQL API; when that API changes, the wrapper has to catch up.

Do my agents cost extra to use the CLI or API?

No. Every agent credential is a client of the API, CLI, or MCP server, not a billed seat, and there is no usage meter anywhere in the product. You pay one flat $50 per user, per year, billed annually, for the humans, and that price is locked at the rate you join. The Plain Software Pledge backs it: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

The short version

Linear never shipped a CLI, so the community shipped a dozen, and most of them are pointed at agents. That is demand telling you where the terminal belongs: as a first-class surface the tracker ships itself, on one API, free for the agents to drive. That is the bet Radial made.

See the developer surface on the developers page, or read how Radial compares to Linear on the one thing a cap table won't let Linear match.

Originally published on the Radial blog.

Linear vs Jira, and the third option neither names

Nico Acosta — Fri, 26 Jun 2026 13:13:14 +0000

If you are comparing Linear and Jira, you have probably already read the verdict ten times: Linear is fast and developer-first, Jira is powerful and enterprise-grade. That is true, and we will say it plainly below before we say anything else.

But the comparison everyone runs has a blind spot. Both tools answer "how should we track work." Neither answers "why does the bill keep climbing, and what happens when the AI meter turns on." That second question is the reason Radial exists, and it is the part this post is really about. First, the honest head-to-head.

Linear vs Jira, the fair version

These two tools start from opposite philosophies, and most teams already feel the difference within a day.

Linear is opinionated and fast. Fixed, sensible workflows instead of infinite configuration. A keyboard-first interface with a command menu that eliminates the mouse. It is built for engineering teams and product teams that want to move without administrative setup. The trade is flexibility: you do it Linear's way, and Linear's way is good.

Jira is the opposite bet: near-infinite customization. Any workflow you can imagine, deep analytics, capacity planning, Gantt-style roadmaps, and thousands of apps in the Atlassian Marketplace. It scales to large organizations tracking work across many teams and non-engineering departments. The trade is weight: most teams configure a fraction of it and absorb the slowness as the cost of breadth.

The honest summary the comparison sites converge on:

Choose Linear if you are an engineering-led startup or product team that values speed, a clean interface, and developer experience, and you do not need cross-department workflows.
Choose Jira if you are a large enterprise, work in a regulated environment, or need to connect product development to marketing, sales, and support in one system.

If your only axis is speed versus breadth, that decision tree is correct, and you can stop reading. The rest of this post is for the people who picked one, lived with it, and then watched the invoice.

The question both comparisons skip: the meter

Here is what the Linear-vs-Jira posts rarely put side by side, because it cuts against both:

Linear is per-seat per month, and its newer AI work (Coding Sessions) bills from a prepaid, USD-denominated AI credits balance. The base is a subscription; the AI is a meter.
Jira is per-seat per month ($0 free / about $7.91 Standard / about $14.54 Premium, plus Enterprise), and its AI layer, Rovo, ships a monthly credit allowance per seat (roughly 25 / 70 / 150 by plan) with overage billing announced. Rovo Dev is a further $20 per developer per month. The base is a subscription; the AI is a meter.

Same shape, two vendors. A per-seat line that grows with headcount, and a usage line that grows with how much AI work you run. Neither is wrong as a business model. But it means the number you sign up for is not the number you end up paying, and the gap widens exactly as your team leans into agents.

That is the option neither comparison names, because it is not one of them.

The third option: one flat number, and no meter at all

Radial is the fast, keyboard-first issue tracker engineering teams actually want, and it took the speed-and-developer-experience side of the Linear argument seriously: instant search, a command palette, list and board layouts, Cycles (time-boxed sprints), triage, projects. The job Linear does well, Radial does.

The difference is the part above. Radial's price is $50 per user, per year, flat, billed annually, locked at the rate you join. There is no AI credit balance, no usage meter, no overage line, because there is no AI in the product to meter. Your agents ride free: every agent credential is a client of the API, not a billed seat.

And the part that makes it a commitment rather than a slogan is the Plain Software Pledge, written down: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

Moving over is meant to cost a command, not a migration project. Radial deep-imports from both tools, so the comparison does not strand you on whichever one you are leaving. Run it dry first to see exactly what comes across:

npm i -g radial.build
radial import --from jira export.json --dry-run

Swap jira for linear if you are coming the other way. Issues, projects, labels, comments, and history come across in a single run. Every command takes --json, so the same move scripts from CI, and your agent can do the equivalent over MCP at mcp.radial.build.

Where Radial is honestly behind

A fair three-way comparison names the gaps. Against Jira, Radial does not have its breadth: no portfolio or initiative layer, no burndown or velocity dashboards, no Gantt roadmap, no thousand-app marketplace. If you genuinely run fifty teams with fifty different workflows, Jira is built for that and Radial is not. Against Linear, Radial does not yet ship presence indicators, multiplayer editing of descriptions, or notification email beyond invites.

If those are load-bearing for your team, that is a real reason to wait, and we would rather tell you now than lose your trust in a bake-off. What Radial will not be behind on is the price and the pledge.

FAQ

Is Jira better than Linear?

For large enterprises with complex, cross-department workflows and a need for deep customization and analytics, Jira's breadth wins. For engineering-led teams that value speed and developer experience, most comparisons land on Linear. "Better" depends entirely on whether you need Jira's configurability or you are paying for breadth you never use. If it is the latter, a fast, focused tracker like Radial or Linear will feel like a different category.

What is the difference between Jira and Linear?

Philosophy. Linear is opinionated and fast, with fixed workflows and a keyboard-first interface built for developers. Jira is endlessly customizable, with deep analytics and enterprise tooling built to scale across many teams and departments. Linear optimizes for speed and simplicity; Jira optimizes for flexibility and breadth.

Is Jira becoming obsolete?

No. Jira remains dominant in enterprise, and Atlassian is moving Data Center customers to cloud rather than retiring the product. The shift is narrower: teams that adopted Jira for engineering work, but never needed its enterprise breadth, are increasingly moving to faster, focused trackers. That is a fit problem, not an obsolescence one.

Who is Jira's biggest competitor?

Linear is the one named most in developer circles, which is why "Linear vs Jira" is the comparison people run. The quieter competitor is any tool that removes Jira's weight without adding a new tax, which is the lane Radial sits in: the speed of Linear, plus a flat locked price and a binding pledge against a usage meter.

How is Radial's pricing different from both?

Linear and Jira are per-seat per month plus a metered AI layer (Linear's Coding Sessions credits; Jira's Rovo credits with announced overage). Radial is a single flat $50 per user, per year, with no usage meter of any kind, agents riding free, and a written guarantee that your subscription goes free the day Radial ever adds a meter.

The short version

Linear wins on speed and developer experience. Jira wins on enterprise breadth and customization. Both bill per seat and meter the AI on top. Radial takes the speed side of that argument, then removes the meter entirely: one flat locked $50 per user per year, agents ride free, and a pledge that pays you if we ever break it.

See the one number on pricing, or read why is Jira so slow for the engineering reason the weight is not free. If you are coming from Linear specifically, here is the Radial vs Linear comparison.

Originally published on the Radial blog.

Give Claude Code access to your issue tracker in 5 minutes (MCP)

Nico Acosta — Thu, 25 Jun 2026 13:13:30 +0000

Here is the whole thing in one line. Claude Code talks to external systems through MCP, the Model Context Protocol, so if your issue tracker ships an MCP server, you can connect it once and your agent will file, search, and close issues without you copying anything back and forth.

Most of the setup guides you will find stop at the filesystem and GitHub servers. This one is about pointing Claude Code at an issue tracker, which is where the move actually pays off: the agent stops asking you what to work on and starts reading the work itself.

What MCP actually does here

MCP is an open standard. Claude Code is one client; an MCP server is the thing on the other end that exposes a set of tools. When you connect a server, its tools show up in Claude Code's tool list, and the agent can call them the same way it calls its built-in file and shell tools.

For an issue tracker, the tools are the obvious verbs: create an issue, search issues, list issues, comment, close an issue, run the triage queue. Once those are wired in, "what is left on RAD-219" and "file an issue for this flaky test" become things the agent does in its own loop, not things you go do in another tab and paste back.

Claude Code supports two transports: stdio for a local process, and HTTP for a remote, hosted server. The remote path is the shorter one, because there is nothing to install and authorization happens in your browser.

The 5-minute setup

Radial ships a hosted MCP server at mcp.radial.build. Adding it to Claude Code is one command, then one approval. From your terminal:

claude mcp add --transport http radial https://mcp.radial.build

That registers the server. Now start Claude Code and run /mcp, which lists your connected servers and lets you authorize the new one. Radial uses OAuth, so the browser opens, you approve the connection against your workspace, and the token comes back to Claude Code. There is no API key to generate, copy, or paste, and you can revoke the connection later in one click without touching anything else.

If you would rather keep the config in your project so a teammate gets it on checkout, drop it in .mcp.json at the repo root instead of adding it by hand:

{
  "mcpServers": {
    "radial": {
      "url": "https://mcp.radial.build"
    }
  }
}

Either way, the next time the agent needs to know what to build, it asks the tracker instead of asking you.

What your agent can do once it is connected

The server exposes the tracker's verbs as tools: create_issue, update_issue, search_issues, list_issues, comment, close_issue, list_projects, and triage_queue. So a session can go like this, in plain language to the agent:

"Search Radial for open issues assigned to me in the ENG team, then start on the highest priority one."
"I just fixed the login race condition. Close the issue and leave a comment with the root cause."
"While you were working you found a second bug. File it as a new issue, priority high, before you move on."

The agent reads the work, does the work, and writes the result back to the same place. You are not the message bus between the model and the tracker anymore.

There is a second reason this matters, and it is the one developers keep running into on big projects. When a project gets large, the reasoning behind decisions scatters: some in a chat window that resets when it fills up, some in a doc that drifted out of date, some lost entirely. As one developer put it, GitHub stores the code but not why you wrote it that way. An issue the agent files and comments on as it works is the cheapest durable home for that reasoning, and it lives in the same place the next agent session will look.

Local instead of remote

If you do not want a hosted connection, the same tools are available over stdio. The Radial CLI serves them locally:

radial mcp

Point any MCP client at that command and you get the identical tool set, running on your machine against your authenticated session. Same verbs, no remote server, your call.

Where the line is

One honest note, because it is the whole point of the product. The intelligence here is your agent, your model, your keys. Radial is the fast system of record the agent writes to. There is no copilot, no AI summary, no auto-triage, and no AI credit meter inside the tracker, because the agent already does that part and you already pay for it once.

That is also why the connection does not cost you anything extra. Every agent credential is a client of the API, CLI, or MCP server, not a billed seat. The price is $50 per user, per year, flat, billed annually, for the humans. Agents ride free, and the Plain Software Pledge is the binding version of that: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

FAQ

What is the difference between Claude Code and MCP?

Claude Code is Anthropic's command-line coding agent. MCP is the open protocol it uses to reach tools and data outside its built-in set. Claude Code is the client; an MCP server is what it connects to. They are not alternatives to each other; MCP is how Claude Code gets access to your issue tracker, your database, or anything else that speaks the protocol.

How do I add an MCP server to Claude Code?

For a remote server, run claude mcp add --transport http <name> <url>, then run /mcp inside Claude Code to authorize it. For a local one, point a stdio config at the command that serves it. You can also check a .mcp.json file into your repo so the server is configured for everyone on the project.

Do I need an API key to connect Claude Code to Radial?

No. The hosted server at mcp.radial.build uses OAuth, so you authorize the connection in your browser and Claude Code holds the token. Nothing to paste, and you can revoke it in one click. Scoped API keys exist if you want them for CI or a non-interactive agent, but they are not required for the Claude Code path.

Does connecting my agent over MCP cost extra?

No. Agent credentials never count as billed seats. You pay $50 per user, per year, for the humans on the workspace, and that number is locked at the rate you join. There is no AI credit meter anywhere in the product.

Can I use the same setup with Codex or Cursor?

Yes. The server is plain MCP, so any client that speaks the protocol can connect to the same eight tools. Claude Code is the example here because it is the most common, but the connection is not Claude-specific.

The short version

Connecting Claude Code to your tracker takes one command and one browser approval, and after that the agent reads the work, does the work, and writes the result back to the place it already lives. That is the wedge: not a smarter tracker, a tracker your agent can drive.

See the full tool list and the OAuth flow on the developers page, or read why issue tracking isn't dead if you got here from the threads about whether the tracker still has a job.

Originally published on the Radial blog.

Why is Jira so slow? A field guide to the 200-requests-per-ticket problem

Nico Acosta — Wed, 24 Jun 2026 13:13:21 +0000

If you have ever clicked a Jira ticket, watched a spinner, and felt a small part of your focus drain away, you are not imagining it. The slowness is real, it is structural, and once you understand where it comes from you stop blaming your laptop.

The short answer: Jira is slow because opening one ticket sets off a cascade of network requests, each waiting on the last, before the page is usable. The fix is not a faster machine. It is a tool built so the data is already there when you look.

What is actually happening when a Jira page loads

The most-quoted diagnosis comes from a developer on Hacker News, describing why a single ticket takes so long:

"Because it's a SPA trying to make 200 requests to get a ticket... and I'm barely exaggerating."

That is the shape of the problem. A modern single-page app renders a shell, then fires off a fan-out of API calls to fill it in: the issue body, the comments, the custom fields, the permissions, the linked issues, the watchers, the sidebar, each panel its own round trip. Many of them are sequential, because one response decides what the next request even is. The browser is fast. The network is the tax.

The numbers people report are not subtle. From another widely-shared thread:

"A customer I am currently working with has a JIRA instance which literally takes 13.04 seconds before it's done loading. It takes at least 10 seconds before the page will even let me scroll."

And the part that wears people down is not the worst case, it is the per-click drip:

"It has that slowness that makes my soul die a little every time I bring up a page, every time I click on a link, every time I make an edit."

These are real, cited anecdotes from real Jira users, not a benchmark we ran. But they all point at the same architecture: every interaction is a trip across the network, and the trips add up.

Why the architecture makes it hard to fix

Two things compound the round-trip problem.

First, a request is never free. A common engineering mistake, and the one underneath a lot of slow SPAs, is treating a network call as if it were a local function call. It is not. Even a fast call has latency, and a page that needs forty of them to render is forty chances to wait. You can cache, you can batch, you can parallelize, but as long as the source of truth lives on a server and the client has to ask for everything, the floor on "how fast can this feel" is set by the network, not the code.

Second, the form keeps growing. Slowness and bloat are the same disease seen from two angles. As another engineer put it:

"You don't like that the ticket form has 50 fields you don't need?"

Every field is more to fetch, more to render, more to validate. A tool that adds surface area for a decade ends up with a lot of surface area to load. The slowness is not a bug that shipped one day. It is the accumulated weight of everything the tool decided to become.

What a fast tracker does instead

The fix is an architecture choice, made before the first feature: keep the working set close to the user, so the common actions, open an issue, search, edit, do not wait on a server round trip to feel done.

That is the bet behind Radial. The product is deliberately one thing, an issue tracker, so there is no 50-field form to fetch and no dashboard suite fanning out behind every page. Opening an issue and searching are meant to feel instant because the data is already there, not because we optimized a slow path. Speed is a position you hold by saying no, not a setting you turn on.

We are careful here: we do not publish a latency number as a measured benchmark, because the only honest claim is the design goal, not a marketing figure. What we will say is that the whole tool exists to not make you wait, and that not adding the things that make tools slow is the entire strategy.

Leaving Jira is one command

If you have read this far, you are probably less interested in why Jira is slow and more interested in not using it. The migration is meant to cost a command, not a quarter. Export your Jira project, then preview exactly what will come across before you commit:

npm i -g radial.build
radial import --from jira export.json --dry-run

The dry run tells you how many issues, comments, relations, and labels would import, and surfaces any warnings, without writing anything. Drop the --dry-run to run it for real. Every command takes --json, so the same import scripts cleanly from CI, and your agent can do it over MCP at mcp.radial.build if you would rather not touch the terminal yourself.

FAQ

Why is Jira so slow to load?

Because opening a single page fans out into many network requests, often sequential, before the page is usable: the issue, comments, custom fields, permissions, linked issues, and more, each its own round trip. The browser is not the bottleneck, the volume of round trips is. The more fields and panels a page has, the more requests it takes to fill, which is why heavily-customized instances feel the slowest.

Is Jira slow because of my setup or the network?

It can be both, but the structural cause is the request fan-out, not your hardware. A faster laptop does not remove a round trip; it just waits a little less obviously. Self-hosted instances, large projects, many custom fields, and lots of plugins all add requests, which is why the same Jira feels slower in some companies than others.

Does Jira get slower as you add fields and plugins?

Yes. Every custom field, panel, and app adds data to fetch and render on the pages that show it. Slowness and "the form has 50 fields I don't need" are the same problem from two directions: more surface area to load. A tracker that stays small stays fast.

How do I move off Jira without losing my data?

Export your Jira project to JSON, then run radial import --from jira export.json. Run it with --dry-run first to preview the exact counts and any warnings before anything is written. Issues, comments, relations, and labels come across in a single command, and a full export back out is always one command away, so you are never locked in.

Is a faster issue tracker actually worth switching for?

If your team opens dozens of tickets a day, the per-click wait is a focus tax you pay all day, every day. The point is not a benchmark; it is that the tool gets out of the way. A tracker you forget you are using is the goal.

The short version

Jira is slow because of how it is built: one ticket is many round trips, and a decade of added fields means many things to fetch. The fix is not a faster machine, it is a tool designed to keep the data close and to never grow the 50-field form in the first place.

See the one flat price on pricing, or read why we think issue tracking isn't dead even after the category's most-loved tool said it was. When you are ready, leaving Jira is one command at /developers.

Originally published on the Radial blog.

Radial vs Linear: same speed, no meter, one locked price

Nico Acosta — Tue, 23 Jun 2026 13:17:26 +0000

If you are shopping for a Linear alternative, start with the honest part: Linear is the best issue tracker of the AI era. The speed, the keyboard craft, the command palette, the feel of the thing. That bar is real, and Radial is measured against it.

So this is not a teardown. It is a narrow claim. There is one structural thing Linear cannot do without unwinding the business its investors bought, and that one thing is the whole reason Radial exists: a flat, locked price with no meter, ever, written down as a guarantee.

What Linear does well, said plainly

Linear is fast. It is keyboard-first. Its agent story is good: third-party agents like Claude Code, Codex, and Copilot can join a workspace, get assigned issues, and open PRs, and Linear states outright that those agents do not count as billable users. So if your only question is "can my agent ride free," the answer in Linear is already yes.

We say this because it matters for the comparison. "Your agents ride free" is becoming table stakes. It is not the wedge. Anyone selling you a Radial-vs-Linear post that leads with free agents is selling you a feature both products have.

The difference is somewhere else.

The one structural gap: the meter, and the pledge against it

Here is what is metered in Linear: not seats for agents, but AI usage. Coding Sessions bill from a prepaid, USD-denominated AI credits balance. That is a per-seat price plus a usage line that climbs with how much AI work you run. It is a reasonable way to run an AI company. It is just a meter, and the meter is the thing.

Radial does not have one. The price is $50 per user, per year, flat, billed annually. Agents ride free, because every agent credential is a client of the API, not a billed seat. There are no AI credits anywhere in the product, because there is no AI in the product to meter.

And the part that makes it more than a marketing line is the Plain Software Pledge, written down and binding: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free.

That is the asymmetry. A tracker whose growth story leans on metered AI cannot make that promise without cannibalizing the story. The moat is not a feature Linear lacks. It is a commitment Linear's cap table will not let it make.

This is not anti-AI. AI is redefining plenty of products. Your issue tracker is not one of them. The intelligence belongs to your agent, your model, your keys. Radial's job is to be the fast system of record your agent writes to, without a bill for it.

The other gap: a first-class CLI

Linear ships a hosted MCP server and a full GraphQL API. What it does not ship is a first-class command-line tool. Radial does, and that is the asymmetry worth owning.

Moving over is meant to cost a command, not a quarter. Run the import dry first to preview exactly what comes across, then run it for real:

npm i -g radial.build
radial import --from linear export.json --dry-run

Deep import brings your issues, projects, labels, comments, and history. Every command takes --json, so the same move scripts cleanly from CI. Your agent can do the same over MCP at mcp.radial.build, or you can hit api.radial.build/v1 directly with a scoped, revocable key. The developer surface is shipped, not a roadmap promise.

Where Radial is honestly behind

A fair comparison names the gaps too. Today Radial has no presence indicators, no multiplayer editing of descriptions, and no notification email beyond invites. Linear has all three. If those are load-bearing for your team, that is a real reason to wait. We would rather tell you now than lose your trust in a bake-off.

What we will not be behind on is the price and the pledge.

FAQ

Is Radial a true Linear alternative?

For the core job, yes: a fast, keyboard-first issue tracker with projects, cycles, triage, instant search, and a command palette. Where it goes further is the developer surface (a first-class CLI alongside MCP and REST) and the pricing (one flat locked number, no meter). Where it is currently behind is presence, multiplayer editing, and notification email. Pick on those specifics, not on a vibe.

Is there an open-source or self-hosted Linear alternative instead?

There are several, and they are legitimate if self-hosting is a hard requirement: Plane is the most prominent. Radial is hosted, not open-source. The trade is that you get a managed, fast tracker with one-command export, so your data is always portable even though the server is ours.

Do my coding agents cost extra in Radial?

No. Every agent credential is a client of the API, CLI, or MCP server, not a billed seat. There is no AI credit meter anywhere in the product. You pay $50 per user, per year, for the humans, and that number is locked at the rate you join.

How is the price different from Linear's?

Linear is per-seat per month plus metered AI usage (Coding Sessions, billed from an AI credits balance). Radial is a single flat $50 per user, per year, with no usage meter of any kind, and a binding guarantee that your subscription goes free the day we ever add one.

How long does migrating from Linear take?

As long as it takes to run one command. Export from Linear, then radial import --from linear export.json, with --dry-run first to preview. Issues, projects, labels, comments, and history come across in a single run.

The short version

Linear is excellent, and its agents already ride free. Radial is the alternative for the person who wants that same speed without the meter, with a real CLI, at one price that never moves, backed by a pledge that pays you if we break it.

Read the one flat number on pricing, or see what we will and won't ship in the manifesto. And if you read the threads and just wanted a good issue tracker that stays one, here is why issue tracking isn't dead.

Originally published on the Radial blog.

Boring on purpose: the tool that disappears is the one that survives 2026

Nico Acosta — Mon, 22 Jun 2026 18:45:39 +0000

The tool you will still be using next year is the one you stop noticing. Not the one with the most demos, the longest changelog, or the newest agent in the sidebar. The one that opens, does its job, and gets out of the way. That is the whole bet behind building an issue tracker that is boring on purpose.

This is not a nostalgia pitch. It is a reaction to something the people who write the code are now saying out loud. AI fatigue crossed from a private grumble into named, mainstream developer discourse this year. An essay titled "AI fatigue is real and nobody talks about it" hit the top of Hacker News. The phrase that stuck with us: spending weekends evaluating new tools, terrified of falling behind, and ending the quarter more drained than any quarter before it. That is the cost of a stack where every tool is racing to become an AI company, and your attention is the thing being spent.

A tracker should not be one of those tools.

What "AI fatigue" actually is

AI tool fatigue is the exhaustion of juggling too many tools that each demand setup, updates, and a fresh mental model. It is not that any single tool is hard. It is that there are too many of them, each with its own dashboard, each shipping a copilot you did not ask for, each retraining you on where the buttons moved. Product Hunt lists dozens of new AI tools a day. Even after aggressive filtering, that is a steady drip of "should I be using this?" that never stops.

The counter-trend, the one quietly gaining ground in 2026, is the opposite instinct: pick the calm thing, commit to it, and spend the saved hours building instead of evaluating. The developers who look least frazzled are not the ones who tried everything. They are the ones who chose a small set of durable tools and stopped shopping.

A boring tracker is built for exactly that person.

Boring is a design constraint, not an apology

"Boring on purpose" is a stance with mechanisms behind it. Here is what it actually buys you.

No copilot to learn each quarter. The tracker does not summarize your standup or draft your tickets. There is nothing new to relearn when you open it on a Monday. The interface you learned in week one is the interface you keep.
No meter ticking in the corner. There is no AI credit balance to watch drain, no usage line on the invoice. One flat price, the same number every January.
Speed as the feature. It opens fast and search returns before you finish typing, because latency is a focus tax and the boring tool's job is to give your attention back, not take more of it. (We hold a fast performance gate as a shipping bar, not a benchmark we quote you.)
A roadmap that is supposed to look the same next year. Doing one thing well is the plan, not a phase before the pivot. That predictability is the product.

This is the part worth being precise about: boring does not mean anti-AI. The intelligence in your workflow is real and it is welcome. It just belongs to your agent, your model, and your keys, driving the tracker through real interfaces, not to a metered copilot bolted into a sidebar we own. The tracker stays a fast, trustworthy system of record. Your agent does the thinking. That distinction is the difference between a tool that fatigues you and one that disappears.

The durability argument

There is a harder, less sentimental reason to prefer the boring tool: it is more likely to still be there. One tracker logged roughly 95 AI-tool shutdowns and 101 acquisitions across an 18-month stretch. When you adopt something that sunsets in four months, the switching cost is brutal and nobody priced it into the hype. A tool that is boring on purpose is making a different promise: it will be the same issue tracker next year, doing the same one thing.

Two things make that a commitment instead of a vibe. Your data leaves in one command, JSON or CSV, always available, so you are never trapped. And the stance is written down as a binding pledge: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free. Calm software you cannot leave is just a nicer cage; the export and the pledge are what make "boring on purpose" trustworthy.

Verifiable today

The fastest way to feel what boring-and-fast means is to use it. Open a terminal and file an issue against your own workspace:

npm i -g radial.build
radial create "Cut the eval-every-tool habit" -t ENG -p high --json

That is the real CLI, returning JSON your scripts and CI can read. Every command takes --json. Your agent can do the same over MCP at mcp.radial.build, or hit api.radial.build/v1 directly with a scoped, revocable key. The developer surface is shipped, which is the unglamorous part most contrarian marketing skips.

FAQ

What is AI tool fatigue?

It is the mental and operational exhaustion of juggling too many AI tools at once, especially ones that overlap in features and each demand setup, updates, and a new mental model. It is driven by too much choice and too many dashboards, not by any single tool being hard. A tracker that ships no copilot and changes little is one fewer source of it.

Why do so many AI tools keep shutting down?

The space is churning fast: one count logged around 95 shutdowns and 101 acquisitions over 18 months. New tools launch daily, funding chases the frontier, and a lot of them sunset before they mature. That churn is exactly why durability is a feature. A tool built to stay the same is making a bet you can actually rely on.

Is boring software actually better?

For the jobs you do every day, often yes. "Boring" here means predictable, fast, and stable: no relearning, no meter, no surprise pivots. The exciting tool that reinvents itself every quarter costs you attention each time. The boring one gives that attention back, which is the entire point of a tool that disappears into the work.

Is "boring on purpose" the same as anti-AI?

No. It is bring-your-own-agent. The tracker never hosts, meters, or bolts in a copilot, but it ships the surface your agent runs on: a CLI, an MCP server, and a REST API. Your agent and your model do the intelligent work; the tracker is the fast system of record it writes to. The enemy is the uninvited copilot and the meter, not AI.

How do I keep using a tracker without falling behind?

You stop treating the tracker as a tool to keep evaluating. Pick one that does the job and is built to look the same next year, wire your own agent into it through real interfaces, and spend your saved evaluation time building. Falling behind is a function of churn; a tool that is boring on purpose removes itself from that race.

Pick the tool you can forget about

If you are tired of weekends spent evaluating tools and quarters spent relearning interfaces, the move is not a better copilot. It is a tracker that gets out of the way and stays that way. Track issues like it's 2019. Ship like it's 2026.

Read what we will and won't do in the manifesto, or see the one flat number on pricing. And if a tracker just walked away from the category on you, here is why we think issue tracking isn't dead.

Originally published on the Radial blog.

Issue tracking isn't dead. Your tracker just got bored of you.

Nico Acosta — Mon, 22 Jun 2026 17:03:45 +0000

Issue tracking is not dead. It is more important than ever, and the people who do it every day know that better than anyone. What got bored was one tracker, which decided the category was beneath its next act and pivoted to selling you agent management instead.

That is a real event, and it is worth being honest about. The best-built tracker of the AI era looked at the thing it does extremely well, a fast keyboard-first place to track the work, and called it finished. On Hacker News, the people who actually use it said the quiet part out loud: they just want a good issue tracker, and they are tired of watching every tool they like turn into something else.

We read those threads too. We built Radial for the person writing them.

What "issue tracking is dead" actually means

It does not mean teams stopped tracking issues. Look at any repo, any sprint, any incident channel. The work still needs a home with structure: a status, an assignee, a priority, a due date, the relations between the thing that is blocked and the thing blocking it. That need did not shrink. If anything, more agents writing more code means more work to track, not less.

What the headline means is narrower and more commercial: a tracker decided the tracker is no longer the product, and the agent layer on top is where the new money is. That is a fine bet for a company to make. It is just not a bet that helps you if what you wanted was a tracker that opens fast and stays out of the way.

So the category is not dead. A position opened up in it.

The Holdout's job

Someone has to keep building the boring one. The one that is still an issue tracker next year, and the year after. The one with no copilot to learn each quarter, no credit meter ticking in the corner, no quarterly relearning of where the buttons moved.

That is the whole pitch. An issue tracker. That's it.

It opens fast and search returns before you finish typing. Speed is the feature, because latency is a focus tax and focus is the one thing a tool cannot give back to you.
It runs from the keyboard. A command palette and real keyboard navigation, not a tour you dismiss.
It is driven by your agent, not one we sell you. A first-class CLI, an MCP server, and a plain REST API. Claude Code, Codex, whatever ships next week, all drive Radial through real interfaces.

This is not anti-AI, and that distinction matters. AI is redefining a lot of products. Your issue tracker is not one of them. The intelligence belongs to your agent, your model, your keys. The tracker's job is to be a fast, trustworthy system of record that your agent can write to without you getting a bill for it.

Verifiable today, not someday

The Holdout stance only counts if you can check it. So check it. Open a terminal and file an issue against your own workspace:

npm i -g radial.build
radial create "Stand up the new tracker" -t ENG -p high --json

That is the real CLI, doing the real thing, returning JSON your scripts and CI can read. Every command takes --json. Your agent can do the same over MCP at mcp.radial.build, or you can hit api.radial.build/v1 directly with a scoped, revocable key. The developer surface is shipped. Contrarian marketing is easy; shipping an OAuth server is the part most people skip.

And the part that keeps us honest is written down. Pricing is $50 per user, per year, flat, billed annually. Agents ride free, because every agent credential is a client of the API, not a billed seat. The rate you join at is the rate you keep. The pledge underneath it is binding: the day Radial ships a copilot, meters your usage, or charges you for AI you didn't ask for, your subscription is free. We are not asking you to trust a vibe. We wrote the consequence down.

FAQ

Is issue tracking actually dead?

No. One vendor declared its tracker finished and moved up the stack to agent management. Teams still track issues every day, and more code from more agents means more work to track, not less. The category did not die. A seat in it opened up.

So is Radial anti-AI?

No. Radial is bring-your-own-agent. We never host, meter, or bolt in a copilot, but we ship the surface your agent runs on: a CLI, an MCP server, and a REST API. The intelligence is yours. The tracker is the system of record it writes to. The enemy is the uninvited copilot and the meter, never AI itself.

Why does "your agents ride free" matter if other trackers also let agents in?

Agents getting access is becoming table stakes. The difference is the bill. In Radial an agent credential is a client, not a billed seat, and there is no AI credit meter anywhere in the product. One flat price, locked, with a written guarantee if we ever break it. The promise is what's unusual, not the API.

What if Radial pivots too, or shuts down?

Fair question, and the reason we made two things commitments instead of vibes. Your data leaves in one command, JSON or CSV, always available, so you are never locked in. And "boring on purpose" is the roadmap, not an accident: Radial is built to still be an issue tracker next year, doing the same one thing well.

How do I move off my current tracker?

Deep import from Linear or Jira brings your issues, projects, labels, comments, and history. Run it with --dry-run first to preview, then for real. The switch is meant to cost you a command, not a quarter.

You wanted a tracker. Here's one.

If you read the threads and thought I just want a good issue tracker, this was built for you. Track issues like it's 2019. Ship like it's 2026.

See what we will and won't do in the manifesto, or read the one flat number on pricing. And on the calm-software thesis underneath all this, here is why being boring on purpose is the point.

Originally published on the Radial blog.