The AI workspace your agent can actually operate.
Notebooks, datasets, models and agents on your own machine. Every capability is a typed tool that runs headless, so an agent drives the workspace instead of sitting in a chat panel beside it. Policy decides what it may do, and every run ends in a signed evidence package.
Runs on your machine. macOS and Linux. Free for personal use; sign in once and it works offline.
From the client you already use
Your agent already knows how to use it.
IVYX serves its capabilities to any MCP client. Point Claude Code, Claude Desktop or Cursor's agent at it and your datasets, models, database and tools become things it can call as typed tools, not a user interface it has to drive. Every call passes the same policy rule and lands on the same signed record as the work you do yourself.
The agent does not just write the code. It runs the work, and the record covers all of it.
claude-code → ivyx connected · mcp tools/list datasets.download mlops.pipeline.run mlops.gate.evaluate mlops.model.promote approval: step tools/call mlops.model.promote → production allowed: false reason: Denied by policy rule churn-project#0.
The same rule, the same record. This call arrived from an outside client; the run below shows it from inside the app.
Three capabilities do this work, and they are in the catalog like everything else. capability.search searches the installed capabilities by keyword and returns the matches with a one-line summary each. capability.describe returns one capability in full: what it does, the exact arguments it takes, what it returns, and whether calling it needs approval. capability.serveCall runs one capability for a remote caller through the full policy, approval and audit pipeline.
Studio, or a terminal
Reachable with IVYX Studio open, or from a terminal with ivyx serve --stdio, which runs the same gateway with no window.
What the record covers
Your policy is what decides which capabilities an outside client can reach, and the record covers every call that passed through IVYX, not everything an agent did elsewhere.
That terminal command is the CLI: the same gateway with no window, and the same policy and evidence checks as CI steps. See what the CLI does
What makes it different
Built for a person, or built for an agent.
A VS Code extension contributes commands, views and menus, and it waits for someone to choose one. Since 2024 it can also register a tool a model calls, and VS Code now documents how an extension can ship an MCP server as well. What neither carries is a rule evaluated on the call itself. An IVYX capability declares its inputs and outputs as JSON Schema, carries a risk level and an approval requirement in the same manifest, and every call it makes is checked against a policy rule and written into the run record.
| Criterion | VS Code extensions | IVYX capabilities |
|---|---|---|
| Built for | A person clicking | A person or an agent |
| Callable by a model | Yes, inside a running editor session | Yes, every capability in the workspace |
| What says no | A confirmation dialog, if you are there to see it | A policy rule, whether you are there or not |
| Aware of the arguments | No. The dialog authorises the tool | Yes. A rule matches an argument tuple |
| Kept as a record | No | Yes, one signed evidence package per run |
This is also why the gate exists. When an agent can reach every capability with nobody watching, a confirmation dialog is not a control: there is nobody to click it. Policy has to be the thing that says no.
The comparison pages carry the long version: against a policy proxy, against a notebook and a tracking tool, and four more. See all six comparisons
Three words used on this site: an extension is what you install; it exposes one or more capabilities an agent can call; an ivy-node is a capability IVYX generated for you, with a manifest.
Nothing runs until policy says yes. Nothing risky runs until you do.
Every model call, tool call and agent step passes the same gate. The rule does not select on who is calling: a person choosing Promote in the app and an agent calling the same capability from Claude Code meet the same rule and write to the same record, and an agent additionally passes an agent-mode profile, so an agent is never gated less than a person.
The decision is made before the action happens, not logged after it. A deny is terminal: no prompt and no standing grant satisfies it. An action whose manifest declares it high-risk stops and waits for you, and the grant is bound to the arguments you saw.
run train-churn-classifier├─ capability.audited datasets.download allowed: true├─ capability.audited mlops.pipeline.run allowed: true├─ capability.audited mlops.model.promote → production allowed: false│ reason: Denied by policy rule churn-project#0.└─ capability.audited mlops.model.promote → staging allowed: true reason: Approval required (step). → granted, scope: once
Example run. Every line is a gate decision, kept with the run.
Policy, next to the work
Rules live with the workspace in a policy file, with conditions on the arguments of a call. Export them to the files your gateway needs, and the export names every rule that could not cross.
Your go-ahead on risk
A capability whose manifest declares it high-risk stops and waits. You see the call, its arguments and the numbers it is claiming before you approve, and the grant covers those arguments only.
An audit chain, not a log
The datasets and files a run touched, with the engine content hash where there is one; every gate decision with the rule that produced it; evaluation figures with the bounds they were measured against. One signed evidence package per run.
Typed, not trusted
An AI-built component declares its inputs, outputs and risk in a manifest, and every call it makes is schema-validated, policy-checked and audited before it executes.
A node is a contract, not a snippet.
Describe what your workspace is missing and IVYX writes it as an ivy-node. The manifest declares what the node may do: which actions it uses from a closed vocabulary of fourteen, what risk it carries, whether it needs a person. Policy binds to that declaration, which is what makes a generated component something you can govern instead of something you have to trust.
Nothing is hidden. The source of every generated node sits in your workspace and in Git, open in the editor. The manifest is what policy reads, not a substitute for reading the code.
ivy-node
The manifest is the component.
Describe a capability your workspace is missing and IVYX writes it as an ivy-node: typed inputs and outputs, a declared risk level, and a validated manifest. The code is one implementation of that contract, and it stays open in your workspace.
- Generate a node with a validated manifest and typed inputs
- Discover, search and register nodes in a central registry
- Test and validate a node before it runs anywhere
- Version, reuse and install components from the marketplace
ivy-agent
Bring workflows to life.
Turn code components into intelligent workflows. Design, test and run them, with governance built in. From simple background tasks to complex operations, full control is in your hands.
- Transform ivy-nodes into runnable workflows
- Approval workflow and policy-based risk assessment
- Artifact store, observability and audit trails
ivy-mcp
Serve your workspace to the agent you already use.
ivy-mcp works in both directions. Serve the capabilities of your workspace to any MCP client, and author your own MCP methods and servers to publish outward. Both directions pass the same gate, and your policy is what narrows what a client can reach.
- Serve your capabilities to Claude Code, Claude Desktop or any MCP client
- Develop custom MCP methods and publish your own MCP server
- Every call, in either direction, passes the gate and joins the run record
Included in the workspace.
Not add-ons. Every published extension is bundled and enabled the first time you launch it.
Work
- Notebooks and local kernels
- Code editor, with a debugger for Python
- Native terminal and Git
- Docker and Compose, managed from the workspace
- Python environments: venv and conda
- Command palette
- AI assistant
Data
- Dataset manager for Kaggle and Hugging Face
- CSV and Parquet profiler, with DuckDB SQL over local files
- PostgreSQL and MySQL browser
- Object storage: S3, GCS, Azure Blob, MinIO
Models
- Local and remote LLMs
- Training runs, tracked and compared, with MLflow inside the workspace
- Model registry and promotion
- Signed evidence packages
Ops
- Run history and comparison
- Trace view for agent runs
- Offline scoring on your golden sets
- Policy gates and approvals
- Secrets, local or in HashiCorp Vault
- Policy export for your gateway
- Audit export
Every item above is also a callable capability. This is not only what you get; it is the action space your agents work in. The Capability Catalog inside the app lists every one of them, across extensions, ivy-nodes, agents and MCP servers, and you choose which ones an outside client may reach. The marketplace adds more.
MLOps and LLMOps
Pass the audit without changing platforms.
Models, under policy
Do the work on your own machine, and still be able to show what happened.
Promote a model and you can build a signed evidence package from it: the training run it resolves to, every gate decision, and the bounds each figure was measured against.
Agents, under policy
The policy is written with the agent and exported to production with it.
A network proxy cannot see an agent that has not left the developer's machine yet; the gate can.
IVYX CLI
The same gate from a terminal: serve the workspace to an MCP client, answer the calls policy holds, and run policy and evidence checks as CI steps.
Read about the CLILLM management in IVYX
Local weights, Ollama and remote providers in one list, one switch that decides which model answers, and instruction classes that fix what each is asked to do.
See how models are managedMLOps in IVYX
The pipeline is one file you can read. Every stage is a gate, every write waits for a person, and the trail remembers who said yes.
Read the pipeline pageUse it, or build on it.
The same governed core, from two directions.
IVYX calls this an application profile: a file that selects which shell modules load and which capabilities are in budget, enforced in the gateway ahead of the policy gate. A vendor shipping a governed surface of its own writes a profile rather than a fork of the core.
Use IVYX Studio
The desktop workspace for data, models, notebooks and agents. macOS and Linux, free for personal use.
Download IVYX StudioBrowsing the marketplace stays open to everyone, with no account.
Build on the governed core
Ship your own product with customer-safe AI extensibility: private registry, self-hosted or air-gapped, audit export included.
Talk to usBuilt for the people who have to answer for it.
Three roles, one question: what ran, on what data, and who allowed it.
ML engineers
Ship a model with its provenance attached, instead of reconstructing it a quarter later.
Data scientists
Notebook to run to artifact, without bolting on a second tool just to track what happened.
Platform and compliance
One policy language for laptops and production, and an audit chain you can hand to a reviewer.
Learning instead? The Education marketplace has guided, notebook-based courses that run inside the app. Education
Extensions, ivy-nodes and courses, installed from inside the workspace.
An IVYX extension is not a UI plugin. It declares typed inputs, runs headless, and is callable by an agent the moment it is installed, so installing one widens what your agents can do, not just what your menus show. Everything published today is built by the IVYX team. The publishing path is live and documented, and we issue the tokens for now, so the guide is worth reading if you want to be among the first.
What is free, and what is not.
IVYX Studio is free for personal use, for students and teachers, and for companies under 250 employees and under 10 million US dollars in annual revenue. Teams and companies above the thresholds pay per seat.
Frequently asked
How is this different from Jupyter or a normal IDE?
Jupyter and IDEs know files; IVYX knows runs, capability calls and gate decisions. Think of what VS Code did for code editing, a small core extended by components, and apply it to AI work with a core that also understands what a run, a dataset and a gate decision are. When something is missing, you describe it and keep the component instead of waiting for a plugin.
How is an AI-built feature kept safe?
An AI-built feature declares its inputs, outputs and risk in a manifest. Every call it makes is schema-validated, checked against policy and written to the run record before it executes, and anything its manifest declares high-risk stops and waits for you.
Do I have to approve every action an agent takes?
You do not approve every action an agent takes. A policy rule decides each capability call in advance, and only the actions whose manifest declares them high-risk stop and wait for you, which is what keeps the interruption meaningful when it comes. The how-it-works page follows one such run from the first call to the signed evidence package.
Can I use IVYX from Claude Code or another MCP client?
IVYX serves its capabilities over MCP, so Claude Code, Claude Desktop and any other MCP client can call them, whether IVYX Studio is open or ivyx serve --stdio is running the same gate from a terminal. Every call an external client makes is evaluated against the same policy rule and written into the same signed run record as the work you do in the app, and your policy is what decides which capabilities it can reach.
How is an IVYX capability different from an MCP server?
An IVYX capability and an MCP server both expose typed, callable capabilities, and IVYX speaks MCP through ivy-mcp in both directions. The difference is what travels with the declaration. A capability manifest is what policy is evaluated against, the decision is bound to the arguments of that call, and every call joins the same signed evidence package as the datasets and files around it. An MCP server declares what it can do; a capability also declares what it may do.
How is IVYX different from an MCP policy firewall or an agent gateway?
An MCP policy firewall or agent gateway such as AgentFence or Amazon Bedrock AgentCore Policy sits in front of tools it does not own and decides each call from the tool name and its arguments. IVYX owns both sides of the call, so its rule reads the capability manifest, the action class, the risk level and whether a person is needed, and the same rule applies whether a person or an agent is calling. The comparison page sets the two side by side, including where a proxy is the better choice.
Read the comparisonCan I read the code IVYX generates?
You can read all of the code IVYX generates. The source of a generated node sits in your workspace and in Git like any other file. What policy checks is the manifest, its declaration of what the node may do, so the code stays fully open to you while the boundary stays enforceable.
Do I have to leave MLflow, DVC or Ollama?
You keep them. MLflow, DVC, Ollama, promptfoo and Evidently are integrated directly, and traces are exported over OTLP, so Langfuse, Phoenix, Tempo and Datadog keep working too. What IVYX adds is the gate and one run identity across all of them, which they do not share with each other.
Where does my data live?
Your data lives on your machine. Files, datasets and local models stay local unless you deliberately connect a hosted service.
Is IVYX Studio free?
IVYX Studio is free for personal use, for students and teachers, and for companies under 250 employees and under 10 million US dollars in annual revenue. There is no trial period. On first launch you create a free account with an email and a password, sign in once, and the app is licensed; there is no key to copy and the licence does not expire. Companies above either threshold need a Business or Team licence, and Enterprise covers self-hosted and air-gapped installs.
Can I use it without installing?
IVYX Studio is a desktop application today, and a browser version is planned. The desktop app is the full experience: native terminal, local files, Git and offline work.