OpenSeek - Open-Source Coding Agent With 28 Providers

TL;DR

TL;DR: OpenSeek is a Bun-based terminal coding agent for people who want open-source control, broad provider choice, MCP support, and a clear autonomy ladder from planning mode to YOLO execution.

Source and Accuracy Notes

This post is based on the official OpenSeek repository, its published project documentation, and the linked website. The project currently documents Bun as a hard runtime requirement and positions OpenSeek as open source across macOS, Linux, and WSL2.

What Is OpenSeek?

OpenSeek is trying to answer a very direct question: what if you want a Codex- or Claude-Code-like terminal agent experience without locking yourself to one provider or one closed implementation?

Its answer is a TUI coding agent with:

• 28 built-in providers
• 50+ tools and 100+ slash commands
• MCP client support
• LSP diagnostics during edits
• Plan, Agent, and YOLO execution modes
• an HTTP/SSE runtime via openseek serve --http

That feature mix makes OpenSeek less like a simple chat shell and more like a local agent runtime for people who care about control surfaces.

Why OpenSeek Is Interesting

The strongest idea here is not provider count by itself. It is the combination of provider flexibility with execution governance.

OpenSeek explicitly separates three modes:

• Plan for read-only planning
• Agent for confirmed execution
• YOLO for full autonomy

That is a healthier model than pretending autonomy is one slider. It gives teams a clearer escalation path from “show me what you would do” to “go do it.” Pair that with MCP integration and LSP feedback, and OpenSeek starts to look useful beyond hobby demos.

That same execution ladder is becoming recurring theme in better agent tooling. Repos such as ask-human-mcp and MCP Workbench are popular for similar reason: users want more control around powerful runtimes, not less.

Prerequisites

• macOS or Linux, or Windows via WSL2
• Bun >= 1.3.0
• one provider API key or a local model backend such as Ollama
• comfort with TUI-based workflows

The documentation is explicit that Bun is required at runtime and that Node alone cannot run OpenSeek because the project uses Bun.spawn, Bun.serve, and Bun.file.

Repo-Specific Setup Workflow

Step 1: Install Bun first

OpenSeek documents Bun installation like this:

curl -fsSL https://bun.sh/install | bash

# or on macOS with Homebrew
brew install oven-sh/bun/bun

The install guide expects bun --version to print at least 1.3.0.

Step 2: Install OpenSeek

The project supports three documented install paths:

# npm
npm install -g openseek

# bun
bun add -g openseek

# from source
git clone https://github.com/LichAmnesia/openseek.git
cd openseek
bun install
bun run build
ln -sf "$PWD/bin/openseek" ~/.local/bin/openseek

The source path is the best fit if you plan to inspect or modify the agent itself.

Step 3: Run setup and diagnostics

The first-run commands are concise and practical:

openseek
openseek setup
openseek doctor
openseek serve --http

That gives you the interactive TUI, the provider setup wizard, resolved config diagnostics, and the headless runtime API on port 7117.

Step 4: Pick provider model strategy

OpenSeek’s published docs put major emphasis on multi-provider support. They document OpenAI-compatible, Anthropic-protocol, Google, and local backends, including Ollama and custom endpoints.

The repo shows environment-based setup patterns such as:

OPENSEEK_PROVIDER=relayrouter-anthropic \
OPENSEEK_API_KEY=sk-... \
OPENSEEK_MODEL=claude-sonnet-4-6 \
openseek

and:

OPENSEEK_PROVIDER=relayrouter \
OPENSEEK_API_KEY=sk-... \
OPENSEEK_MODEL=gpt-5.4 \
openseek

Even if you do not use RelayRouter, these examples reveal the design: provider, API key, model, and base URL are first-class config knobs rather than hidden assumptions.

Step 5: Understand config layering

OpenSeek resolves settings from multiple layers. The documentation explicitly lists environment variables at the top, including:

• OPENSEEK_PROVIDER
• OPENSEEK_MODEL
• OPENSEEK_API_KEY
• OPENSEEK_BASE_URL

It also mentions provider-specific keys such as DEEPSEEK_API_KEY and ANTHROPIC_API_KEY, plus a project overlay at /.openseek/config.toml.

That tells you the tool is designed for both personal defaults and project-scoped overrides.

Deeper Analysis

Bun as hard dependency

Some repos mention Bun as a preference. OpenSeek documents it as non-optional. That is both strength and risk.

Strength because it simplifies runtime assumptions and likely helps performance.

Risk because it raises adoption friction for teams standardized on Node-only environments. If your shell boxes, CI, or remote hosts are not ready for Bun, you will feel it immediately.

Why MCP and LSP together matter

OpenSeek includes two features that are often split across tools:

• MCP for external tools and skills
• LSP feedback for inline diagnostics during edits

That combination matters because agent quality is usually bottlenecked by environment context, not pure model intelligence. MCP broadens what the agent can reach. LSP narrows how long it can stay wrong.

Cost transparency is part of product design

The documentation calls out a transparent cost meter with real-time spend tracking and cache-hit accounting. That is not cosmetic. In multi-provider agent setups, cost surprises become architecture problems. Surfacing spend per model is part of making experimentation sustainable.

Open-source agent projects often underestimate this. They benchmark output quality, but not operator economics. If you are choosing between different terminal-agent stacks, compare not only edit quality and tool support, but also whether a project helps you understand which model, provider, and mode are burning money. That is one place where OpenSeek feels more mature than many fast-rising alternatives.

OpenSeek also benefits from being auditable in way many closed terminal agents are not. When model routing, command execution modes, and config precedence live in public repo, teams can reason about adoption risk with more confidence. That matters most for builders who intend to wire agent into daily engineering workflow rather than use it as side experiment.

That openness also helps during failure analysis. If a provider fallback behaves strangely, a command mode misfires, or an MCP integration needs review, engineers can inspect implementation details rather than reverse-engineering product behavior from black-box output. For serious users, that alone can outweigh feature gaps versus more polished hosted alternatives.

Readers comparing multiple local-first agent options may also want to contrast this post with WeSight, because WeSight attacks management layer while OpenSeek attacks terminal runtime layer.

Practical Evaluation Checklist

• [ ] You want an open-source alternative to closed terminal coding agents
• [ ] Bun is acceptable in your runtime environment
• [ ] Multi-provider BYOK flexibility matters more than one-vendor simplicity
• [ ] MCP support is part of your agent workflow
• [ ] You want a plan-to-autonomy ladder instead of one undifferentiated run mode
• [ ] Real-time cost visibility would change how you evaluate models

Security Notes

OpenSeek can run shell commands, edit files, connect to remote providers, and invoke MCP servers. That makes its execution mode choices security-relevant.

• Start in Plan mode when evaluating new repos or prompts.
• Treat YOLO mode as privileged execution, not convenience.
• Keep provider keys in environment or config layers you control and rotate them if shells or logs are shared.
• Review any MCP servers you connect, since external tools expand attack surface fast.

If you use OpenSeek with broad tool access, pair technical controls with human checkpoints.

FAQ

Q: Can OpenSeek run on Node without Bun? A: No. The project explicitly documents Bun as required at runtime, and Node alone cannot run the project.

Q: Does OpenSeek support local models? A: Yes. The documented provider list includes Ollama and custom local or OpenAI-compatible endpoints.

Q: What is openseek serve --http for? A: The repo describes it as a headless HTTP/SSE runtime for IDE bridges and CI-style integrations.

Q: Why do the Plan, Agent, and YOLO modes matter? A: They create a clearer safety ladder: inspect first, confirm next, then allow full autonomy only when the task and environment justify it.

Conclusion

OpenSeek is one of the more coherent open-source coding-agent repos trending right now because it does not rely on one gimmick. Provider breadth, MCP support, LSP diagnostics, cost visibility, and execution modes fit together into one real operator workflow.

If you want an open terminal agent and you are comfortable adopting Bun, OpenSeek is worth testing. Start with Plan mode, wire in one provider, and decide whether its control surface feels better than your current CLI stack.