n8n, Zapier, Make and Skybridge do not meter the same thing. n8n prices around complete workflow executions. Zapier generally counts successful actions as tasks. Make uses credits whose consumption depends on module operations and, for some AI features, tokens or other usage factors. Skybridge sits inside a managed Compsia production system and is governed by contracted users, usage and service limits.
A price comparison that starts with plan names will mislead you. Start with a representative workload, translate that workload into each vendor's billable unit, then add model spend, infrastructure and operating labor.
The four billing units answer different questions
n8n's current pricing counts a run of an entire workflow as one execution, even when the workflow contains many steps. Concurrency, retained history, environments and other operating features vary by plan. AI assistant credits may form another allowance.
Zapier's unit is usually a task: a successful action performed by a Zap. One trigger can lead to several tasks, and branching changes the total. Product-specific AI features and tool calls can add their own rules, so a normal Zap estimate should not be copied unchanged into an agent estimate.
Make now uses credits. Most non-AI application operations use one credit. Bundles matter because one action module can run once for every bundle it receives. Some built-in AI functions consume credits dynamically from tokens, file size, page count or runtime.
Skybridge has no separate platform licence inside an active managed Compsia system. The contract defines the permitted users, workload, support and service boundary. Model usage, integration work and continued operation belong in the system economics, even when they do not appear as a per-step software charge.
Build one workload model before opening a pricing page
Use a monthly workload record with six fields:
| Field | What to count |
|---|---|
| Trigger volume | Scheduled starts, incoming events and user requests |
| Path length | Actions or modules on each branch |
| Fan-out | Records, files or recipients processed per trigger |
| AI usage | Input tokens, output tokens, embeddings and model choice |
| Rework | Retries, revisions, tests and human-review cycles |
| Operation | Monitoring, incident response, maintenance and support time |
The fan-out field catches the most common error. A scenario that reads one list and updates 100 records does not have the economics of a two-step flow. The trigger may run once while a downstream module runs 100 times.
A worked example shows why the units diverge
Consider a hypothetical weekday process that receives 200 requests each month. Each request reads one source, classifies the item, drafts a response and creates a record. Twenty per cent need a human revision. Ten per cent retry once after an external API error.
The workload has 200 top-level runs, but more than 200 downstream actions. If the flow has three billable actions after the trigger, the base volume is about 600 actions before revisions and retries. A record-level fan-out would increase that number again.
Under an execution model, the base estimate may remain close to 200 executions if each request stays within one workflow. Under a task or module-credit model, the estimate follows the actions and bundles. AI model charges depend on tokens, not the workflow count. A managed service adds the work required to design, release, observe and maintain the production result.
This does not make one model cheaper in general. It shows which variable each model rewards. Long workflows can favor execution pricing. Small, infrequent handoffs can fit task pricing well. Visual scenarios make per-module consumption visible. Managed delivery can be economically sound when internal ownership would otherwise become a second job.
Include the cost that appears after launch
Software calculators rarely know your operating burden. Add these items to the estimate:
- the time spent designing and reviewing the process;
- test and development runs;
- model-provider fees and embedding costs;
- hosting, storage, backups and secrets where self-hosted;
- failed-run investigation and replay;
- connection renewal and API-change maintenance;
- human approval and revision time; and
- the cost of an unowned business failure.
The final item is not a fictional risk premium. Give it a bounded form: which failure matters, how often could it occur, who detects it and how much work is needed to recover?
How Skybridge makes cost an operating record
In Skybridge, usage records are kept outside short-lived runtime counters so deployment restarts do not erase the historical view. Input and output tokens are separated because model providers can price them differently. Usage can be attributed by period and workload, while cost projections use measured baselines and expected run frequency.
This design separates two jobs. Live telemetry tells an operator what is happening now. The durable ledger supports monthly reconciliation and planning. Estimated usage remains visibly distinct from observed usage.
The approach also keeps the commercial boundary honest. Skybridge access is included within the contracted system limits. A material new workload, integration or business perimeter is assessed as a system change, not hidden behind an unlimited-use claim.
Use a cost decision that survives a price change
Vendor prices and plan boundaries change. A good spreadsheet should survive that change because its workload assumptions stay explicit. Keep a row for each use case, record the unit conversion, and version the date of every vendor rate.
Then compare three totals: platform consumption, AI and infrastructure consumption, and operating ownership. That is the level at which n8n, Zapier, Make and a Compsia system with Skybridge can be compared fairly.
Continue with the four-way operating-model comparison or use the durable AI cost ledger guide to design the evidence behind the estimate.
Continue reading: Skybridge vs Make: choose visual scenario control or managed production ownership.