How IVYX compares
Five comparisons, each written to be useful even when it argues against us. Competitor rows were checked on 5 September 2026.
IVYX vs Visual Studio Code
Visual Studio Code and IVYX Studio are both extensible workspaces, so the comparison worth making is between their extension models rather than their feature lists. A VS Code extension is written for a person: it contributes commands, views and menus. Since the Language Model Tool API was finalised in late 2024 an extension can also register a tool a model invokes, and VS Code now documents a path for an extension to ship an MCP server as well, so reach is no longer the interesting difference. 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 evaluated against a policy rule and written into a signed run record. The difference is not where a tool can be called from. It is what travels with the call.
The short answer
- Use VS Code to edit code. Its extension ecosystem is the largest in software and IVYX has nothing comparable.
- Use IVYX Studio when what an agent did to your data and models has to be provable afterwards.
- This is not an editor comparison. IVYX does not try to replace VS Code as a place to write code.
| Criterion | VS Code extension | IVYX capability |
|---|---|---|
| Written for | A person clicking commands, views and menus | A person or an agent |
| Callable by a model | Yes, through the Language Model Tool API | Yes, every capability in the workspace |
| Typed inputs and outputs | Yes, JSON Schema in package.json | Yes, JSON Schema in the capability manifest |
| What authorises a call | A confirmation dialog, with Always Allow | A policy rule, evaluated before the call runs |
| Rules aware of arguments | No. The dialog authorises the tool | Yes. A rule matches an argument tuple, and a grant is bound to one |
| If nobody is watching | The dialog waits | The rule decides, and the decision is recorded |
| Record of the call | Not kept as a system of record | A signed run record, beside the datasets and files the run touched |
| What is governed | The tools an extension registers | Every capability, from the notebook kernel to the database browser |
| Ecosystem size | Tens of thousands of extensions | Small, and first-party today |
Where VS Code is ahead
By almost every measure that is not on this page. VS Code is free, on every platform, and carries the largest extension ecosystem in software; its Language Model Tool API is well designed, its tools are schema-validated before invocation, and the confirmation flow with Always Allow is a sensible default for a person sitting at the keyboard. IVYX has a fraction of the catalogue and everything in it today is first-party. If your work is writing code, this comparison should end here.
Where the line falls
A confirmation dialog assumes a person is present, and it authorises a tool rather than a call: once you have clicked Always Allow, every future invocation with every future argument is covered. A policy rule is written in advance, matches on the arguments, and produces a decision that is recorded whether or not anyone is at the keyboard. That is a different guarantee, and it is the one that starts to matter once an agent is doing the work.
Frequently asked
Can VS Code extensions be called by an LLM?
VS Code extensions can be called by an LLM. The Language Model Tool API, finalised in late 2024, lets an extension register a tool with typed, schema-validated inputs that a model invokes, and VS Code also documents how an extension can ship an MCP server so that other clients can reach it. What the API does not carry is a policy rule evaluated on each call, a decision bound to the arguments of that call, or a record joining the call to the data it touched.
Is IVYX Studio a fork of VS Code?
IVYX Studio is not a fork of VS Code or Code OSS. It is a desktop application built on its own substrate with its own component model. It uses the Monaco editor component, as many applications do, which is not the same thing as deriving from Code OSS.
Is IVYX Studio trying to replace VS Code?
IVYX Studio is not trying to replace VS Code. It replaces neither the editor nor its ecosystem, and the intended split is code in VS Code, models and agents in IVYX Studio.
IVYX vs Cursor
IVYX Studio and Cursor solve different problems. Cursor is an AI code editor: the unit of work is a file and the goal is to write software faster. IVYX Studio is a local AI workspace: the unit of work is a run, and the goal is to be able to show afterwards what a model or an agent did. Cursor already gates the two boundaries an editor has, and gates them properly. The difference is how much of the workspace is governed that way, and whether anything keeps the record.
The short answer
- Use Cursor or VS Code if your work is application code. Their completion and multi-file editing are ahead of anything IVYX offers.
- Use IVYX Studio if your work produces datasets, models, evaluations or agent runs that someone will ask about later.
- Use both. IVYX does not replace your editor, and nothing in it asks you to stop using one.
| Criterion | Cursor | IVYX Studio |
|---|---|---|
| Unit of work | A file | A run |
| Primary job | Write and edit code | Train, evaluate and operate models and agents |
| What is gated | Shell commands and MCP tool calls, through hooks | Every capability call in the workspace |
| How rules are written | A hook script you write and maintain | Declarative rules in a policy file, with conditions on arguments |
| Fail closed | Yes, per hook | Yes, per workspace |
| Headless operation | Yes. The Cursor CLI runs with no editor window | Capabilities run headless, but IVYX Studio has to be running |
| Dataset identity | A file path | A path, with the pipeline engine content hash where it supplies one |
| Audit output | Git history | A signed record per run: datasets, files, gate decisions, approvals |
| Works offline | Editing yes; AI features need the cloud | Yes, including local models |
When Cursor is the better tool
If you are building an application, Cursor is the stronger choice and it is not close. Its completion model, multi-file refactoring and codebase indexing are the product of a team working on that problem full time. Its hooks are also a genuine pre-execution control rather than a diff review: beforeShellExecution and beforeMCPExecution fire ahead of the call and can deny it outright, and a hook can be declared fail-closed so that a broken hook blocks instead of permitting. IVYX generates components, not applications, which is a narrower job by design.
When an editor is not enough
The gap opens on breadth and on memory. Cursor governs the two boundaries an editor has: the shell and MCP. A workspace for model work has more of them, and the dataset manager, the kernel, the model registry and the database browser are each a place an agent can do something you would want a rule about. And when it is over, an editor has no concept of a run, so it cannot answer which dataset trained this model, or who approved the promotion and against which numbers. Git tells you what changed in a file. It does not tell you what a model did with data that was never in the repository.
Frequently asked
Can I use Cursor and IVYX Studio together?
Cursor and IVYX Studio can be used together, and running both is the intended setup: application code in Cursor, model and agent work in IVYX Studio. Neither one requires you to move your repository.
Does Cursor gate agent actions before they run?
Cursor gates agent actions before they run. Its beforeShellExecution and beforeMCPExecution hooks fire ahead of the call and return allow, deny or ask, and a hook can be set to fail closed so that a hook failure blocks rather than permits. The limits are scope and memory: the hooks cover shell commands and MCP tool calls rather than every capability a workspace exposes, the logic lives in a script you maintain rather than in declarative rules, and the decisions are not collected into a signed record of the run.
Does IVYX Studio write code the way Cursor does?
IVYX Studio generates components rather than completing code as you type. You describe a capability the workspace is missing, IVYX builds it with a validated manifest and typed inputs and outputs, and it runs only after it passes policy and, for anything declared high-risk, your approval.
IVYX vs AWS Kiro
AWS Kiro and IVYX Studio share a conviction and apply it to different work. Both hold that a declaration belongs in front of the work, and that a person approves before an agent acts. Kiro is a spec-driven IDE for application development: it writes requirements, design and task documents, waits for your approval, then generates code from them. IVYX Studio applies the same principle to data, models and agents: a capability manifest declares what a component may do and at what risk, and the gate evaluates policy against that declaration on every call at runtime, not only at the points where a person is asked to approve.
The short answer
- Use Kiro if the thing being governed is source code, especially on AWS.
- Use IVYX Studio if the thing being governed is a dataset, a model or an agent in operation.
- They do not functionally overlap. Kiro published material describes no dataset, training-run or model-promotion features, and IVYX does not generate applications.
| Criterion | AWS Kiro | IVYX Studio |
|---|---|---|
| Category | Spec-driven agentic IDE | Local AI workspace |
| Built on | Code OSS, the VS Code open-source base | Its own substrate, with its own component model |
| Primary artifact | The spec: requirements, design, tasks | The manifest: what a capability may do, and at what risk |
| When approval happens | On the spec before code is generated, and per change or shell command in supervised mode | On every call at runtime, plus explicit approval for anything declared high-risk |
| Generally available | 7 May 2026 | In beta |
| Knows a dataset | Not described in published material | Yes, by path, with a content hash where the engine supplies one |
| Knows a training run | Not described in published material | Yes |
| Model promotion | Not described in published material | Yes, declared high-risk, with a signed evidence package |
| Model backend | Hosted models through the Kiro service | Local or remote models, your choice |
Where Kiro is ahead
Kiro has been generally available since 7 May 2026, is backed by AWS, and its spec workflow for application development is more developed than anything IVYX offers for writing software. If the artifact you need governed is source code, Kiro is the more mature answer and IVYX does not compete with it. Its agent hooks and steering files are also a good model for encoding team standards, and IVYX policy files serve a narrower purpose by design.
Where the line falls
Kiro governs the act of writing software. IVYX governs the act of running a model or an agent. The distinction is not academic: a spec approved before code generation says nothing about what the deployed agent does at three in the morning with a customer record, which dataset a retraining job read last night, or whether a promoted model was checked against the bounds it claimed. Those are runtime questions, and they need a runtime gate. Both products are downstream of the same idea. They put the declaration in front of different work.
Frequently asked
Is IVYX Studio an alternative to AWS Kiro?
IVYX Studio is not an alternative to AWS Kiro, because the two govern different objects. Kiro governs the code an agent writes for you, approving a specification before generation. IVYX Studio governs what a model or an agent does when it runs, evaluating policy at each capability call. A team can reasonably use both.
What is the difference between spec-driven development and a capability manifest?
Spec-driven development puts a written specification ahead of the code: the spec is reviewed and approved, and code is generated from it. A capability manifest operates at runtime instead. It declares what a component may do, and policy is evaluated against that declaration every time the component is called. A spec governs what gets built. A manifest governs what is allowed to happen.
Does AWS Kiro handle machine learning or data workflows?
AWS Kiro is positioned for application development, with particular strength on AWS-native stacks. Its published material does not describe dataset management, training runs or model promotion, so a team with those requirements should check current AWS documentation rather than assume coverage.
IVYX vs Kiln AI and Transformer Lab
Kiln AI, Transformer Lab and IVYX Studio are all local desktop workspaces for AI work, and they overlap on evaluation, datasets and agents. The difference is what happens at the moment a model or an agent acts: Kiln AI and Transformer Lab record it, IVYX evaluates a rule first and can refuse. If your requirement is an enforced, signed record, that gate is the deciding feature. If it is not, Kiln AI and Transformer Lab are mature and very good at what they do, and on model training Transformer Lab is ahead of IVYX outright.
The short answer
- Transformer Lab if the work itself is model training. It fine-tunes, including LoRA on diffusion models. IVYX does not fine-tune at all.
- Kiln AI if you want a mature evaluation workflow with team ratings, synthetic data and Git-native dataset versioning, and you do not need enforcement.
- IVYX Studio if someone outside your team will ask what ran, on what data, and who allowed it.
| Criterion | Kiln AI | Transformer Lab | IVYX Studio |
|---|---|---|---|
| Local desktop app | macOS, Windows, Linux | macOS, Windows via WSL2, Linux | macOS and Linux |
| Fine-tuning | Yes, including distillation | Yes: full, LoRA and QLoRA, DPO, ORPO and SimPO | No |
| Diffusion and images | No | Yes, including LoRA training | No |
| Evaluation | LLM-as-judge, golden datasets, human ratings | LLM-as-judge, benchmarks | Deterministic offline scoring on your golden sets |
| RAG | Yes, with chunking and indexing | Via plugins | Yes: chunking, embedding, indexing and retrieval |
| MCP | Yes, tools and MCP support | Listed in the app | Yes, and it publishes servers as well as consuming them |
| Policy gate before execution | No | No | Yes |
| Human approval in the path | No | No | Yes, for capabilities declared high-risk |
| Signed audit record | No | No | Yes, one per run |
| Licence | MIT library and server; source-available desktop app | AGPL-3.0 | MIT source; the app runs on a 7-day trial, then a licence key |
Recording and enforcing are different guarantees
All three keep a history of what ran. Kiln AI versions datasets through Git, Transformer Lab keeps runs in the app, and IVYX names every dataset and file its calls touched. Only IVYX evaluates a rule before the action and can refuse it, and only IVYX stops for a person on an action its manifest declares high-risk. A history assembled after the fact can prove harm occurred. A record built from gate decisions can show it was prevented.
Where IVYX is behind
On training, plainly. Transformer Lab does full fine-tuning, LoRA and QLoRA, preference-optimisation methods and diffusion LoRA. IVYX does none of that and has no plans to: fine-tuning orchestration is recorded as out of scope. Kiln AI evaluation workflow, with team ratings and synthetic data generation, is more developed than IVYX offline scoring. And both ship on Windows, which IVYX does not yet.
Frequently asked
Which local AI workspace has an audit trail?
Of the local desktop AI workspaces, IVYX Studio is the one built around an audit trail: every run records the datasets and files its calls touched, along with every gate decision and approval, as one signed package. Kiln AI and Transformer Lab keep run history but do not produce a signed record built from enforced decisions.
What is the best local alternative to Kiln AI?
Transformer Lab and IVYX Studio are the two closest local alternatives to Kiln AI. Transformer Lab goes deeper on model training, including diffusion and preference-optimisation methods. IVYX Studio adds a policy gate and a signed audit record, which neither Kiln AI nor Transformer Lab provides.
Can I use Kiln AI or Transformer Lab alongside IVYX Studio?
Kiln AI, Transformer Lab and IVYX Studio can run side by side. All three are local desktop applications that work on ordinary files and datasets, so nothing prevents it. Training in Transformer Lab and promoting the result through IVYX Studio, so that the promotion carries a signed record, is a reasonable split.
IVYX vs assembling it yourself
You can assemble most of IVYX Studio from free open-source tools: MLflow for runs and model lineage, Langfuse or Arize Phoenix for traces, Ollama or LM Studio for local models, promptfoo or DeepEval for evaluation, and OPA or Cedar for policy. Many teams should. IVYX earns its place only when those pieces need to share one record and one gate, because an assembled stack records what happened and stops nothing unless you wire enforcement into every call yourself.
The short answer
- Assemble it yourself if what you need is visibility. The tools are free, mature, and your team already knows them.
- Use IVYX Studio if you need a decision made before an action runs, a person in the path for high-risk steps, and one record that spans data, models and agents.
| Criterion | Assembled stack | IVYX Studio |
|---|---|---|
| Records what happened | Yes | Yes |
| Lineage across runs, models and prompts | Yes, in MLflow 3 | Yes |
| Agent call traces | Yes, in Langfuse or Phoenix | Yes, over OTLP to any compatible backend |
| Local model serving | Yes, via Ollama or LM Studio | Yes |
| Offline scoring on golden sets | Yes, via promptfoo or DeepEval | Yes |
| Stops an action before it runs | Only where you wire it. OPA or Cedar can decide and a gateway such as LiteLLM can enforce on model calls, but nothing spans data, model and agent calls together | Yes, at one gate every capability call passes through |
| Human approval in the execution path | Only inside an agent framework that supports interrupts | Yes, for capabilities declared high-risk |
| One record across data, models and agents | No. Each tool has its own id space, joined by hand | Yes, one run identity |
| Signed record you can check offline | Not as one record across the stack | Yes |
| Setup and upkeep | Five services, five upgrade paths, five auth models | One install |
What the assembled stack already does well
This case is stronger than it was two years ago, and it is worth stating plainly. MLflow 3 treats a logged model as a first-class object with lineage across runs, traces, prompts and evaluation metrics: a real provenance graph, not just a metrics table. Langfuse and Phoenix self-host on your own infrastructure and capture full agent traces. promptfoo and DeepEval run your golden sets locally. Ollama and LM Studio run local models in one command. If your requirement is to see what happened, this stack meets it and costs nothing.
Why the distinction matters
A recorded system tells you, after the fact, that an agent sent customer data to an unapproved endpoint. A gated system does not let it. Both produce a log; only one produces a log in which the unwanted action was refused rather than done. That is the whole reason IVYX exists, and it is the only question worth asking when you compare it to a stack you could build yourself.
You should not buy IVYX if
Documentation is the requirement rather than prevention: MLflow 3 and Langfuse meet that today, for free. Nobody outside the team asks: two people, no external auditor and no regulated data, and the gate is overhead you will route around within a month. Or the stack already runs well: a team fluent in it loses more to migration than it gains from consolidation. Add the gate later, when someone asks for it.
Frequently asked
Does IVYX Studio replace MLflow?
IVYX Studio does not replace MLflow. MLflow records runs, models and lineage; IVYX Studio adds the gate that decides whether a call happens at all, and a signed record spanning data, models and agents. The intended pattern is to keep MLflow, which IVYX writes to directly, and let IVYX add the record MLflow cannot.
Do MLflow, Langfuse and Phoenix gate anything, or only record?
MLflow, Langfuse and Phoenix record. They capture runs, lineage and traces after an action has taken place, and they do it well. None of them sits at the call boundary and refuses an action before it executes. OPA or Cedar can make that decision, but nothing in the stack wires the decision into every call. An audit trail assembled from these tools can prove that harm occurred. It cannot show that harm was prevented.
Can I keep Langfuse, Ollama and promptfoo if I use IVYX?
Ollama and promptfoo are integrated directly: IVYX manages a local Ollama daemon and runs promptfoo locally. Langfuse is reached the way any OTLP-compatible backend is, because IVYX exports traces over OTLP, so Langfuse, Phoenix, Tempo, Jaeger and Datadog all work without a vendor-specific integration.
Why not just publish these capabilities as MCP servers?
You can publish these capabilities as MCP servers, and IVYX does exactly that through ivy-mcp, so nothing stops you. What a plain MCP server does not carry is a manifest that policy is evaluated against, a decision bound to the arguments of the call, or a shared run identity linking a tool call to the dataset it read and the file it wrote. MCP says what a capability can do. The manifest adds what it may do, and its calls land on the same signed record as everything else in the run.
Competitor rows are drawn from each vendor published material and were checked on 5 September 2026. A comparison page with a stale competitor row does more damage than no page at all, so if you are reading this much later, treat the competitor columns as dated.
Runs on your machine. macOS and Linux.