01
Anthropic
Run /connect and choose Anthropic, paste your API key, then /model to pick a model.
Ecosystem
Your models, your tools, your distribution
Keys on your own accounts, tools from the official market, artifacts delivered through your own pipeline — every layer of the ecosystem runs on your infrastructure.
Three provider channels
MagicFrog has exactly three model channels, and every one is bring-your-own-key: Anthropic, OpenAI, and custom OpenAI-compatible endpoints. There is no vendor catalog to browse and no subscription login path.
Three channels, three ways to bring a model in — all bring-your-own-key:
BYOK is clearest in deployment: your server holds the key, the provider sees your server IP — no layer of ours in between.
Self-hosted inference servers ride the built-in preset discovery: a local OpenAI-compatible endpoint is recognized automatically, with no glue code. Rotating a key is one config update — the workbench does not restart.
Fewer channels, smaller credential surface: three channels, three keys you hold yourself.
Keys flow only between your server and the provider endpoint — no relay.
02
OpenAI
Run /connect and choose OpenAI, paste your API key; the official endpoint accepts both chat completions and Responses shapes.
03
Custom OpenAI-compatible endpoint
Most providers expose an OpenAI-compatible API: store the key, then declare the provider in magicfrog.json.
All three channels share one discipline: keys live only in your server-side database — never in client artifacts, never in config repositories. Switching models is a config change, not a vendor change.
Providers doc →The official MCP registry
In-product: the official registry plus your custom sources.
The market is more than a browse page — it carries an explicit install-queue protocol:
The market is a three-family catalog — MCP servers, plugins, and skills — with the desktop client and the web site consuming the same data layer. The official registry is permanent and irremovable; you can also declare your own catalog endpoint speaking the same registry API shape and fold internal tools into the same list.
Browse without an account; tokens live in page memory only and vanish with the tab.
- Browse the web site without an account: search, category filters, picks, and recent updates
- Installs from the web: sign in, queue with one click, the desktop client claims and executes through an explicit state machine
- Install payloads carry catalog identity only, never prebuilt config — the desktop verifies against your real environment
- Credentials live in page memory only: no browser storage, and refresh tokens never reach the web side
The install queue flows explicitly: pending → claimed → executed, terminal states immutable, failures always carry a reason. Retries never double-install, and unknown outcomes are never reported as success.
The web site and the desktop client consume the same data layer, so "what exists" and "what is installed" never diverge between the two.
Custom sources speak the same registry API shape, so an internal tool catalog folds in seamlessly: one configuration, visible on both web and desktop. Install queues are per-account, not per-machine — switching computers keeps your queue.
Queues are per-account; switching machines keeps your tasks.
Payloads carry catalog identity; the desktop builds real config for your environment.
market install queue
POST /v1/market/queue → pending desktop claims → claimed idempotent journal check → executed ↘ cancelled | failed (reason)
Memory in five dimensions
One Markdown memory tree, five dimensions; the most specific dimension wins on the same path.
Memory is how an agent keeps its judgment across sessions; MagicFrog makes it an editable tree:
Each session renders one memory block, most-specific first; updates replace the whole block and say so.
| Dimension | Scope | Roams with account |
|---|---|---|
account | Shared across the whole account | Yes |
user | One user's preferences and context | Yes |
agent | One named agent, isolated by agent ID | Yes |
task | One task (project), isolated by task ID | Yes |
device | One computer only, never merged across machines | No |
The five dimensions form a coverage chain from broadest to most specific: account < user < agent < task; device stands outside the chain as its own row.
Memory entries carry frontmatter: revision and update time live in the file header, git-friendly. Notes under the skills layer are skill sources — a memory note that says "how we work" becomes a loadable skill.
Where a note path exists in several dimensions, the most specific wins.
Roaming dimensions carry conflict-safe revisions; device memory never leaves its machine.
Memory is plain Markdown on disk — a text editor is a memory client. Writes carry a revision; stale writes fail explicitly instead of silently overwriting. The cloud profile surface roams; device memory never leaves that machine.
Memory doc →Distribution surface
The distribution surface answers three factual questions:
Inside your network, the bucket can run through your own mirror — digests unchanged, verification intact.
01
Client and server artifacts ship from the dedicated magicfrog-downloads bucket with direct downloads — no proxy in between.
02
Downloads are verified by SHA-256 digest plus byte size.
03
Container images live at ghcr.io/gsc-org/magicfrog; image publishing will be announced separately.
Verification uses a SHA-256 digest plus byte size; both must match before a download counts as complete.
Client and server share one version-metadata surface: latest.json for the CLI, latest-desktop.json for the desktop app. Read the metadata first, then pick your artifact coordinate.
Unsigned artifacts are legitimate; verify by digest and byte size.
Container image coordinates will be announced separately; bucket artifacts rule today.
Three facts answer one question about distribution: where your installers come from, how they are verified, and whose hands they pass through — the answer is your own infrastructure.
Self-hosting guide →Start with one command
The ecosystem is not platform lock-in — it hands choice back to you: models, tools, and distribution can each be swapped, verified, and self-managed.
Self-host for freeRead the docsThe combined effect of the three faces: swap model providers without touching tools, swap the tool catalog without touching distribution, swap distribution without touching models — every layer is independently replaceable.
Next step: bring one key of yours and make the first model call — see the full chain working in ten minutes.