SWE-ReX: the licence field names a file the tree does not have

The licence field points at LICENSE and the tree has LICENSE.txt

The manifest declares the licence as a file reference, `license = {file = "LICENSE"}`, and the repository's top level does not contain a file with that name. What it contains is `LICENSE.txt`. A file-object licence declaration tells the build backend which file to read and embed, so a name that does not resolve is either a rename that was missed or a declaration that quietly stops carrying the text. The classifier list separately says `License :: OSI Approved :: MIT License`, and the repository's own licence field records MIT, so the substance of the claim is consistent across two sources even though the third one points nowhere. Anyone who needs the licence text verbatim, for a legal review or a redistribution, has to find the file rather than trust the declaration. The extension is an unusual one for an MIT project and is worth correcting on its own.

requires-python says 3.10 and the only version classifier says 3.11

The project metadata contradicts itself on the floor. `requires-python` is set to 3.10 or newer, so an install on 3.10 will be attempted and not refused. The classifier list, which is what package indexes search and render, contains a single Python version entry and it is 3.11. So a user on 3.10 finds an installable package, and a user on 3.11 sees a project that appears to require 3.11 while it does not. The same classifier block still carries the scaffolding comments from the packaging tutorial it was copied from, including a note asking how mature the project is and listing 3 as Alpha, 4 as Beta and 5 as Production. No maturity classifier follows that comment. There is also a stray trailing comma inside the dynamic version list, and the build-system table keeps a comment explaining that the table is required if used, in a file where it is used.

daytona is marked work in progress and the dev extra depends on it

The install block is five lines, four of them optional backends:

pip install swe-rex
# With modal support
pip install 'swe-rex[modal]'
# With fargate support
pip install 'swe-rex[fargate]'
# With daytona support (WIP)
pip install 'swe-rex[daytona]'
# Development setup (all optional dependencies)
pip install 'swe-rex[dev]'

The daytona line is annotated work in progress, yet it is a declared extra with `daytona` and `daytona-sdk` pinned at 0.21 or newer, and the dev extra lists `swe-rex[modal]`, `swe-rex[fargate]` and `swe-rex[daytona]` as dependencies of its own. So a development install pulls all three cloud SDKs including the unfinished one. There is also an oddity in the AWS pair: the modal extra includes `boto3` alongside `modal>=1.0`, so a non-AWS provider drags in the AWS client, and the fargate extra pulls `boto3` as well.

FOOTER_IMPLEMENTATION_SUMMARY.md and test_footer.py are at the top level

The repository root tells a story about what shipped unfinished. Alongside the expected entries there is `FOOTER_IMPLEMENTATION_SUMMARY.md`, a summary document about a footer, and `test_footer.py`, a test file outside the `tests/` directory where the real suite lives. Neither belongs to a sandboxed execution runtime, and both point at documentation-site work that used the repository as its workspace. The rest of the documentation setup is visible and substantial: `mkdocs.yml` at the root, a `docs/` directory, and a dev extra carrying the documentation toolchain, including mkdocs-material, mkdocstrings, a glightbox extension, an include-markdown plugin, griffe-pydantic for schema-aware API docs, and `mike` for versioned documentation. That last one explains why the README can be 279 words and still be the front door, since versioning implies the docs site is expected to change alongside the code.

One release in thirteen months, and three tags named three different ways

The release history is thin and the last entry is old. The three listed releases are v1.2.0 on 2025-02-25, v1.2.1 on 2025-03-05 and v1.4.0 on 2025-08-14. The default branch was last pushed on 2026-09-28, roughly thirteen and a half months after that newest tag, so the code you would install from the branch is far ahead of the newest published version, and there is no release naming the intermediate work. The listed tags also disagree on their own release names: one is titled with the tag including its prefix, one is titled with the bare number, and one has no release name at all. None of that is fatal, but combined with the dynamic version declaration it means the only reliable way to know what you have is to read the installed package rather than the releases page.

Eight unbounded base dependencies, including a web server stack

The base dependency list is eight names: fastapi, uvicorn, requests, pydantic at 2 or newer, pexpect, bashlex, python-multipart and rich. Only one carries a version constraint. That means a fresh install resolves the other seven to whatever is current, which for a framework meant to run unfamiliar code is a wider surface than the constraint list suggests. Three of them, fastapi, uvicorn and python-multipart, exist to serve HTTP, so the local-only path still installs a web server stack. The two that do the actual work are pexpect for driving interactive sessions and bashlex for parsing shell input, and bashlex in particular is the piece that has to keep up with whatever syntax an agent decides to emit. The keyword list still reads nlp, agents and code, which is a leftover from an earlier scope for a project whose stated job is execution.

The README is 279 words and hands you to a docs site

What the visible documentation does establish is the shape of the abstraction. SWE-ReX is a runtime interface for sandboxed shell environments, letting an agent run any command in any environment, and the agent code does not change whether execution is local, in a Docker container, on an AWS remote machine, on Modal, or somewhere else. It recognises when a command has finished, extracts the output and the exit code, and returns them, and it lets an agent drive interactive tools such as ipython or gdb, with many sessions running in parallel the way a person keeps several shells open. The stated origin is SWE-agent and SWE-agent enigma, and the demo is SWE-agent running 30 SWE-bench instances at once. What is absent from those 279 words is just as informative: no configuration, no security model, no API surface and no failure behaviour, all of which sit behind the documentation link the install section ends on.

Editorial conclusion

Use SWE-ReX when your agent needs to run interactive commands in environments you already have, because the value is the abstraction over local shells, Docker, remote machines and Modal with the agent code unchanged across them, and because it understands completion rather than just streaming. Do not adopt it expecting a stable release train: the newest tag is v1.4.0 from 2025-08-14 while the default branch was pushed on 2026-09-28, so the branch you would install from is well ahead of anything tagged. Before you build on it, confirm three packaging details yourself, the licence file the manifest points at, whether your interpreter is 3.10 or 3.11, and whether the daytona extra, which the documentation marks work in progress, is one you want in a dev install.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. SWE-agent/SWE-ReX on GitHub