Wally CLI: connect coding agents to hosted and local models

Wally's coding-agent and model routing scope

Wally addresses the gap between a coding agent and the model endpoint that agent expects. According to the README, one command can open OpenCode, Claude Code, Hermes, OpenClaw, DeepSeek Harness, or Prime Agent with the selected model already configured. If the requested agent is missing, Wally installs it first. This is useful for developers and teams that move between agents or between hosted inference and models running on their own machines, because they do not have to reproduce each agent's model configuration manually.

The supported execution paths differ in an important way. A hosted model such as GLM 5.3 Flash is billed against RunAnywhere credit after the user logs in. An open model can instead be downloaded and run locally without an account. Wally also says it can chat with a model in a terminal and serve one through an OpenAI-compatible API. That places Wally above individual model runners, although the README does not specify every endpoint, compatibility caveat, or server configuration option.

The project is aimed at developers rather than only application programmers. Its examples launch coding agents, select models, pull checkpoints, and classify a software symptom. Developers who need offline or account-free local operation can use the latter path, while hosted users need RunAnywhere credit. The choice of agent and model therefore determines both the user experience and the operational dependency.

Wally's Rust, CMake, and native SDK structure

The repository layout shows that Wally is not a plain Rust binary assembled solely by Cargo. Application code is Rust, while a packaged RunAnywhere SDK remains a native C++ kit behind a C ABI exposed through `src/sys`. `Cargo.toml` identifies the crate as `wally`, version `0.8.8`, with edition 2021 and Rust 1.93 as its minimum declared version. It produces both a `staticlib` and an `rlib`.

CMake remains the product build system. It builds the Rust crate as a static library and links it into the shipped executables together with the native kit. The `wally` Rust binary is described as a developer entry point for `cargo run` and integration tests, while the distributed executables are built through CMake. Two additional binaries, `fake_llm` and `harness_child`, exist only for local harness tests and do not ship with the product.

This architecture has a direct adoption consequence. Building source is not equivalent to cloning an ordinary command-line project and running `cargo install`. The README says that Wally is built with CMake against a prebuilt RunAnywhere C++ desktop kit, not the SDK source tree, and directs contributors to `CONTRIBUTING.md` for the procedure. Repository files such as `CMakeLists.txt`, `cmake/`, `build.rs`, and `rust-toolchain.toml` support that native build path. The design is reasonable for a desktop-linked inference tool, but it makes source builds more dependent on project-specific setup than a pure Rust crate.

Installing Wally on macOS, Linux, and Windows

The quickest documented installation uses the platform-specific installer. On macOS, only Apple Silicon is supported; Intel Macs are excluded. Linux support is limited to x86-64 or ARM64 systems using glibc 2.39 or newer, including Ubuntu 24.04+ and Debian 13+. On Windows, both x64 and ARM64 are documented.

For supported macOS and Linux systems, this installer adds `wally` to `PATH` for new terminals:

curl -fsSL https://raw.githubusercontent.com/RunanywhereAI/wally/main/install.sh | sh

On Windows, the PowerShell equivalent is:

irm https://raw.githubusercontent.com/RunanywhereAI/wally/main/install.ps1 | iex

After installation, open a new terminal on Windows. On macOS and Linux, the installer prints a command such as `. ~/.zshrc`, or the reader can open a new terminal. That PATH step matters because an already open shell may not see the installed command.

The first hosted-model workflow requires authentication before opening OpenCode:

wally account login
wally opencode -m glm-5.3-flash

The login command starts the account flow. The next command opens OpenCode using the hosted `glm-5.3-flash` model. If no model is specified, the documented default is also `glm-5.3-flash`:

wally opencode

To select a different default, use:

wally models default <model>
wally help

The first command changes the default model, while `wally help` exposes the CLI's available command help. No build output, login result, or successful agent session can be inferred beyond these documented commands.

Wally's hosted and local decision paths with Eve

Eve is separate from the coding and chat paths. The README describes it as RunAnywhere's hosted decision model, which scores explicit labels rather than generating prose. It is intended for yes-or-no questions, multiple choices, and ordered scores. A request supplies an input and one or more questions. This differs from a coding agent because Eve returns structured decisions instead of editing a repository or writing an answer.

The following hosted example asks whether a checkout symptom is a software bug and which team owns it:

wally decisions --input "Checkout is blank after Pay" \
  --ask "Is this a software bug?" \
  --choice "Owner=frontend,payments,account"

For automation, `--json` adds `request_id` and `http_status`, or returns an error document on failure. `--request FILE` accepts the complete typed request shape. Image requests support PNG, JPEG, and WebP in the cloud path. The README states that the request, including images, can be up to 24 MiB, while request content outside images is limited to 1 MiB. An image can be up to 64 MP as JPEG or 24 MP as PNG or WebP. Requests beyond those limits are rejected with HTTP 400 and a stated limit. On macOS, a HEIC image is converted to a full-size upright JPEG with EXIF and GPS removed.

Eve can also run locally. The README gives this sequence:

wally models pull clef-flash-9b
wally decisions --local -m clef-flash-9b \
  --input "Checkout is blank after Pay" --ask "Is this a software bug?"

`wally models pull` downloads the checkpoint. The `--local` selection then scores it in process through the SDK's decision component. Local and cloud transports share request flags, rendering, and JSON output. `--cloud` forces the hosted path. Images are documented as cloud-only in the general decision section, so local Eve adoption should not assume identical image support.

Wally's model switching and interface boundaries

Wally's main advantage is not that it supplies a new chat UI or coding agent. It acts as the connection layer between those tools and selected models. The README names several agents, but it does not promise that every agent supports every feature of every model. It points to `docs/EDITORS.md` for how agents are wired and where sessions live, and to `docs/ENGINES.md` for platform coverage and selection behavior. Those documents, rather than the main README, are the relevant checks before standardizing an agent and model pair.

Model selection is explicit. A command can name `glm-5.3-flash`, the default model can be changed, and open checkpoints can be pulled by name. Local operation avoids a RunAnywhere account according to the README, while hosted operation depends on credit. This gives users a clear account and billing boundary, but it does not remove hardware and operating-system constraints.

The terminal chat and OpenAI-compatible API paths expand Wally beyond agent launching. However, the README does not document their startup flags, default address, authentication settings, lifecycle controls, or exact compatibility boundaries. It would therefore be premature to treat the OpenAI-compatible API as a drop-in replacement for every OpenAI client. The project establishes that the capability exists, while operational details remain with the official documentation.

Eve has stricter boundaries than the other model modes. The README says decision models are refused by `wally run` and the coding tools, which direct callers back to `wally decisions`. This separation avoids treating a classifier checkpoint as a general conversational model. It also means a workflow that begins as a coding-agent request cannot transparently switch to Eve when the expected output is a label or ordered score.

Wally's license, release cadence, and upgrade boundary

The repository has an important metadata inconsistency. The README states that Wally is licensed under the MIT license and points to `LICENSE`, while the repository's `Cargo.toml` declares `license = "Apache-2.0"`. The README also says `Cargo.toml` must equal the product version in `versions.toml`, and it identifies the current crate version as 0.8.8. A reviewer who needs to determine the applicable terms should inspect the repository's actual `LICENSE` file and resolve this discrepancy with the maintainers. This article does not provide legal advice or treat the package metadata as proof of the final licensing terms.

The recorded last push was on 2026-10-15. Releases listed for v0.8.8, v0.8.7, and v0.8.6 were published on 2026-10-14, 2026-10-10, and 2026-10-10. Those dates show recent release activity, but they do not define Wally's long-term compatibility policy or migration cost. The repository is not archived.

The native dependency makes upgrades more involved than copying one standalone script. Users of installers should account for platform support, `PATH`, agent installation, model selection, and any changes in supported engines. Source builders must also account for the Rust toolchain, CMake, the packaged native kit, and version synchronization across repository files. The release page is documented as providing versions and checksums, which gives users specific release artifacts to verify, but the README does not state whether CLI sessions can be resumed across versions.

Editorial conclusion

Developers should adopt Wally when they want coding agents, terminal chat, local checkpoints, and hosted models behind one documented CLI. Organizations with unsupported operating systems, incompatible Linux runtimes, or a requirement to build entirely from public sources should verify those constraints first. The first deployment check should confirm that the target agent, selected model, platform, and credential path work together.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. RunanywhereAI/wally on GitHub