{"slug": "a-turnkey-toolkit-for-agentic-development-with-flox", "title": "A Turnkey Toolkit for Agentic Development with Flox", "summary": "Flox released a GitHub repository, agentic-development-with-flox, that consolidates nearly 80 turnkey Flox environments for agentic development, covering harnesses including Claude Code, Codex, OpenCode, Hermes Agent, Pi and OpenClaw. Flox positions its cross-language, cross-toolchain package and virtual environment manager as the reproducible layer of the agent stack, letting agents search millions of historical package versions and run conflicting dependencies such as OpenSSL 1.1.1q and 3.0.19 side by side without containers or VMs. Because the repo's environments ship no committed manifest.lock file, first-time activation resolves dependencies via the Flox Catalog and requires a free FloxHub login through `flox auth login`; a valid lockfile removes that requirement.", "body_md": "# A Turnkey Toolkit for Agentic Development with Flox\n\n[Claude Code](https://github.com/anthropics/claude-code), [Codex](https://github.com/openai/codex), [OpenCode](https://github.com/anomalyco/opencode), [Hermes Agent](https://github.com/nousresearch/hermes-agent), [Pi](https://github.com/earendil-works/pi), [OpenClaw](https://github.com/openclaw/openclaw). These are the agentic harnesses people can’t seem to stop obsessing about. But the harness *by itself* isn’t actually the most important tool in the agentic toolkit. Arguably, it’s the domain- or use-case-specific enhancements—the skills, tools, persistent memory, sandboxes, software for managing swarms of agents at once—that most matter.\n\nThese give coding agents an understanding of their environing world, what they can do, what they have to work with, what matters… and what doesn’t. This also presupposes a *definite environment* in which an agent runs: a **world** consisting of pinned software packages, standard shell settings, and runtime services. It’s the **one** part of the stack that can be made reproducible, the one thing you can control… even when the behavior and output of stochastic agents isn’t and can’t.\n\nEnter **Flox**: a cross-language, cross-toolchain package manager that works across operating system and CPU/GPU architectures. Agentic tools use Flox to discover, find specific versions of, and install *just* the right dependencies, searching among *millions* of historical package versions. Flox doesn’t require using containers, installing (or changing) system-wide packages, or clobbering installed dependencies.\n\n### Worlds within worlds\n\nBecause Flox is also a cross-platform, cross-language, cross-architecture **virtual environment manager**, agentic tools won’t burn tokens resolving dependency conflicts. It’s even straightforward to run conflicting versions of dependencies in the same runtime, at the same time. Need OpenSSL versions 1.1.1q and 3.0.19 *in the same [Flox environment](https://flox.dev/glossary/#flox-environment)*, side by side? No problem!\n\nBest of all, Flox runs directly on your system—no containers or VMs required.\n\nAnd when you (or your Hermes, Pi, or Claude Code minions) are ready to share what you’ve created, the Flox environments that you built and perfected locally Just Work when friends, coworkers, or random users (human and agentic alike) pull and run them on their own machines.\n\nRead on to find out why Flox and [FloxHub](https://hub.flox.dev) are perfect for vibe coding, prototyping, and agentic engineering… and how the Flox environments you work with locally travel to CI and prod, too.\n\nLooking for a specific agentic tool? Skip straight to the category that interests you:\n\n## Agentic development with Flox\n\nThis [repo](https://github.com/flox/agentic-development-with-flox) consolidates nearly 80 environments into a one-stop resource for agentic development. Each folder is its own turnkey Flox environment, complete with a **`README.md`** that explains what it is, how it works, and what features / affordances it offers.\n\nClone it to get started:\n\nOnce you [download and install Flox](https://flox.dev/docs/install-flox/install/), you can start Flox environments by running:\n\nNone of the repo’s environments includes a committed **`manifest.lock`** file, so first-time [activation](https://flox.dev/glossary/#activation) must resolve dependencies via the Flox Catalog. That requires a FloxHub login ([which is free](https://flox.dev/blog/flox-catalog-login-requirement-what-you-need-to-know/)): just run **`flox auth login`** first. After a successful resolution, Flox saves the [lockfile](https://flox.dev/glossary/#lockfile) locally, and activation with a valid lockfile doesn’t require login. If you want to try one of these environments, **`cd`** into its folder before activating it.\n\nIf an environment defines services—like MCP servers, databases, model servers, workflow scheduling engines (like Airflow), and so on—you can either start them at runtime or from within an activated session.\n\nThis is all you need to start working with any of these tools, once you’ve configured whatever model credentials they require. As for the AI agents/assistants included with this repo, several get [the knowledge + context](https://flox.dev/blog/focusing-on-the-code-not-the-cruft/) they need from the Flox **`flox`**, **` floxify`**, and **` flox-debug`** skills; others will benefit from reading and referring back to the **`FLOX.md`** file that’s baked into the root of this repo. Flox retired its own MCP server in October 2026, chiefly because—as a thin wrapper around our CLI—agents could use the CLI directly. Flox focused its efforts on skills to make the best use of the CLI, bolstered by scripts to lower token costs and increase determinism.\n\nSome tools don’t need to know anything about Flox: Flox just provides the world (and a declarative, predictable mechanism for reproducing this world) that lets them run anytime/anywhere. *How* they run and what you do with them is up to you—or (Skynet isn’t a thing yet, right?) *them*…?\n\nNeed validated production runtimes?\n\nThe CUDA Kickstart Program gives teams a guided path to deploying hardened, validated CUDA-accelerated environments in production.\n\n### Making agents reproducible, too\n\nFlox is also sponsoring [Agent Stacks](https://github.com/agent-stacks), an open source project aimed at making the agents themselves reproducible. Consider everything that goes into a typical agent setup: the agent, its skills, plugins, MCP servers, and the runtimes those components depend on. Install all of that ad hoc, and two developers running the “same” agent can end up running very different software.\n\nAgent Stacks packages these components together, pins their versions, and gives you a launcher that makes everything available to the agent without modifying your global configuration. Its [agent-pkgs](https://github.com/agent-stacks/agent-pkgs) repository already contains hundreds of packaged plugins, including the Flox skills, and there's a [Claude Code reference implementation](https://github.com/agent-stacks/claude-code) you can try today.\n\nThe specification is still a draft, and features like sandboxing and [secrets management](https://flox.dev/glossary/#secrets-management) remain works in progress. But the idea is compelling: if we're going to make [development environments](https://flox.dev/glossary/#development-environment) reproducible for agents, why not make the agents themselves reproducible?\n\n### Terminal coding agents\n\nAnthropic's official Claude Code CLI bundled with the Flox **`flox`**, **` floxify`**, and **` flox-debug`** skills. These give Claude Code the knowledge + context to discover packages, create and modify Flox environments, and troubleshoot the ones that don’t work as expected. Creates a turnkey Claude Code development environment with built-in Flox integration. The activation hook also removes the old Flox MCP registration if it finds one.\n\n**Note**: This environment should pick up new versions of Claude Code as they become available; just run **`flox upgrade`** within the repo directory to force an upgrade.\n\nRun it: `cd claude-code && flox activate`\n\nOpenAI's local AI coding agent with ChatGPT account integration and approval-based command execution. (For full filesystem access, use **`codex --sandbox danger-full-access`**; approval controls are separate.) This environment includes the Flox skills and removes the old Flox MCP entry if one is present.\n\nRun it: `cd codex && flox activate`\n\nOpen-source AI coding agent built for the terminal. Its TUI lets you switch between “build” (for interactive development) and “plan” (for analysis + code exploration) agents. In “plan” mode, OpenCode defaults to read-only behavior, asks before running shell commands, and is geared toward planning changes. You can point OpenCode at Anthropic’s Claude, OpenAI’s GPT models, or Google Gemini, along with local providers (like Ollama). Uses a client/server architecture so the TUI is just one possible client. (You can run the agent on one machine and drive it from another client). OpenCode offers an optional (beta) desktop app, plus an internal “@general” subagent that can perform complex searches + multi-step tasks.\n\nRun it: `cd opencode && flox activate`\n\nA deliberately minimal terminal coding agent. Pi gives the model four tools—read, bash, edit, write—and lets you add what you need with skills, extensions, prompt templates, themes, or Pi packages. It supports multiple providers and models, so you don’t need to buy into a single model vendor to use it. And it has an appealingly small amount of machinery between you, your code, and the model.\n\nThe Flox environment includes the **`flox`**, **` floxify`**, and **` flox-debug`** skills. Pi has also added native MCP support, for anyone who still wants to connect tool servers. (Skills and MCP aren’t enemies. One supplies instructions and practices; the other supplies connections to external systems.)\n\nRun it: `cd pi && flox activate`\n\nCharm's glamorous, stylish, and surprisingly powerful AI coding agent front-end. (**Full disclosure**: We here at Flox are fans.) Ships with a self-bootstrapping wizard that encrypts/stores secrets using system keyring (if available). Supports multiple providers—including Ollama! The Flox skills are pre-integrated, too. Arguably the most versatile agentic coding assistant out there.\n\nRun it: `cd crush && flox activate`\n\nGitHub Copilot’s terminal-based agent, with repository context and access to GitHub workflows. Talk to it about a codebase, ask it to investigate issues or make changes, and review what it proposes before letting it run commands. The Flox environment includes the Flox skills, so Copilot can work with the same package and environment setup as the other agents in this repo.\n\nRun it: `cd copilot-cli && flox activate`\n\n### Claw-adjacent agents\n\nThe “claw” cluster is a loose family of self-hosted, open-source personal/coding-agent stacks with overlapping design goals (viz.: local-first, sandboxed, multi-channel, pluggable providers) but built in different languages with wildly different tradeoffs. If you want to test-drive several of these stacks side by side, Flox offers arguably the path of least resistance: You could even activate each environment and run them at the same time; you don’t need to worry about them stomping on one another’s runtimes or config.\n\nAI agent from [Nous Research](https://github.com/NousResearch) with a built-in learning loop. Hermes identifies routine work and turns it into reusable skills, improves them during use, nudges itself to persist knowledge, and searches conversation history for recall across sessions. Runs as a persistent gateway you can talk to from a TUI and/or messaging platforms like Discord, Slack, WhatsApp, Signal, and email.\n\nModel choice is wide open: Nous Portal, OpenRouter, NVIDIA NIM, Hugging Face, OpenAI, and other compatible endpoints, all switchable via **`hermes model`**. Hermes also supports scheduled automations, spinning up isolated subagents for concurrent work, and multiple backends, so it can run on anything from a cheap VPS to a cloud GPU cluster. Hermes *feels* like a close relative of the seminal OpenClaw agent, but with a focus on learning from past work, building reusable behaviors, and running as a persistent agent.\n\nRun it: `cd hermes-agent && flox activate`\n\nSpeaking of which….\n\nSelf-hosted AI assistant and agent platform. OpenClaw runs a persistent local gateway that multiple frontends can connect to: a built-in TUI, single-turn CLI agent mode, or external chat channels (Telegram, Discord, WhatsApp). Uses OpenRouter as its model provider, facilitating access to a large catalog of models (Claude, GPT, Gemini, Llama, etc.) via a single API key. Features agent workspaces with session persistence, **`cron`** scheduling, plugin/skill systems, a browser automation subsystem, and sandbox containers for agent isolation. Includes a **`doctor`** command for health checks and self-repair.\n\nThis Flox environment runs the gateway as a managed service (**`flox activate -s`**) that stops automatically when you exit. This means no orphaned daemons or persistent systemd units.\n\nRun it: `cd openclaw && flox activate -s`\n\nSecure personal AI assistant written in Rust by NEAR AI. Built around WASM-sandboxed tool execution with capability-based permissions, credential-leak detection, and HTTP allowlisting. Persistent memory runs on PostgreSQL + pgvector if you **`flox activate -s`**, enabling hybrid full-text and vector search (Reciprocal Rank Fusion); runs on an embedded libSQL database if you run without services (e.g., **`flox activate`**). Multi-provider (NEAR AI, Anthropic, OpenAI, Gemini, Copilot, Ollama, Mistral, OpenRouter, and more) and multi-channel (REPL, HTTP webhooks, Web Gateway, Telegram, Slack) via WASM channels. A routines engine handles cron schedules, event triggers, webhook handlers, and heartbeat loops; a dynamic-tools feature can build new WASM tools from natural-language descriptions. **Note**: This Flox environment auto-detects Postgres-mode vs libSQL-mode based on whether you run **`flox activate -s`**.\n\nRun it: `cd ironclaw && flox activate -s`\n\nThe repo also includes lighter or more specialized relatives, including **[nullclaw](https://github.com/nullclaw/nullclaw)**, **[claw-code](https://github.com/ultraworkers/claw-code)**, and **[claurst](https://github.com/Kuberwastaken/claurst)**. They’re still available if that particular tradeoff interests you; they’re just not where I’d start a tour of the agentic tools people are gravitating toward in late 2026.\n\n### Multi-agent orchestration & parallel workflows\n\nThe next cluster is all about running multiple agents at once: either coordinating specialized sub-agents inside a single task, or fanning out several independent agents across isolated workspaces so you can review their work as it lands.\n\nThink of Herdr as a [tmux](https://github.com/tmux/tmux)-like workspace manager that “understands” coding agents. It can track Claude Code, Codex, OpenCode, Pi, Hermes, and others in separate terminal panes, showing which are busy, which are waiting for interactive input, and which have finished. The panes survive terminal disconnects, and you can attach remotely over SSH. Run one agent, five agents, whatever you want; Herdr is about keeping track of what they’re all doing without juggling terminal windows.\n\nIts server runs independently of the Flox session, just as a tmux server does. That’s intentional: you detach and the agents keep working. Stop it explicitly with **`herdr server stop`** when you’re done.\n\nRun it: `cd herdr && flox activate`\n\nA git worktree manager designed for running coding agents side by side. One task gets one branch and one worktree, so two agents—or you and an agent—don’t work on the same files at the same time. **`wt switch -c`** creates the worktree; **` wt list`** shows what’s happening; **` wt merge`** gets the finished work back into the main checkout. Less exciting than a swarm of 100 autonomous agents, perhaps, but also less likely to micturate upon one another’s work. Worktrunk, then, really ties the room together.\n\nRun it: `cd worktrunk && flox activate`\n\n**[xum](https://github.com/coder/xum)** (née **mux**)\n\n**`xum`** lets you plan and run tasks using multiple agents at the same time, each getting its own **isolated workspace**: git worktree, Docker container, SSH remote, or local directory. Multi-provider (Anthropic, OpenAI, Google, xAI, DeepSeek, OpenRouter, Ollama, AWS Bedrock, GitHub Copilot) with a plan/exec loop and built-in orchestrator sub-agents (**`exec`**, **` explore`**, **` plan`**). Use the one-shot CLI (**` xum run \"Refactor the auth module\"`**), the browser UI (start the Flox service and hit **` localhost:3000`**), or the desktop app. Perfect for “fan out N tasks, review diffs as they land”-type workflows.\n\nRun it: `cd mux && flox activate -s`\n\nMulti-agent orchestration platform that sits on top of Claude Code. (Formerly known as Claude Flow.) Ruflo coordinates specialized role-based agents—coder, tester, reviewer, architect, security, etc.—and adds memory, routing, and MCP integrations. There’s a lot going on here, and some of the project’s marketing claims are difficult to independently verify. Ruflo installs **`ruflo@latest`** via npm on first activation of this Flox environment. That means the downloaded version isn’t pinned by Flox, so inspect what you’re installing before giving it access to a repo or credentials.\n\nRun it: `cd ruflo && flox activate`\n\n### Skills, browser automation & MCP\n\nThere’s another big change since OpenClaw first dropped: much of the interesting work has moved from choosing the agent to choosing what the agent knows and can safely do. Skills package up instructions, reference material, and repeatable workflows. MCP connects agents to tools and services. You’ll find both in the wild, often in the same setup. It turns out there’s no law requiring you to pick a side.\n\nFlox has made the same shift. Its old MCP server is retired; the maintained **[Flox skills](https://github.com/flox/flox-skills)** are **`flox`**, **` floxify`**, and **` flox-debug`**. They teach supported agents how to work with Flox rather than forcing every operation through a dedicated Flox MCP server. The **`floxify`** skill is particularly useful when you inherit a repo whose setup instructions nobody trusts: have an agent inspect the project and create a Flox environment for it. The agent does the detective work once; the environment is what you keep.\n\nBrowser automation aimed at agents rather than people. Instead of dumping a huge blob of HTML into the context window and hoping the model finds the right button, agent-browser gives it a compact accessibility snapshot with element references it can click, fill, inspect, or screenshot. It works as a CLI or MCP server. The Flox environment provides Chromium on Linux, so there’s no separate browser download there. Browser automation is especially useful once you want the agent to *test* the application it just wrote.\n\nRun it: `cd agent-browser && flox activate`\n\nLets an agent call MCP tools from the shell: list servers, inspect their schemas, invoke a tool, and get the result as text or JSON. Mcporter can reuse MCP server definitions already configured for Claude Code, Codex, Cursor, and other agents, or connect directly to a server. It can even turn a tool server into a standalone CLI. This is a useful counterexample to the notion that MCP has somehow gone away.\n\nRun it: `cd mcporter && flox activate`\n\n### Sandboxing & supply-chain security\n\nGiving an agent the tools it needs to install packages, run commands, and mutate files is useful. It also invites the question as to what agent can and can’t do. Sandboxing software gives you a way to confine agents to a restricted environment—a “jail,” so to speak—and control which files they can read or mutate; which (if any) network destinations they can reach; and what local resources they can access. If an agent gets confused, makes mistakes, or goes rogue, a sandbox helps contain the damage.\n\nKernel-enforced sandbox for AI agents. **`nono run --allow-cwd -- <command>`** runs an agent, an MCP server, or any command such that it writes only to the current directory. Credentials like **`~/.ssh`** stay unreadable. No root, container, or VM is involved; on Linux it uses [Landlock](https://github.com/landlock-lsm). You can cut off network access (**`--block-net`**) or allow only listed domains (e.g., **`--allow-domain api.anthropic.com`**). Snapshot a project with **`--rollback`** and restore it if/when an agent goes off the rails. Signed, ready-made profiles for Claude Code, Codex, pi, OpenCode, and others come from nono's registry. Every session lands in a tamper-evident audit log.\n\nnono's default profile can't see the [Nix store](https://flox.dev/glossary/#nix-store), so the Flox environment adds a **`nono-flox-profile`** helper. It extends any profile with access to **`/nix/store`** and to other active Flox environments, so Flox-installed agents and their wrappers run inside the nono sandbox. Layer it on top of an agent environment, then run, for example, **`nono run --allow-cwd --profile \"$(nono-flox-profile nolabs-ai/claude)\" -- claude`**. Like any sandbox, it’s a way to limit the blast radius vis-a-vis the damage an AI agent run amok can do.\n\nRun it: `cd nono && flox activate`\n\nAnthropic’s lightweight sandbox for coding agents and other commands. Runs a process—and the processes it starts—with filesystem and network restrictions using operating-system facilities, without requiring a container. On Linux it uses bubblewrap; on macOS, sandbox-exec. Give an agent enough access to work on the code in front of it, not the entire contents of your home directory. Flox manages the dependencies; the sandbox manages what the process can touch. Different jobs.\n\nRun it: `cd sandbox-runtime && flox activate`\n\nSix scanners and validators for agent skills and configurations, including NVIDIA’s **[SkillSpector](https://github.com/NVIDIA/SkillSpector)**. Scan a downloaded skill for suspicious instructions, dependency behavior, credential access, or scripts that fetch more scripts; check your own skills and agent settings before you commit them. Linters and scanners aren’t proof that code is benign, but they’re a much better idea than installing an anonymous skill and hoping for the best.\n\nRun it: `cd agent-lint && flox activate`\n\nSocket Firewall Free (sfw) checks packages against known-malware data as package managers fetch them. The Flox environment puts shims for npm, npx, yarn, pnpm, pip, uv, cargo, and a few aliases in **`$PATH`**, so agent-invoked commands (like **` npm install`**) also go through sfw. It's another layer of protection, not a substitute for vetting untrusted packages or limiting an agent's privileges.\n\nRun it: `cd sfw && flox activate`\n\n### Memory & context\n\nA tool can keep every conversation in a log and still have no idea which details from Tuesday matter most on Friday. Long-running agent work creates a different kind of problem: teams need a way to reuse useful knowledge across sessions without requiring models to reread the complete project history every time.\n\nPersistent memory for agents, backed by sessions, messages, and a background worker whose job it is to turn conversations into facts, preferences, and summaries. Honcho can answer questions about what an agent has learned about a project or person over time. The Flox environment runs its API, the background worker, and a local PostgreSQL + pgvector database as managed services.\n\nHoncho also integrates with Hermes Agent, which adds semantic search and persistent user modeling to Hermes's built-in memory. With PostgreSQL's **`pgvector`** extension, it uses vector embeddings to search memories by meaning rather than keywords, finding relevant information even when an agent's question uses different words than the original conversation.\n\nRun it: `cd honcho && flox activate -s`\n\nThe less elaborate alternative: store memories as ordinary Markdown files in a directory you own, with links and a local searchable index. Agents can read and write those notes over MCP. You can also open them in your editor, grep them, commit them, or decide a particular memory was a bad idea and delete it. And the knowledge isn’t trapped inside somebody else’s opaque state store.\n\nRun it: `cd basic-memory && flox activate`\n\nGives coding agents semantic code navigation backed by language servers: find a symbol, follow references, inspect implementations, or replace a function instead of guessing where it lives from a text search. Serena also stores project memories.\n\nRun it: `cd serena && flox activate`\n\n### Keeping tabs on token spend\n\nIt’s now trivially easy to run several agents at once. It’s also no less easy to outfit agents with browsers, tools, and memories. And, by the same token, it’s easy to get an *extremely* unpleasant surprise when the bill for all of this agentic work comes due. Finops for AI is impossible to ignore in this era of agentic engineering.\n\nReads the logs agents already write to disk and reports token counts and estimated costs by day, session, or billing window. It supports Claude Code, Codex, OpenCode, Pi, and others, with a status-line integration for Claude Code. No extra service or telemetry collector needed.\n\nRun it: `cd ccusage && flox activate`\n\nA richer dashboard for tracking agent spend across models, projects, and tasks. CodeBurn reads local session logs, with TUI, web, and machine-readable reports. Useful for finding the agents or workflows that consume the most tokens, or for comparing a local-model experiment against a paid API workflow.\n\nRun it: `cd codeburn && flox activate`\n\n### Agentic IDEs\n\nBoth of these are full desktop IDEs rather than TUIs, and both orchestrate multiple agents—but their philosophies are very different. Antigravity is Google’s agent-first VS Code fork built around a Mission Control dashboard; Kiro is a spec-first IDE that formalizes planning, constraints, and automation via first-class workflow primitives.\n\nGoogle’s agent-first IDE: a deep fork of VS Code that integrates Gemini (and Claude) for autonomous multi-agent coding. Three surfaces: a familiar **Editor** with inline AI commands (**`Cmd/Ctrl+I`**) and tab completions; a **Manager** (“Mission Control”) view for spawning and monitoring parallel autonomous agents across workspaces; and an integrated **Browser** for agent-driven web testing. Multi-model: Gemini and Claude models (with the specific lineup changing as Google updates the service). Agents produce artifacts—code diffs, screenshots, browser recordings, implementation plans—that you review asynchronously. Per-project **`agents.md`** and **` skills.md`** files provide persistent instructions and reusable skills (à la **`CLAUDE.md`**). Sign in with a supported Google account; model access and quotas depend on your plan.\n\nRun it: `cd antigravity && flox activate`\n\nKiro is a spec-first desktop IDE (also VS Code-based) that embeds a coding agent. Instead of a chat-driven UX, Kiro incorporates first-class workflow primitives—**specs**, **steering files**, and **hooks**—to formalize how work gets planned, constrained, and automated. It turns prompts into specs, extracting requirements and producing an implementation plan; markdown steering files apply persistent guidance across tasks; hooks fire on file events to automate quality gates. Kiro codebase-indexes your workspace by scanning + tracking code, configs, docs, and dependencies. The IDE runs locally, but AWS operates the backend and powers inference via Amazon Bedrock. Kiro also has a CLI for agentic workflows outside the editor.\n\nRun it: `cd kiro && flox activate`\n\n### Local inference for agents\n\nOllama paired with a curated set of CLI coding agents, pre-wired for **`ollama launch`**. Pull a tool-use-capable model (**` ollama pull gemma4`**, **` qwen3`**, **` devstral`**, **` llama4`**, …), start the service with **` flox activate -s`**, and launch any bundled agent against it in one command: **`ollama launch claude --model gemma4`**, **` ollama launch codex --model gemma4`**, **` ollama launch opencode --model gemma4`**, **` ollama launch openclaw --model gemma4`** (if you enable the optional OpenClaw package in this environment). Includes Flox skills for supported agents. GPU accelerated on supported platforms (Nvidia CUDA, Apple Metal/MPS), with CPU fallback; edit the manifest to swap **`ollama-cuda`** for **` ollama-rocm`** on AMD. The one-command path from “downloaded a model” to “running a coding agent against it locally.”\n\nRun it: `cd agentic-ollama && flox activate -s`\n\nHeadless-by-default local inference server with a desktop GUI when you want one. Runs llama.cpp everywhere and MLX on Apple Silicon. Exposes both an **OpenAI-compatible** API (**`/v1/chat/completions`**) and an **Anthropic-compatible** API (**`/v1/messages`**) on **` localhost:1234`**—drop-in for either SDK. Supports tool calling, JSON-schema structured output, MCP servers, and configurable parallel inference slots (default 4). The headless daemon starts automatically via **`flox activate -s`**; opt into the GUI with **` LMS_GUI=true`**. Designed to be composed into other Flox environments: when you want a local backend that speaks Anthropic’s protocol, not just OpenAI’s, this is the one.\n\nRun it: `cd lmstudio && flox activate -s`\n\nThe next four are production-grade inference engines. They’re almost certainly overkill for a single developer vibe-coding against a local model—Ollama or LM Studio will serve you better day-to-day—but they’re cool to have on hand when you need serious throughput, multi-GPU deployments, or want to experiment with the runtimes that actually power production LLM serving. **All four are `x86_64-linux` only and require an NVIDIA GPU with a recent NVIDIA® CUDA® driver.**\n\nProduction inference and serving engine, optimized for high throughput and low latency via PagedAttention KV-cache management and continuous batching. This Flox environment installs **`flox-cuda/python3Packages.vllm`** from the catalog along with **` flox/vllm-flox-runtime`** (model provisioning + serving scripts). Exposes an OpenAI-compatible API on **`localhost:8000`**. Override the model at activation with **` VLLM_MODEL`** and **` VLLM_MODEL_ORG`** env vars. Supports streaming, prefix caching, Multi-LoRA, distributed inference (tensor/pipeline/data/expert parallelism), and INT4/INT8/FP8 quantization. Handles MoE, embeddings, and multimodal models from Hugging Face.\n\nRun it: `cd vllm && flox activate -s`\n\n**`llama-server`** wrapped as a production Flox environment. Where vLLM serves full HuggingFace model directories, llama.cpp serves **GGUF files**—single files or split shard sets—so quantized models run out of the box with no torch dependency and the entire runtime is a single compiled binary. Uses **`flox-cuda/llama-cpp`** (CUDA 12.9, driver 575+). Defaults to **` microsoft/Phi-4-mini-instruct-GGUF`** (Q8_0, ~3.9 GB) on **` localhost:8080`** with GPU offload and continuous batching. Override the model at activation with **`LLAMACPP_MODEL`**, **` LLAMACPP_MODEL_ORG`**, **` LLAMACPP_MODEL_ID`**, and **` LLAMACPP_MODEL_FILE`**. OpenAI-compatible API.\n\nRun it: `cd llamacpp && flox activate -s`\n\nHigh-performance serving framework focused on structured generation, constrained decoding, and complex multi-call LLM programs. CUDA 12.8 (driver 550+), AVX2 required. The default manifest targets an **all-SM** build covering T4, A10, A100, L40, H100, B200, and RTX 3090/4090/5090 (SM75–SM120); swap in a GPU-family-specific package (e.g., **`flox/sglang-python312-cuda12_8-sm89-avx2`** for Ada Lovelace) if you want a tighter build. Defaults to **Phi-4-mini-instruct-FP8-TORCHAO** on **`localhost:30000`**; override with **` SGLANG_MODEL`** at activation. Supports tensor parallelism across multiple GPUs (**`SGLANG_TP_SIZE=4`**) for 70B-class models and attention-backend tuning for older GPUs (**`SGLANG_ATTENTION_BACKEND=triton`**).\n\nRun it: `cd sglang && flox activate -s`\n\nNVIDIA’s Triton Inference Server (now part of **Dynamo-Triton**), built from source via Nix and shipped with four backends: **Python**, **ONNX Runtime**, **vLLM**, and **TensorRT**. Triton serves model *repositories*—directories containing versioned subdirectories with backend-specific artifacts and optional **`config.pbtxt`** files—and exposes HTTP, gRPC, and Prometheus metrics simultaneously on separate ports. This runtime handles the operational lifecycle: port reclaim, model provisioning, environment validation, and process management. Defaults to **Phi-3.5-mini-instruct-AWQ** via the vLLM backend with zero network access (the model is installed as a Flox package, ~2.2 GB). Opt into an OpenAI-compatible frontend on port 9000 with **`TRITON_OPENAI_FRONTEND=true`**. This is the one you reach for when you need to serve many models concurrently across mixed backends with production-grade observability.\n\nRun it: `cd nvidia-triton && flox activate -s`\n\n### Spec tools\n\nOpenSpec and GitHub’s spec-kit both push the same idea: make AI-assisted coding more predictable by turning requirements into versioned, reviewable artifacts you can diff, test against, and hold the implementation accountable to. Align on intent *before* any code is generated; keep an auditable trail from spec → tasks → changes.\n\nA spec workflow you add to your existing repos so you + your AI coding assistant can align on intended behavior. Run **`openspec init`** to create an **` openspec/`** sub-folder structure: **` openspec/specs/`** stores the current source-of-truth specs; **` openspec/changes/`** the per-feature change folders that bundle a proposal. This path also stores a task checklist and spec deltas (i.e., the “patch” to the specs). Some assistants surface OpenSpec’s steps as **`/openspec <verb>`** slash commands after running **` openspec init`**, because OpenSpec writes the **` instruction/config`** files they read at startup. But these commands are mere shortcuts: the “real” workflow lives in the repo as an **`openspec/`** folder. With tools that don’t support custom slash commands, you run the same spec-first loop by posing requests in plain language and having the assistant create/review/apply/archive OpenSpec files.\n\nRun it: `cd openspec && flox activate`\n\n**[spec-kit](https://github.com/github/spec-kit)** (GitHub Spec Kit)\n\nGitHub’s open-source toolkit for “spec-driven development.” Pushes you to define requirements + outcomes first, then turns your spec into: plan → task list → code. Run the **`specify`** CLI (**` specify init`**, **` specify check`**) to scaffold or retrofit projects. Spec Kit drops a small set of files into your repo and configures your preferred agent so that when you type **`/speckit.<command>`**, the agent runs Spec Kit’s scripts and uses the generated artifacts. Supports a broad range of tools out of the box: Claude Code, OpenAI Codex CLI, Gemini CLI, Cursor, Copilot, Kilo Code, OpenCode, and Qwen Code.\n\nRun it: `cd spec-kit && flox activate`\n\n**[GSD Core (Get Shit Done)](https://github.com/open-gsd/gsd-core)** is another active take on the problem. Its emphasis is less on writing the spec than on getting an agent through a long project without losing the plot: break the work into phases, give it fresh context, save the decisions and progress, and verify what comes back. The original GSD repo is archived, but development continues in Open GSD. **This one isn’t a turnkey environment in the Flox repo yet**; it belongs here as a point of comparison, not as a package I’m pretending you can activate.\n\n## >227,000 Other Packages, Millions of Historical Versions\n\nThe Flox Catalog contains just about every dependency you (or your AI agent minions) will need to build, test, and ship software. The Flox environments collected in this repo offer ready-to-run implementations showcasing *some* of these packages; however, what you see here isn’t close to exhausting the possibilities of what’s available. Here’s a sampling of the MCP packages available in the Flox Catalog:\n\n- **[github-mcp-server](https://hub.flox.dev/packages/base/github-mcp-server)** . Exposes GitHub repo/issue/PR operations via the GitHub API.\n- **[gitea-mcp-server](https://hub.flox.dev/packages/base/gitea-mcp-server)** . Exposes Gitea repo/issue/PR operations via the Gitea API.\n- **[terraform-mcp-server](https://hub.flox.dev/packages/base/terraform-mcp-server)** . Lets agent inspect/plan/apply Terraform workflows.\n- **[mcp-k8s-go](https://hub.flox.dev/packages/base/mcp-k8s-go)** . Go-based MCP tool server that exposes Kubernetes cluster operations (via**`kubectl`** -style reads/actions) as callable tools.\n- **[aks-mcp-server](https://hub.flox.dev/packages/base/aks-mcp-server)** . MCP server for Microsoft’s Azure Kubernetes Service (AKS); supports cluster/resource management + other operations; surfaced as MCP tools.\n- **[playwright-mcp](https://hub.flox.dev/packages/base/playwright-mcp)** . Exposes Playwright browser automations (navigate/click/extract/screenshot) as MCP tools.\n- **[mcp-grafana](https://hub.flox.dev/packages/base/mcp-grafana)** . Exposes Grafana entities (dashboards/panels/alerts/queries) as tools.\n- **[mcp-proxy](https://hub.flox.dev/packages/base/mcp-proxy)** . Forwards/bridges MCP connections so clients can reach tool servers through a single hop.\n- **[pythonXXXPackages.mcp](https://hub.flox.dev/packages/search?q=python313Packages.mcp)** (where**`XXX`** is the version). Python MCP library/SDK used to build MCP clients/servers and define tool schemas in Python. Packages available for Python versions 3.10-3.13.\n- **[toolhive](https://hub.flox.dev/packages/base/toolhive)** . Installs/runs/manages MCP servers as “tool bundles” so agents can consume them.\n\n[Search all 227,000+ packages on FloxHub](https://hub.flox.dev/packages/search)\n\n## But Wait: There's More\n\nHow about another serving of turn-key environments to build with as you ramp up your vibecoding vacation? If you or your AI agent minion need a database, scheduler, workflow management engine, httpd/reverse proxy, or other tools, services, or runtimes, check out the following repos:\n\n- **[flox/floxenvs](https://github.com/flox/floxenvs/)** . A collection of ready-to-run Flox environment examples (via flake.nix) for language toolchains like Go, Python (pip/poetry/uv), JavaScript (node/bun/deno), Ruby, and Rust, plus local service stacks like Postgres, Redis, MySQL, MongoDB, Cassandra, and Elasticsearch. This repo also includes environment templates for tools/apps such as nginx, mkcert, direnv/dotenv, 1Password, Dagger, Podman/Colima, LocalStack, JupyterLab, and Ollama.\n- **[floxrox/floxenvs](https://github.com/floxrox/floxenvs)** . Another collection of ready-to-run Flox environments, including: Airflow, AWS CLI, Colima, ComfyUI, Dagster, GitHub CLI, Jenkins, JupyterLab, Kafka (plus Karapace, a schema registry), kind, MariaDB/MySQL, n8n, Neo4j, nginx, Node-RED, Ollama (plus Open WebUI), Postgres (including a Metabase combo), Prefect, Redis, Spark, Temporal (plus a temporal-ui env), and multiple Python dev environments (3.10–3.13).\n\nYou and your AI assistants can combine these environments in two complementary ways:\n\n- **Composition** . Compose multiple modular environments into a single, declarative “stack” that resolves and locks everything up front. Composition is great when you need reproducible, shareable setups;\n- **Layering** . Layer environments one on top of another at runtime. Useful for adding tools/services when you need them in the moment: e.g., layering Python debugging tools on top of core Python dev tools.\n\nIn practice [you’ll often use both](https://flox.dev/blog/layering-and-composing-flox-environments/): using composition to create rich “stack” environments; layering extras on top when you need them.\n\nWhat else? How about Flox-and-AI guides to get you started?\n\nYour first agent is three commands away.\n\nInstall Flox, sign in to FloxHub, then:\n\n## Keep learning with Flox\n\nInterviews, tips, guides, industry best practices, and news.\n\n[View all posts](https://flox.dev/blog/)\n\n### Focusing on the Code, Not the CruftPutting the flox and floxify agent skills through their paces with Claude Code: building a FastAPI embedding service from scratch, then reconstructing a complete six-service Mastodon development environment from an existing checkout. Read post\n### Making Flox Better for People and MachinesFlox v1.14.1 improves activation, search, and usability as more developers, CI systems, and AI agents rely on Flox. Read post\n### Flox Account Tokens for People and MachinesFlox now supports granular, role-based tokens that enable organizations to reduce their blast radius, keep pipelines running smoothly through staff changes, easily rotate credentials on a schedule, and seamlessly authenticate in browserless workflows. Read post\n### One Tool, Every Language: Declarative Dev EnvironmentsImagine creating declarative, reproducible environments for the toolchains and dependencies you use in your workflows. Declaring compilers, debuggers, dev libraries, and other dependencies as code. Declarative patterns make this convenient, reproducible, and scalable. Read post\n### AI Stack as Code: Define It Once, Run It EverywhereLearn how AI stacks as code make ML and AI environments reproducible across macOS, Linux, Windows, CUDA, and Apple Silicon with reusable reference patterns. Read post\n### Platform Teams and the Challenge of Works-on-My-MachineA practical guide to creating and working with Flox standardized local development environments, including playbooks for defining, reproducing, and managing project environments at scale. Read post", "url": "https://wpnews.pro/news/a-turnkey-toolkit-for-agentic-development-with-flox", "canonical_source": "https://flox.dev/blog/a-turnkey-toolkit-for-agentic-development-with-flox", "published_at": "2026-11-03 23:21:37.023577+00:00", "updated_at": "2026-11-03 23:21:39.365083+00:00", "lang": "en", "topics": ["ai-agents", "ai-tools", "developer-tools", "ai-infrastructure"], "entities": ["Flox", "FloxHub", "Claude Code", "Codex", "OpenCode", "Hermes Agent", "Pi", "OpenClaw"], "also_reported_by": [], "alternates": {"html": "https://wpnews.pro/news/a-turnkey-toolkit-for-agentic-development-with-flox", "markdown": "https://wpnews.pro/news/a-turnkey-toolkit-for-agentic-development-with-flox.md", "text": "https://wpnews.pro/news/a-turnkey-toolkit-for-agentic-development-with-flox.txt", "jsonld": "https://wpnews.pro/news/a-turnkey-toolkit-for-agentic-development-with-flox.jsonld"}}