# Loom: A Research Coding Agent With a Rust Workspace and Server-Side LLM Proxy > Loom is an experimental Rust coding agent for developers who want to inspect or contribute to its REPL, tool system, conversation store, and provider integrations. Its own warning excludes everyone except Geoffrey Huntley, while the proprietary licence and unstable APIs make it unsuitable as a general-purpose dependency. **ghuntley/loom** — if your name is not Geoffrey Huntley then do not use loom - Repository: https://github.com/ghuntley/loom - Stars: 1,655 · Forks: 230 - Language: Rust - License: MIT - Published: 2026-10-16 · Updated: 2026-10-16 · Language: en - Canonical page: https://hysenlabs.com/projects/ghuntley-loom ## Loom's Restricted Audience and Coding-Agent Scope Loom addresses a specific but unusual problem: it is an AI-powered coding agent intended for interactive development work through a REPL. According to the README, its agents can perform file system operations, analyze code, and use other tools while conversing with an LLM. That places it in the broad category of coding assistants, but the README does not establish exactly which workflows are supported or which tools are enabled in a default installation. The audience restriction is unusually strict. The README says, "If your name is not Geoffrey Huntley then do not use." It labels Loom a research project that is experimental and unstable, warns that APIs may change without notice, and says features may be incomplete or broken. There is no support, no documentation guarantee, and no warranty. This is not merely a stability warning. It is an explicit usage condition, so treating the repository as an ordinary public coding-agent dependency would conflict with the project owner's stated instruction. The repository layout points to Geoffrey Huntley and developers contributing to his research implementation. The Svelte 5 frontend, Rust workspace, specifications, infrastructure files, and numerous provider crates make source-level study possible, but permission and licensing questions must be resolved before reuse. The README does not document installation for outside users, supported platforms, a general configuration workflow, or a production readiness guarantee. It also does not describe safeguards around every tool that can modify a developer's files. ## How Loom Routes Agent Requests Through Rust Loom is organized as a Cargo workspace containing more than 30 Rust crates, plus a separate Svelte 5 web frontend. The main behavioral path starts with `loom-cli`, whose `ProxyLlm-Client` sends HTTP requests to `loom-server`. The server's `LlmService` then communicates with providers such as Anthropic or OpenAI. Streaming responses return through the server as SSE, so the CLI does not need to handle provider credentials directly. That server-side proxy is the clearest architectural decision in the README. API keys are stored only on the server, while clients use routes under `/proxy/{provider}`, including `/complete` and `/stream`. This separates client orchestration from provider access. It also means the server occupies a central position in every LLM interaction and must be considered when examining deployment, authentication, logging, and request handling. Around that path are specialized subsystems. `loom-core` contains core abstractions, types, conversation state, and tool orchestration. `loom-tools` implements agent capabilities through a registry and execution framework. Provider integrations occupy separate `loom-llm-*` crates. Other workspace members cover conversation persistence, OAuth and ABAC authorization, GitHub App integration, source-control mirroring, audit records, jobs, Kubernetes integration, Weaver remote execution, search providers, secrets, analytics, and terminal UI components. This separation can make focused changes easier to locate, but it also creates a large surface for contributors to understand and validate. ## Weaver, Threads, and Loom's Server-Side State Loom extends beyond a direct CLI-to-provider exchange with several server-side systems. Weaver represents remote execution environments using Kubernetes pods. That capability may be relevant to isolated agent work, although the README does not document how pods are provisioned, which resources they receive, how credentials reach them, or whether this subsystem is usable outside the author's environment. The thread system provides conversation persistence and synchronization, and the architecture table states that it supports FTS5 search. This indicates that stored conversations can be retrieved and searched rather than existing only in terminal output. The repository also includes dedicated crates for session management, audit, database access, spooling, secrets, and source-control mirroring. Those names indicate a broader service architecture, but they do not establish that every listed feature is complete or connected to a usable client path. Analytics, OAuth, magic links, ABAC authorization, feature flags, and kill switches appear as additional server concerns. The presence of kill switches is relevant to an experimental agent that can invoke development tools, yet the README gives no example configuration or operational procedure for them. The specifications directory is identified as the index for architecture, configuration and security, analytics, editor integration, and remote execution. It is the first project-specific source to consult for missing operational details. The README does not say whether remote execution is optional, disabled by default, or limited to a particular deployment. ## Building Loom's CLI and Server with Nix or Cargo The README provides development build instructions, but it does not provide an installation package, release artifact, or supported first-use sequence. Because the repository has no GitHub releases, the documented route begins with building from source. Nix is the preferred approach and uses `cargo2nix` for reproducible builds with per-crate caching. Build the CLI from the repository root with: ```bash nix build .#loom-cli-c2n ``` This command selects the documented CLI build target. Build the server separately with: ```bash nix build .#loom-server-c2n ``` The README also exposes a generic crate pattern, but its angle-bracket placeholder is a build-target template rather than a literal command: ```bash nix build .#-c2n ``` For development without the named Nix targets, Cargo can build the workspace and run its Rust test suite: ```bash cargo build --workspace cargo test --workspace ``` The first command builds workspace members, while the second invokes their tests. No post-build configuration, provider credential procedure, server startup command, or REPL invocation is documented in the README, so these instructions do not establish how to complete a first agent conversation. The `specs/README.md` file is identified as the categorized index of design documentation and is the first file to consult for additional startup information. ## Loom's Check Targets, Web Stack, and Contribution Surface The workspace includes several code-quality entry points. Rust formatting and linting can be invoked directly, while `make check` is documented as a full check for formatting, linting, building, and testing. These are development controls rather than evidence that the agent is stable or suitable for production. ```bash cargo clippy --workspace -- -D warnings cargo fmt --all make check ``` The Makefile also exposes targets for the Svelte web application. Its help text names `web-install`, `web-dev`, `web-build`, `web-test`, `web-lint`, `web-format`, and `web-check`. Top-level repository entries include `Cargo.lock`, `Cargo.nix`, `flake.nix`, `flake.lock`, `devenv.nix`, `docker/`, `infra/`, `TEST_PLAN.md`, `TODO.md`, and `.pre-commit-config.yaml`. Their presence shows a substantial development and deployment structure. It does not confirm that container images, Kubernetes deployment, or the Svelte interface are ready for external use. A contributor can start from `specs/README.md`, `AGENTS.md`, `TEST_PLAN.md`, and `make check`, but the README does not define an external contribution process or explain how patches should be submitted. ## Why Loom Is the Wrong Tool for Most Teams Loom's limitations are decisive for an adoption decision. It has no GitHub releases, no stable API promise, no support, no documentation guarantee, and an explicit prohibition on use by anyone other than Geoffrey Huntley. It is also marked `SPDX-License-Identifier: Proprietary`, with all rights reserved. A proprietary label means external copying, modification, redistribution, and commercial use cannot be assumed; the repository does not grant an open-source-style permission set. The implementation is also broader than the documentation. More than 30 crates cover provider access, remote Kubernetes execution, authentication, analytics, auditing, source control, email, search, secrets, and multiple interfaces. That scale can slow onboarding even for Rust developers. Some named capabilities may still be research components, but the README does not separate completed features from placeholders clearly enough to confirm their status. A real alternative is an established editor coding assistant with a documented local workflow and licensed tool interface. Such a product differs by moving the primary interaction into the editor and often placing model access under a provider-controlled client rather than requiring contributors to operate a 30-plus-crate Rust service workspace. Loom instead centers its design on a REPL, a core agent state machine, server-side provider proxying, Kubernetes-backed Weaver environments, and persisted threads. That architecture may be useful to contributors who understand its boundaries, but it is the wrong choice for a team seeking predictable support, straightforward installation, and clear reuse rights. ## Loom's Maintenance Signals and Upgrade Exposure The repository is not archived, and its last push was on 2026-04-10. The README warns that APIs can change without notice. Code activity therefore does not reduce compatibility risk for an adopter. The main upgrade cost is likely source-level rather than binary migration. Because this is a Cargo workspace with named provider, server, CLI, authentication, database, and tool crates, changes to core types or service interfaces may affect several members. The repository has no published GitHub releases, so the README provides no release-note history or upgrade procedure against which to assess breaking changes. Licensing also affects maintenance planning. The source headers and README identify the project as Proprietary, and the license field in the repository metadata is unknown. This review cannot determine what a recipient may legally do with modifications or whether outside contributions receive usable rights. That uncertainty is separate from technical stability. The adoption boundary is direct: only the named owner has an express invitation to use the project, and other contributors need authorization before treating Loom as reusable code. ## Conclusion Loom is appropriate only for Geoffrey Huntley and contributors working under his stated terms. Engineers seeking a supported, reusable coding agent should not adopt it, while anyone reviewing the source should first verify `SPDX-License-Identifier: Proprietary`, the stated no-support policy, and the stability of the interfaces they intend to modify. ## FAQ ### Who is allowed to use Loom? The README explicitly says that anyone whose name is not Geoffrey Huntley should not use it. It also labels Loom a research project with no support or documentation guarantees. ### Can I build the Loom CLI and server with Nix? According to the README, the preferred commands are `nix build .#loom-cli-c2n` for the CLI and `nix build .#loom-server-c2n` for the server. ### Does Loom keep LLM API keys on the client? No. The documented architecture stores API keys server-side and routes CLI requests through `loom-server`, which communicates with providers such as Anthropic and OpenAI. ### Does Loom have GitHub releases or a documented upgrade path? The repository has no GitHub releases, and the README does not document a release or upgrade procedure. It warns that APIs may change without notice. ### Can I use Loom in a commercial project? The repository identifies itself as Proprietary and does not grant open-source-style reuse rights. The README also tells everyone other than Geoffrey Huntley not to use the project. ## Sources - [ghuntley/loom on GitHub](https://github.com/ghuntley/loom) - [Issues](https://github.com/ghuntley/loom/issues) - [README](https://github.com/ghuntley/loom/blob/trunk/README.md) --- Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/ghuntley-loom