Getting it into your agent
One page per mod, every tool's command on it. A separate URL per tool would split the same page into five that compete with each other.
npx agentmods add skills/omnigent-ai/omnigent/dockernpx skills add omnigent-ai/omnigent --skill dockergit clone --depth 1 https://github.com/omnigent-ai/omnigentWhat it costs to keep this loaded
Counted locally with the o200k_base tokenizer, which is exact for GPT models; Claude uses its own tokenizer and its counts differ. Treat this as one consistent yardstick across the catalogue rather than a bill. Prices are per million input tokens.
| Model | Per session | Once invoked |
|---|---|---|
| Fable 5 | $0.00084 | $0.01278 |
| Opus 5 | $0.00042 | $0.00639 |
| Sonnet 5 | $0.00017 | $0.00256 |
| Haiku 4.5 | $0.00008 | $0.00128 |
Grade A, and why
deploy-docker-compose scanned grade A with 0 findings against 26 rules in 11 categories — prompt injection, anti-refusal, data exfiltration, privilege escalation, supply chain, agent snooping, system-prompt leakage, SSRF and excessive agency — measured 3d ago.
A static scan of the body, not an audit. Every finding is printed with the line that produced it so you can judge whether it matters here. A mod is markdown that instructs an agent; that is exactly why what it instructs is worth reading.
Nothing flagged
None of the 26 patterns this scan looks for appear in this file: no shell pipes, no recursive deletes, no credential paths, no hidden text, no instruction-override or anti-refusal phrasing, no agent-config snooping. That is not a guarantee, it is the absence of the things that are checkable.
How it starts
The opening of the file, as written. The whole thing — 88 lines — stays where its author put it; the contents beside it link to each section on GitHub.
Run Omnigent as a Docker compose stack
The Dockerfile here is the single image used by every non-Databricks
deploy path. It bundles the FastAPI server + a pre-built web SPA
into a slim Python runtime. The compose file pairs it with Postgres
and exposes the server on port 8000.
The image is "external runner only" — it does NOT include tmux,
the harness SDKs, or anything that would let it execute agent code
in-process. Runners live on user machines and dial in via the
WebSocket tunnel. This keeps the image small (~250 MB), the security
boundary clean (server doesn't execute user code), and the deploy
shape consistent across hosts.
The same Dockerfile also has a host target — the prebaked Omnigent
HOST image (omnigent-host) that remote sandboxes boot from
(omnigent sandbox create --provider modal, server-launched managed
hosts). It is the inverse profile: full omnigent install plus git +
tmux, no SPA, no psycopg, no server entrypoint. Both images are
published by the same workflows with the same :sha-<short> /
:latest / :vX.Y.Z tag scheme. See the "Host image" section in
README.md here.
TL;DR — bring it up
cd deploy/docker
cp .env.example .env # edit POSTGRES_PASSWORD at minimum
docker compose up -d --build
docker compose logs -f omnigent # Ctrl-C when you see "Uvicorn running"
Server is on http://localhost:8000.
Files
Dockerfile |
Multi-stage build with two final targets. web-builder (node:20) runs npm install && npm run build on web/. builder (python:3.12) installs omnigent into /opt/venv; server-builder overlays the SPA bundle from web-builder and adds psycopg. The default target (runtime) copies the venv + /build/ from server-builder and runs entrypoint.py. --target host builds the host image instead (from builder: omnigent + git/tmux, no SPA/psycopg/entrypoint). |
Dockerfile.dockerignore |
BuildKit-aware exclude. Trims deploy/databricks/, deploy/aws/, tests, dev tooling — keeps the build context small. |
entrypoint.py |
Server process entrypoint. Reads DATABASE_URL, runs Alembic migrations, builds the SQLAlchemy stores, calls create_app(), runs uvicorn. Single source of truth for what env vars the container respects. |
docker-compose.yaml |
Two services: postgres (16-alpine, persistent volume) and omnigent (built from the Dockerfile, depends on postgres healthcheck). Build context is ../.. (repo root). |
.env.example |
Documents every env var the compose file passes through: POSTGRES_PASSWORD, OMNIGENT_PORT, all the OMNIGENT_AUTH_* and OMNIGENT_OIDC_* vars. |
README.md |
Customer-facing quickstart + the OIDC walkthrough (GitHub OAuth, Google Workspace, generic OIDC). |
What ships with it
12 files beside SKILL.md in the same directory: the scripts, references and assets a skill reads on demand. Not counted in the per-session cost; read them before you install if any of them is executable.
What this file has done since we first saw it
Hashed on every crawl. A supply-chain change to an agent config is a question of when, not whether, so the history is kept rather than the latest state alone.
- 3d ago First seen · 88 lines · 84 tokens per session scan A 39a70e63bc7e
deploy-docker-compose is a skill published in the GitHub repository omnigent-ai/omnigent (9,591 stars, last pushed today), licensed Apache-2.0. It adds 84 tokens to every session and 1,278 once invoked, about $0.0004 per session on Opus 5. A static security scan graded it A with 0 findings. No closer match exists in the catalogue, so it is treated as the original; first seen 2026-08-30.
Other skills, from other repositories
no-mistakes
Validate your code changes through the no-mistakes pipeline - automated code review, tests, lint, docs, push, PR, and CI - before they reach upstream. Use when the user asks to run no-mistakes, gate or ship or validate their changes, push safely, asks you to do a task and then validate it, or invokes /no-mistakes.
mnemosyne-context
Load this when working on the mnemosyne memory system — its repo, sync server, memory databases, or CI. Covers architecture, the surface/sync data model, dev workflow (tests/ruff/CI matrix), release policy, and known gotchas that are easy to get wrong. Use for any "mnemosyne" dev or devops task, or when a…
hermes-memory-providers
Install and configure Mnemosyne as a Hermes Agent memory provider — local SQLite with vector search, episodic consolidation, and temporal knowledge graphs.
docker
Manage Docker containers, images, volumes, and Compose stacks via the docker CLI — list, inspect, logs, run, build, stop, remove, compose up/down. Use for local container ops.
wrangler
Cloudflare Workers CLI for deploying, developing, and managing Workers, KV, R2, D1, Vectorize, Hyperdrive, Workers AI, Containers, Queues, Workflows, Pipelines, and Secrets Store. Load before running wrangler commands to ensure correct syntax and best practices. Biases towards retrieval from Cloudflare docs over…
mnemosyne
Persistent cross-session memory via Mnemosyne — store, recall, and consolidate facts, preferences, and context.