/jump to repo

Repos Recent Bookmarks Watched Notes Tags Discover Compare Stats GitHub

Repository brief

exo-explore/exo

Read the upstream summary on the left, browse the cached forks below it, and load each fork comparison into the right-hand panel.

Cached analysis

cached 2026-03-30T15:35:38.009Z

1mo ago

exo-explore/exo

exo-explore/exo is an active open source project for running frontier AI locally. It is heavily forked and starred, with recent commits and ongoing development focused on distributed local inference, device clustering, and model-serving improvements.

Loading tags...

Stars43,162

Forks2,976

Default branchmain

Last pushed2026-03-30T14:57:26Z

Recommended shortcuts

Jump straight into Discofork's strongest cached fork picks, or open a compare view in one click.

Forks

Choose a fork to inspect

10 of 10 fork briefs

Maintenance:

Magnitude:

Sort:

Selected

Choose this fork only if you want its alternative backend/platform direction. If you want the current exo experience for local cluster serving, dashboard management, and MLX-based distributed inference, upstream looks like the safer default.

Choose this fork if Rockchip NPU support is the requirement; choose upstream if you want the broader, more current exo feature set and the standard MLX-centered experience.

Choose this fork if you want a more opinionated, UI-heavy local cluster build and can tolerate drift from upstream. Stick with upstream if you want the broadest compatibility, freshest fixes, and less risk around removed server/eval paths.

Choose upstream if you want current exo features and active development. Choose this fork only if AMD GPU compatibility or an older, pinned behavior is the main requirement and you are comfortable owning the maintenance gap.

Prefer this fork only if its older, home-cluster-focused workflow matches your needs and you are comfortable carrying maintenance risk. For most adopters, upstream looks like the safer choice because it is much more active and materially ahead.

Prefer this fork only if you want a bespoke distributed-inference codebase and are willing to maintain it yourself. If you want current exo features, bug fixes, and lower upgrade risk, upstream is the safer choice.

Prefer this fork only if you need its specific customizations and are willing to inherit maintenance risk. For most adopters, upstream is the safer choice because it is active and materially ahead.

Choose this fork only if you specifically want the Roxonn node/participation direction and can absorb maintenance burden. If you want the newest exo capabilities and broad compatibility, upstream is the safer choice.

Prefer this fork only if you specifically need its hardware-compatibility or local-ops changes and are willing to own maintenance. For most adopters, upstream is the safer choice because this fork is materially stale and likely missing many recent fixes and features.

Choose this fork if you want the home-cluster framing plus a few concrete usability and compatibility patches, and you do not need the latest upstream features. Choose upstream instead if you care about active maintenance, new multimodal and dashboard work, or staying close to the current exo codebase.

Fork comparison

risingsunomi/exo-pt

54/100

slowing

significant_divergence

Choose this fork only if you want its alternative backend/platform direction. If you want the current exo experience for local cluster serving, dashboard management, and MLX-based distributed inference, upstream looks like the safer default.

Likely purpose

Rebase exo around PyTorch/torchtune-style workflows and broaden platform/backend support, likely trading upstream's MLX-centric distributed serving experience for a different inference path.

Best for

Users who specifically want a PyTorch/torchtune-based exo variant; Developers porting exo ideas to Windows or AMD GPU environments; People comfortable maintaining a fork and accepting incompatibility with upstream; Experimenters who care more about backend changes than the polished upstream cluster UI

Additional features

PyTorch/torchtune-oriented fork direction
Windows-oriented installation and asyncio support
AMD GPU detection support
VRAM deallocation and memory-management tweaks
Alternative backend experimentation such as tinygrad-related work
Expands API, schema, or SDK surface area for downstream integrations and generated clients.

Missing features

Likely lags upstream by 200 commits and appears materially behind active mainline development
Upstream MLX-centric distributed inference stack appears reduced or replaced
Large portions of the dashboard and API surface were rewritten or deleted, so the original cluster management/chat UX may be harder to use
Upstream model-serving and auto-parallelism code appears heavily altered, so compatibility with the latest exo cluster features is uncertain
Some upstream behavior appears to be removed, disabled, or intentionally stripped down in this fork.
Some upstream plugin, tool, or MCP-style integration paths may be reduced or disabled.

Strengths

Strongly customized for a different technical direction than upstream
May fit users who need non-MLX backends or Windows-centric workflows
Large code churn suggests substantial experimentation rather than a thin wrapper fork

Risks

High divergence makes upstream merges and documentation harder to follow
The fork is old relative to upstream's 2026 activity, so fixes and new features may be missing
Removed or rewritten dashboard/API pieces may break the original exo experience
Quality and stability are hard to infer from the provided facts because the fork has very large deletions

exo-explore/exo · Discofork