# AI-Horde: Community-Powered Distributed AI Generation Without the Cloud Bill

> AI-Horde is a free, community-run distributed inference cluster under AGPL-3.0 that lets anyone request AI-generated images and text by routing jobs to volunteer GPU donors. The kudos system determines queue priority without money changing hands, and the middleware can be deployed privately inside an enterprise network.

**Haidra-Org/AI-Horde** — A crowdsourced distributed cluster for AI art and text generation

- Repository: https://github.com/Haidra-Org/AI-Horde
- Stars: 1,588 · Forks: 179
- Language: Python
- License: AGPL-3.0
- Published: 2026-09-16 · Updated: 2026-09-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/haidra-org-ai-horde

## What AI-Horde is and the problem it solves

AI-Horde addresses the resource barrier that stops most individuals from running state-of-the-art image and text generation models locally. The README frames the project in the tradition of Folding@home and SETI@home: volunteers share spare computing power, and the collective resource makes advanced AI accessible to anyone, including people without a GPU and without funds for a commercial API.

The public instance at aihorde.net supports two distinct generation types: image generation through models like Stable Diffusion, and text generation through large language models including Pygmalion and Llama-family models. Requests enter a queue that is served by volunteer workers running software on their own machines. A request as simple as asking for a painting of a sunset over mountains is routed by the system to an available worker in the same way a ride-sharing app matches a passenger to a driver.

AI-Horde is not a model or a hosted API in the conventional sense. It is middleware. The README describes it as an enterprise-level ML-Ops crowd-sourced distributed inference cluster. The middleware can run as the public service at aihorde.net, or it can be deployed privately inside any enterprise environment to coordinate an internal pool of GPU workers.

## The kudos system: priority without money

The central mechanism that keeps AI-Horde equitable is the kudos system. Kudos are non-monetary priority points. Workers earn kudos when their machines process other users' requests; those kudos can then be spent to receive faster service on the worker's own requests, or left unspent to help others.

The README is explicit on two constraints: kudos never expire and kudos can never be bought or sold. Attempting to trade kudos violates the Terms of Service. Users with more kudos receive faster queue positions, but any user, including anonymous ones, can submit requests at no cost.

Anonymous usage is fully supported. A user with no account submits requests with the anonymous key and waits at the back of the queue. Registering an account, which requires only an OAuth2 flow according to the README, gives the user a persistent kudos balance and the ability to accumulate priority over time by contributing their own GPU as a worker.

The kudos accounting code and the full explanation of how kudos are calculated live in the local documentation index at docs/README.md within the repository.

## Technical architecture and the technology stack

The middleware is written in Python and targets Python 3.12, as shown in pyproject.toml (requires-python = ">=3.12,<3.14"). It uses Flask for the web layer, SQLAlchemy with PostgreSQL as the database, and Redis for caching. The version in pyproject.toml is 5.1.11.

The Docker Compose file defines three services: the aihorde application container, a PostgreSQL container (using a custom image at ghcr.io/haidra-org/ai-horde-postgres:latest), and a Redis container. The application binds on port 7001. The docker-compose.yaml shows the standard startup path:

```yaml
services:
  aihorde:
    build:
      context: .
      dockerfile: Dockerfile
    ports:
      - "7001:7001"
    depends_on:
      postgres:
        condition: service_healthy
      redis:
        condition: service_started
```

The Dockerfile uses a two-stage build. The build stage uses uv version 0.9.18 (specified as an ARG) to compile Python wheels from uv.lock. The run stage installs from the pre-built wheels. An optional AI_HORDE_DEPENDENCY_GROUPS argument allows including optional groups such as telemetry-profiling.

The request and job lifecycle is documented in the haidra-assets repository's workers.md file, which the README links to. The local docs/README.md covers the kudos accounting explanation, reference implementation, and operational procedures for maintainers.

## Running AI-Horde as a worker and contributing GPU time

Two worker types exist, corresponding to the two generation modes. Image generation workers run software that connects to the horde and offers Stable Diffusion capacity. Text generation workers offer LLM inference for KoboldAI-compatible requests. The README provides separate documentation files for each: README_StableHorde.md for image workers and README_KoboldAIHorde.md for text workers.

A worker registers with the horde, announces the models it can serve, and begins polling for jobs. When a user submits a request that matches the worker's announced capabilities, the job is dispatched to that worker. The worker earns kudos proportional to the work done.

From the operator's perspective, contributing a worker is the recommended way to build a kudos balance quickly. The README notes that users with more kudos receive priority. Operators who run image generation workers can list available models on their worker through configuration; the horde_model_reference package (referenced in requirements.txt) provides the canonical vocabulary of model identifiers, sampler capabilities, and which sampler and scheduler combinations are valid for each model.

The README warns that workers should not commit production signing material or credentials to any CI workflow triggered by pull requests, consistent with general security hygiene for publicly accessible repositories.

## Integrating with the AI-Horde REST API

The public instance exposes a REST API documented at aihorde.net/api/. Third-party websites, games, and applications use this API to submit generation requests and poll for results. The README describes this as a supported use case; a partial list of services already integrated with AI-Horde appears on the main website.

For private deployments, the same REST API runs on port 7001 of the self-hosted instance. The API supports both authenticated and anonymous requests. Authenticated requests carry an API key that identifies the account and its kudos balance.

The OAUTH_CLIENT_ID flow documented in the README allows integrating Hugging Face OAuth for user management in self-hosted deployments. The application also exposes performance and statistics through a Grafana instance at grafana.aihorde.net for the public service; operators of private deployments would need to configure their own monitoring.

The requirements list shows stripe>=15,<16 as a dependency, which is used for payment infrastructure supporting donations. Kudos itself remains non-purchasable; stripe is used only for the donation flow.

## Private deployment and what it covers

The README states that the AI-Horde middleware can be deployed privately within any enterprise environment, installed within hours, and scaled within days. A private deployment gives an organisation a dedicated inference cluster using its own GPU resources without routing requests through the public horde.

For a private deployment, the Docker Compose setup covers the application, database, and cache. The .env_template file in the repository provides the required environment variable skeleton. The PROFILE environment variable selects which .env file the application reads; docker sets it to PROFILE=docker, which reads .env_docker.

The AGPL-3.0 licence is the main constraint for private enterprise use. AGPL-3.0 requires that if you modify the server code and provide a network service using those modifications, the modified source must be made available to users of that service under the same licence. Organisations that plan to run a modified private deployment and allow employees or external users to access it must comply with this requirement. The LICENSE and LICENSES/ directories in the repository cover the individual file licences.

## Limitations and the cases where AI-Horde is not the right fit

Queue times on the public instance depend on the number of active workers and the kudos balance of the requestor. There is no guaranteed latency. A user with no kudos and many other requests in the system may wait a long time. The README does not document any Service Level Agreement or performance commitment for the public service.

Content generated by volunteer workers passes through whatever models those workers choose to run. The middleware includes content moderation dependencies (bleach and alt-profanity-check appear in requirements.txt), but the README does not describe exactly what moderation policies are enforced at the API layer for the public instance. Operators of private deployments are responsible for configuring appropriate moderation for their context.

For applications that require a specific model version, guaranteed output determinism, or strict data handling compliance, a self-hosted inference stack with a known model and controlled environment is more appropriate. Services like Hugging Face Inference Endpoints or a self-managed vLLM deployment give the operator direct control over model identity, hardware, and data path, which AI-Horde's distributed architecture cannot match.

The public service has been running and is community-maintained; the last push to the repository was on 2026-09-25.

## Conclusion

AI-Horde is the right choice for developers and researchers who want access to Stable Diffusion or open LLMs without paying per-inference costs and who are comfortable with variable queue times determined by their kudos balance. Teams that need guaranteed latency, data privacy guarantees, or control over which specific model version runs their job should run their own inference stack. The AGPL-3.0 licence means any modifications to the server code must be released under the same terms; organisations that plan to build proprietary services on top of a modified fork should read the licence carefully before deploying. To get started, register at aihorde.net, note the API key from your account settings, and call the REST API directly or through one of the client applications listed on the public instance website.

## FAQ

### Is AI Horde Anonymous?

Yes. The README states that anyone can use AI-Horde, even anonymously, without registering an account. Anonymous users are placed at the back of the queue; registered users with a kudos balance receive faster service.

### Is AI Horde free?

The public service at aihorde.net is free to use. The README describes it as a completely free, community-run service. Kudos cannot be bought or sold; they are earned by contributing compute as a worker.

### How to use AI Horde API?

The REST API is documented at aihorde.net/api/ for the public instance. Requests can be submitted anonymously or with an API key from a registered account. The README lists a partial set of third-party clients and applications that already integrate the API.

## Sources

- [Haidra-Org/AI-Horde on GitHub](https://github.com/Haidra-Org/AI-Horde)
- [Issues](https://github.com/Haidra-Org/AI-Horde/issues)
- [License: AGPL-3.0](https://github.com/Haidra-Org/AI-Horde/blob/main/LICENSE)
- [README](https://github.com/Haidra-Org/AI-Horde/blob/main/README.md)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/haidra-org-ai-horde