Comparison
SMELT Studio and Dify
Dify is the closest thing to us on this list and it is free. It is open source, you can run it on your own hardware, and it ships an embeddable chat widget we do not have. If any of those three is a requirement, stop reading and use Dify. What is left is a difference of operational discipline, which is a slower argument and the only honest one we have.
Where Dify is the better buy
You can run it yourself, for nothing. Dify publishes a free Community Edition on GitHub and describes its core features as released under its open source licence. We have no self-host at all. If your data cannot leave your network, or you simply want the option of leaving without a migration, that is a decisive advantage and this comparison is over.
The chat widget. Dify documents embedding a published app straight into a website:
Your published web app can be embedded directly into any website using these methods
A chat bubble or an iframe, and it is working today. We do not have this. It is the single most commonly assumed capability we are missing, and it ends conversations that were otherwise going well.
Chat and retrieval as the centre of the product. If what you are building is an assistant over your documents, Dify is built around exactly that shape and we are not.
What we optimise for instead
An app builder is judged on the first run. We are built to be judged on the ten thousandth, and that is a different set of decisions.
Runs survive a restart. A run checkpoints after each block and holds a lease with a heartbeat. If the process holding it dies, a sweeper notices the stale lease, exactly one replica claims the run, and it continues from the last completed block rather than dying halfway through. The block that was in flight at the moment of the restart runs again, so it resumes at block granularity, not at the instruction. It is worth asking any platform you are evaluating what happens to an in-flight run when the container restarts, and then testing the answer rather than accepting it.
Traces you can follow across processes. Trace identifiers are stamped at the gateway and carried through the message bus to the agent and back, with OpenTelemetry spans exported in production, not just in a local debug mode. In the app, the trace shows each block with its output and its duration, and each delegated agent call with the credits it consumed.
Failure is configurable rather than fatal. Retries with a bounded attempt count and backoff, a separate error path out of any block so a failure can be handled rather than ending the run, an explicit stop and error block, and approval gates for anything you do not want an agent doing unsupervised.
Agents are versioned resources. An agent is defined once in your workspace and a workflow block pins an exact published version, so shipping a new version of an agent does not quietly change the workflows already running on the old one.
A different centre of gravity
Dify's centre is the LLM application: chat and retrieval, with a canvas attached. It does workflows too, and for assistants it does them well. Ours is the orchestrated workflow, with agents as typed resources, real tool access and human approval where it matters.
Concede the overlap rather than argue about it. The two products look similar in a screenshot and diverge after a month of use, and which divergence you want depends on whether you are shipping a chatbot or running unattended work.
What a run costs, while it is running
Runs are metered in credits. Each block reports its credits and duration as it finishes, the trace shows the credits a delegated agent call consumed, and your workspace usage shows credits drawn against the monthly allowance on your plan. The number is in the app while the work happens rather than on a model provider invoice four weeks later.
This is not a claim about being inexpensive, and we would rather you did not read it as one. It is one predictable number covering orchestration, inference, retries and key management. If your objection is price per token, connect your own OpenAI or Anthropic key and the meter stops entirely.
Plans are monthly. See pricing for the allowances on each tier.
The answer to "do you support X"
If X has a REST API, you can reach it today. The HTTP block calls any endpoint, with your own headers, query parameters and JSON body, and the response comes back as a typed output the next block can reference.
It is guarded rather than open. The host is resolved once, private, loopback and link-local addresses are refused, and the request is then sent to the address that was checked, with the original host header preserved. A DNS answer that changes underneath you does not turn into an SSRF against our network or yours.
Inbound, a webhook trigger gives a workflow its own ingest URL and a signing secret you send in the x-webhook-secret header, and a Respond to Webhook block lets the workflow answer the caller in the same request. Schedule, form, chat and manual triggers sit alongside it, as do triggers for the providers in the palette.
This is a capability, not an apology for a short list. It is also why we do not publish a connector count: it would be a scoreboard for a game we deliberately are not playing.
Who should not buy this
If self-hosting matters, use Dify. If you need a chat widget on your own site, use Dify. If you want to read the runtime source, use Dify. Those are three good reasons and we cannot argue with any of them.
What we do not have
Better you read this from us than find it in a comment thread. Each of these ends some evaluations, and it should.
- No self-host. There is no way to run SMELT Studio on your own infrastructure. Our typed contracts are published and inspectable, so the shape of the architecture is not a secret, but that is weaker than being able to run the thing yourself and we are not going to dress it up as an advantage.
- No Data Tables. There is no built-in store for structured rows between runs. Keep that state in a database you already own and reach it over HTTP.
- No evaluations surface. There is no place in the app to assemble a test set for an agent, score it, and watch the score move when you change a prompt. If a graded regression suite is a condition of putting an agent near a customer, we do not meet it yet.
- No embeddable chat widget. You cannot drop a SMELT chat onto your own website. A hosted form is the only public entry point we offer, and it is a form, not a conversation.
- No MCP server. SMELT can call an external MCP server as a tool. It cannot be one, so another AI client cannot reach into SMELT and run your workflow that way.
- Agent memory is a capped list. An agent decides what to remember, and recall is by semantic search rather than a raw read-back. The list is still capped per agent, and the least recently used entries fall off the end. Treat it as recall between runs, not as a knowledge store.
If one of these is a condition of your buying, say so at [email protected] rather than working around it.
If you are also evaluating automation tools
The n8n migration guide lists the block for block mapping, which is the fastest way to see what is actually in the palette.
Sources
Every claim about another product on this page is checked against that product's own published pricing or documentation, and the date of the last check is recorded in this page's source. Competitors ship quickly, and a page like this goes stale by default rather than by neglect. If something here has gone out of date, tell us at [email protected] and we will correct the page.
Try it against your own workflow
The free tier runs real workflows. Build the one you are unhappy with elsewhere and see whether the second change is easier than the first.