Linchpin

What is Linchpin?

Linchpin is a self-hostable runtime for AI agents that supports running with many different model providers and local models. It is designed to let you route requests to different LLMs, run each agent session in an isolated environment, and provide a controlled set of built-in and external tools.

Its core purpose is to reduce model/provider lock-in while giving agents a sandboxed execution context and managed access to tools, credentials, and event streams.

Key Features

• Any model, one adapter: Linchpin can route to roughly 200 cloud models (including Claude, GPT, Gemini, Llama, DeepSeek, Mistral, and Qwen) via OpenRouter, and it can use Ollama to run models you pull locally; you can switch providers per agent.
• Sandboxed sessions with per-session Docker containers: Each session runs in its own Docker container with Python, Node, git, and ripgrep preinstalled to provide a consistent tool environment.
• Configurable networking per environment: Networking can be set to none for tight restrictions or open egress for less restrictive setups.
• Eight built-in container tools: Agents can use tools including bash, read, write, edit, glob, grep, web_fetch, and web_search, with execution constrained inside the container.
• MCP and HTTP tool integration: Linchpin can plug in Model Context Protocol (MCP) servers via stdio, or connect to any HTTP endpoint; the connector manages process lifecycle and credential injection.
• Encrypted credential vaults: Credentials are stored using Fernet encryption; agents reference secrets by name in their configs, and secrets are decrypted at session start without being written to disk in plaintext.
• Append-only event streaming per session: Linchpin records an append-only event log per session and supports cursor pagination; clients can subscribe over SSE to replay events past a cursor and then stream live updates.

How to Use Linchpin

1. Choose your model path: Configure an agent to use a cloud model through OpenRouter (for provider selection) and/or a local model via Ollama.
2. Run agent sessions in the sandbox: Start sessions knowing each one uses its own Docker container with the preinstalled runtime tools; set networking to match your environment needs (none vs open egress).
3. Select tools for the agent: Use Linchpin’s built-in tools (bash, file operations, search/fetch) and optionally add MCP servers (via stdio) or connect to HTTP endpoints as external tools.
4. Provide credentials securely: Store credentials in Linchpin’s Fernet-encrypted vault and reference secrets by name in agent configs.
5. Stream events to your UI or service: Subscribe over SSE and use cursor pagination to replay prior events and continue receiving updates.

Use Cases

• Multi-provider agent deployment: You want to run the same agent workflow against different LLMs (for example, using Claude for one task and GPT for another) while keeping the rest of your tool and sandbox setup consistent.
• Local-model agent runs: You have models pulled locally and prefer running via Ollama, using the same containerized tools and session isolation regardless of where the model runs.
• Sandboxed code and file workflows: An agent that needs to edit and search project files or run shell commands can do so inside its own Docker container, with restricted networking when required.
• Tooling via MCP servers: You have existing MCP servers that expose capabilities to agents; Linchpin can connect to them over stdio and manage connector lifecycle and credential injection.
• Live UI event feeds: You are building an interface that needs both history and live updates; you can replay event log entries from a cursor and then continue streaming events in real time via SSE.

FAQ

• Does Linchpin require a specific model provider? No. Linchpin routes through OpenRouter to many cloud models and can also run local models via Ollama, with provider selection configurable per agent.

• How are agent sessions isolated? Each session runs in its own Docker container with tools such as Python and Node preinstalled. Networking can be restricted (none) or allowed (open egress) depending on the environment.

• What tools can agents use? Linchpin includes eight built-in tools (bash, read, write, edit, glob, grep, web_fetch, web_search) and can integrate external tools via MCP servers (stdio) or HTTP endpoints.

• How does Linchpin handle credentials? Credentials are stored in a Fernet-encrypted vault and referenced by name in agent configs. They are decrypted at session start and are not written to disk in plaintext.

• Can I stream agent activity to a frontend? Yes. Linchpin maintains an append-only event log per session and supports SSE subscriptions that replay events past a cursor and then stream new events live.

Alternatives

• Self-hosted agent runtimes with sandboxing: Alternative platforms that run agents in isolated containers can also provide controlled tool execution; the difference is often in how they integrate models and tools (provider routing, MCP/HTTP support, and event streaming model).
• Local-only agent frameworks: Frameworks that focus on local models (e.g., those built around local inference) can avoid external provider routing, but may offer different levels of provider switching and managed tool/credential handling.
• MCP-focused tool connectors: If your main need is MCP connectivity, you may find alternatives that emphasize MCP tool integration; compared with Linchpin, you would need to evaluate how they handle session isolation, credential storage, and streaming.
• Custom SSE/event-log implementations: Some teams build their own event logging and SSE streaming around an agent system; the tradeoff is more engineering effort to reproduce cursor-based replay, append-only session logs, and consistent agent tooling behavior.