Comparison
SMELT Studio and Make
Make is a well built platform with a much larger application catalogue than ours and a canvas that is, honestly, nicer than ours. If the problem is reaching applications, buy Make. What follows is the narrow set of things that are different, and one naming collision that will confuse you if nobody points it out.
Where Make is the better buy
The catalogue. Make connects to far more applications than we do, including a large set of AI-specific ones. If the integration is the job, this is not a close call.
The canvas. Make's scenario editor is better designed than ours and will probably stay that way. We are not going to try to win a demo on visual polish, and any comparison that turns on how the canvas looks goes to them.
They have shipped agents. Make lists AI Agents on every plan, in beta, usable with their AI provider or your own model key. Anyone telling you Make has no agent story is working from an old note. They are investing here and the differences below will narrow.
Both products say credits and mean different things
This is the thing to get straight before you compare anything. Make's published pricing defines a credit as a unit of work in a scenario:
Each module action in your scenario, like adding a Google Sheet row or fetching Gmail account data, counts as one credit.
Most actions consume one, and their pricing notes that some advanced AI features consume more. So a Make credit is roughly a step.
A SMELT credit is not a step. It is a unit of model work, weighted by what the model call actually cost to serve, and it is separate from the workflow executions your plan includes. A workflow with many cheap steps and one large model call looks very different under the two meters. Neither is dishonest. They are answering different questions, and you should not put the two numbers side by side and conclude anything.
The practical consequence for agent work: an agent that calls four tools and retries twice is not one step. Under a per-step meter it is however many steps it turned out to need, which is a number you discover after you have built the thing. Under ours you see the model work reported as it happens.
What is different about an agent here
Rather than tell you what Make's agents cannot do, here is what ours are, which you can check against whatever they ship next.
An agent in SMELT Studio is created once in your workspace, not inside a scenario. It has a draft you edit and published versions you pin, and a workflow block references an agent and an exact version, so publishing does not silently change workflows that were working this morning. Its page tells you which workflows use it. An agent can use another agent as a tool, so a supervisor delegates inside a single run with a depth limit and a cycle guard, and the trace records each hand-off with the credits it consumed.
Two honest qualifications: delegation and agent memory are not on the free tier, and the agent page has no chat playground yet.
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 the value is the catalogue, use Make. If you are choosing on the look of the canvas, use Make. If your scenarios are data moving between systems with no judgement in the middle, you will be paying us for machinery you never switch on.
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.
Coming from a scenario builder
The n8n migration guide is the closest thing we have to a concept map, and the vocabulary of modules, routers, filters and connections translates well enough to be worth reading first.
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.