CLI tool
athasdev/athas avatar
athasdev/athas

Athas (athasdev/athas): a Tauri code editor with AI agents, Git and vim keybindings

A lightweight, cross-platform code editor, built with Tauri (Rust and React) with Git support, AI agents, vim keybindings.

3,091 stars257 forksTypeScriptNOASSERTION

At a glance

What is it?
Athas is a cross-platform code editor built on Tauri with a React front end and a Rust workspace behind it. The README lists AI agents, Git integration, LSP support, database viewers and enterprise policy controls alongside the install and build paths.
Who is it for?
Athas fits engineers who want a Tauri-based editor with vim keybindings, Git and LSP in one binary, and who are willing to run a 0.x release. Teams needing a settled plugin ecosystem or a documented rollback path should wait.
Can I use it commercially?
Check first. The repository uses a licence we do not classify automatically, so read its LICENSE file before any commercial use.
Is it still maintained?
Yes. The repository last received commits 3 days ago.
What is it written in?
Mainly TypeScript, according to GitHub's language statistics.

Answers come from the project's GitHub data, last synced on October 1, 2026, and from our analysis. They are not legal advice.

Editorial analysis

What Athas is trying to be, and who that suits

Athas is a desktop code editor, not a framework or a library. The README describes it as "a lightweight, cross-platform code editor, built with Tauri (Rust and React) with Git support, AI agents, vim keybindings." The feature list is broad: AI agents, Git integration, syntax highlighting, LSP support, vim keybindings, an integrated terminal, database viewers, collaboration, and enterprise policy controls under a managed mode plus an extension allowlist. That last item is unusual for a 0.x editor and signals an intended audience beyond individuals. The repository layout backs this up. The Cargo workspace has separate crates for runtime, tooling, lsp, remote, wsl, project, version-control, extensions, terminal, ai, exec-path, github, fff-search, debugger and database. Each capability is a crate rather than a folder of ad hoc code. The primary language is TypeScript, which is where the React front end lives, but the native side is Rust. If you are choosing an editor because you want a small download and a native shell rather than an Electron bundle, the Tauri choice is the relevant fact. If you want a mature extension marketplace with years of third-party packages, this is not that. The version is 0.14.2, and the repository is not archived; the last push was on 2026-09-09.

How the Tauri shell, the Rust crates and the React front end fit together

The architecture is visible in two files. The root Cargo.toml declares a workspace whose members include src-tauri plus the crates listed above. The package.json is private and versioned 0.14.2, with scripts that drive both sides: test:rust runs cargo test --workspace --no-fail-fast, while check:frontend, check:services and check:design run separate validation passes. That split tells you the data flow. The React layer in src/ renders the editor UI and talks to the Rust side through Tauri commands; the Rust crates own the work that must be native, such as the terminal, the LSP client, version control, the debugger and database access. The ai crate is a peer of the others, so agent functionality is implemented in Rust rather than bolted on as a web service. The workspace also patches crates.io for tauri itself, pinning it to a specific git revision, and vendors phf_generator 0.8.0. Both are signs of a project tracking upstream closely enough that it needs a pinned revision. For an editor, that is a reasonable trade: you get the newer Tauri behaviour, and you take on the risk of building against a moving dependency. The release profile sets lto = "thin" and codegen-units = 1, which lengthens release builds in exchange for a smaller, faster binary. The dev profile for libduckdb-sys sets debug = 0, which suggests DuckDB is compiled in for the database viewers and that its debug info is expensive enough to disable.

Installing Athas and opening a real project

The README gives two install routes: a quick install script and package managers. On macOS and Linux the script is fetched and piped to sh. The README states that the scripts detect your operating system and architecture, download the latest stable release, and verify its SHA256 checksum when one is available, and it links both scripts so you can read them first.

bash
curl -fsSL https://athas.dev/install.sh | sh

On Windows the equivalent is a PowerShell one-liner. The README notes you can review the Windows script before running it.

powershell
powershell -ExecutionPolicy ByPass -c "irm https://athas.dev/install.ps1 | iex"

If you want the preview channel rather than stable, the README shows an extra argument passed through to the script.

bash
curl -fsSL https://athas.dev/install.sh | sh -s -- --preview

Package managers are also documented. Homebrew on macOS uses a cask, and Windows has both WinGet and a Scoop bucket.

bash
brew install --cask athas
powershell
winget install --id=athasdev.Athas -e
powershell
scoop bucket add athas https://github.com/athasdev/scoop-athas
scoop install athas

Linux users who prefer packages can take native .deb or .rpm builds, or a portable .tar.gz bundle, from the GitHub Releases page. The README points to an installation guide for detailed platform steps, install locations and uninstall instructions. After installing, the first real use is opening a project directory; the editor's Git integration, LSP support and terminal are all documented as features, so the natural check is whether language servers attach in the workspace you already work in. To build from source instead, the README requires Node.js 24, Bun 1.3.14 and Rust, then two commands.

bash
bun setup
bun dev

The README says bun setup installs dependencies and checks the native requirements for your platform.

Where Athas will disappoint you

The version number is the first limitation. 0.14.2 means the project is still pre-1.0, and the release list shows a preview channel running alongside stable, with v0.14.1-preview.5 and v0.14.1-preview.4 landing within days of each other before v0.14.2. That cadence is good for people who want fixes quickly and bad for anyone who needs a frozen target. The README does not document rollback, so if a release breaks your setup, the path back is whatever the installation guide says about uninstalling, not a documented downgrade flow. Second, the feature list is wide for a 0.x tool: AI agents, collaboration, database viewers, a debugger, WSL and remote crates. Breadth at this stage usually means some areas are thinner than the marketing list implies, and the README does not say which. Third, the licence is AGPL-3.0. If you embed, modify or distribute Athas as part of a networked service, the copyleft obligations reach further than a permissive licence would; that is a reason to read the LICENSE file rather than assume. Fourth, the repository pins Tauri to a specific git revision and vendors a crate. Building from source therefore depends on that revision remaining fetchable. Finally, the build requirements are not trivial: Node.js 24, Bun 1.3.14 and a Rust toolchain, plus platform-specific native dependencies that bun setup checks for. If you only want to edit text, the install script is the short path and the source build is not.

Athas versus Zed, and how the two approaches differ

Zed is the closest comparison a prospective user is likely to make, and the search data shows people asking for it directly. The difference is in the shell. Zed is a native editor written in Rust with its own GPU-rendered UI layer. Athas wraps a React front end inside Tauri, so the interface is web technology and the native work is delegated to Rust crates behind Tauri commands. That choice has consequences. A React front end is easier to iterate on and easier for contributors who already write TypeScript, which matches the repository being primarily TypeScript. A fully native UI has fewer layers between input and pixels. Athas also ships AI agents and database viewers as first-class crates, which is a different bet from an editor that treats AI as an optional plugin. Neither approach is strictly better; they fail differently. Athas's risk is the Tauri and webview dependency chain, which is why the workspace pins a Tauri revision. Zed's risk is a smaller pool of contributors familiar with its UI stack. If your reason for leaving a heavier editor is memory use, the Tauri shell is the relevant argument for Athas. If your reason is input latency at large file sizes, that is a claim the README does not make and you would need to measure yourself.

Maintenance, release cadence and what the licence means for you

The repository is not archived, and the last push was on 2026-09-09, the same day v0.14.2 was released. Stable and preview releases are published separately, and the install script can target either. Preview builds are a real cost: if you install with --preview you are opting into a channel that moves faster than the stable tag, and the README does not describe a downgrade path between the two. Upgrading through Homebrew, WinGet or Scoop follows those package managers rather than the script, so the version you get depends on how the maintainers publish to each channel. The licence is AGPL-3.0. For an individual using the editor locally, the practical effect is minimal. For a company that modifies Athas and offers it to users over a network, the AGPL's source-availability condition is the part that matters. The repository also includes a Contributor License and Feedback Agreement, which governs contributions rather than use. This is not legal advice; read LICENSE and, if you are distributing anything built on Athas, talk to someone qualified. The .env.example file shows that the desktop app talks to production service URLs by default, with overrides for local, staging or preview builds through variables such as VITE_API_URL, VITE_EXTENSIONS_CDN_BASE_URL and VITE_UPDATE_BASE_URL. That is worth knowing if your environment restricts outbound network access, because the editor is not purely offline by design.

Editorial conclusion

Athas fits engineers who want a Tauri-based editor with vim keybindings, Git and LSP in one binary, and who are willing to run a 0.x release. Teams needing a settled plugin ecosystem or a documented rollback path should wait. Before adopting, verify the current release on the GitHub Releases page, check whether the AGPL-3.0 terms fit how you distribute your own work, and read the installation guide for platform-specific install locations and uninstall steps.

Frequently asked questions

What is the Athas code editor?

Athas is a lightweight, cross-platform code editor built with Tauri, using Rust and React. Its README lists AI agents, Git integration, syntax highlighting, LSP support, vim keybindings, an integrated terminal, database viewers, collaboration and enterprise policy controls.

How do I install Athas on macOS or Linux?

The README gives a quick install script, curl -fsSL https://athas.dev/install.sh | sh, which detects your OS and architecture, downloads the latest stable release and verifies its SHA256 checksum when one is available. Homebrew users on macOS can run brew install --cask athas instead.

Does Athas support vim keybindings?

Yes. Vim keybindings are listed as a feature in the README alongside syntax highlighting, LSP support and the integrated terminal.

How does Athas compare with Zed?

The README does not compare Athas with other editors. What the repository shows is that Athas uses Tauri with a React front end and a Rust workspace split into crates for LSP, terminal, version control, AI and database work, while the primary language is TypeScript.

What licence does Athas use?

The README states the licence is AGPL-3.0, and the LICENSE file is in the repository root. The repository also contains a Contributor License and Feedback Agreement, which applies to contributions rather than to use of the editor.

Official sources

  1. athasdev/athas on GitHub
  2. Issues
  3. Project website
  4. README
  5. Releases
Add this badge to your README

If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.

Add this badge to your README

markdown
[![Hysen Labs](https://hysenlabs.com/badge/athasdev-athas.svg)](https://hysenlabs.com/projects/athasdev-athas)