How it works

A small model that only has to pick the right action

A large general model answers anything, which is why it is expensive and slow. An everyday request does not need that. It needs the right action from a short list, with the details filled in correctly. Fernfly trains a small model to do that one job on your actions, and hands the result to your system to run.

One request, two bills
“refund order 62, damaged item”
refund_order({ id: 62, reason: "damaged item" })
Large general model
$10.10
per 1,000 calls
  • ~3,800 tokens listing your actions, every time
  • A few seconds each
  • Runs in the vendor’s cloud
Fernfly
$0
flat plan, any volume
  • Your actions registered once
  • Under a second each time
  • Can run on your hardware
Large-model figure: OpenAI’s published GPT-4o rates ($2.50 and $10.00 per million tokens) against a list of 40 actions. Your own numbers will differ, and the playground measures them.
The cost

Where the money goes

Three costs that come from how the task is run, not from how hard it is.

The list of actions

A large general model has to be told what your app can do, every time you ask it anything.

On a large general model

Re-sent on every request, and charged for every time.

As a function call, on Fernfly

Registered once. Every request after that refers to it.

The bill

Agent platforms charge for the work rather than the software.

On a large general model

Between $0.50 and $0.99 for each resolved conversation.

As a function call, on Fernfly

A flat monthly price, whatever the volume.

The work itself

"Refund order 62" has one right answer and nothing to weigh up.

On a large general model

Reasoning you are paying for and the task never needed.

As a function call, on Fernfly

One step: pick the action, fill in the details, hand it back.

Per-conversation figures are the published rates for Intercom Fin and HubSpot Breeze.

Paying per request scales the wrong way

It is cheapest on the days nothing much happens, and most expensive on the day everything does. A flat price is the other shape.

cost per monthconversations per month
Per-message pricingFernfly, flat
Compare

Three ways to run one request

For an everyday request that ends in one action. Open-ended work is a different question, and the large general model still wins it.

Fernfly
a small model on your API
Large general model
prompted per request
RAG pipeline
retrieve, then prompt
Cost per 1,000 requests Flat, whatever the volume Tokens in and out, on every request Tokens plus retrieval
The list of actions is Registered once, then referred to Re-sent, and charged for, every time Re-sent, plus whatever was retrieved
Typical response Under a second A few seconds Retrieval, then a few seconds
On a repeatable request it is Trained on your own actions General, and prompted each time Good at finding, not at doing
When it does not know Returns nothing and hands off Tends to produce something Answers from the nearest document
Can run inside your network Yes, on a CPU Vendor cloud Store yes, model usually not
The lifecycle

What the next month looks like

Five stages, all of them in the browser. Follow one example the whole way through, or switch it to the business you actually run.

Walk me through
Stage 01

Describe

Paste your address. Fernfly reads what you already have, works out what your business does, and proposes the actions your assistant should be able to run. You tick the ones you want.

  • Works from a website, an OpenAPI file, or a plain description
  • Nothing to install, and no account needed to see the first result
  • Upload an OpenAPI or Swagger file and skip the crawl
Reading the API spec38 endpoints
yourapp.com/openapi.json
Actions found41
invite_user
export_report
change_plan
search_records
Proof

Do not take it on trust

The playground runs the same curated requests through a Fern use-case model and through GPT-4o, side by side, and reports what each one got right, whether the arguments would have been accepted by your app, how long it took and what the large model cost.

Run it yourself
Exact match
right action, right details
Valid
would your app accept it
Latency
measured per run
Cost
the large model, priced
What you get

Built for the repeated 80%

It declines instead of guessing

Outside the actions it was trained on it returns nothing and hands off. On a repeatable task a wrong action costs more than a missing one.

Your traffic is the next training set

Everything it could not handle is collected in one list. Approve, retrain, publish. The old version serves until you switch.

You can see what it did

How many requests, how fast, which actions ran, how often it handed off, and where the people asking came from.

It is your model, not a prompt

Trained on your own actions, versioned, and pinned to a deployment you control.

Point it at your actions

Free to start, no credit card, and the first one is live in an afternoon.