Describe your API. Fernfly writes the training data, fine-tunes a small model on your tool set, and mints an endpoint that returns a validated call. One HTTP request, no prompt engineering, and no per-token bill.
Post an utterance with your project key. Get back the calls to run, in the order to run them, or an empty list when the model declines rather than guesses. That is the whole surface.
POST /api/p/YOUR_PROJECT_ID/infer
X-Api-Key: YOUR_PROJECT_KEY
Content-Type: application/json
{
"utterance": "move my 3pm standup to Thursday",
"meta": { "user_id": "u_1042" }
}{
"calls": [
{
"name": "reschedule_event",
"arguments": {
"event": "Standup",
"to": "2026-07-09T15:00"
}
}
]
}You can, and for a handful of calls a day you probably should. The economics invert once the same bounded intent runs thousands of times: a general model re-reads your entire tool schema on every call, and you pay for those tokens every time.
Tools are registered once and referenced by id. A frontier call pays for the full spec as input tokens on every request.
Intent to action is a single classification with arguments. No planning loop, no chain of thought, no retry budget.
A 12M-parameter model runs on ordinary CPU hardware, which is what makes on-premises and offline deployment possible at all.
Do not take the claim on trust. The playground runs the same curated tasks through a Fern use-case model and through GPT-4o side by side, and reports accuracy, schema conformance, latency, and the frontier cost per run.
Open the playgroundYour tool schema is uploaded once and content-addressed to a tool_set_id. Training lines and inference calls then reference the id instead of re-sending tens of KB of JSON Schema on every request.
Gemini writes candidate utterance-to-call pairs from your schema, including negatives for anything out of scope. You review, edit, and approve them before they become training data.
Approved pairs become OpenAI-shaped JSONL and a fine-tuning job on the Fern inference API. Epochs, batch size, and learning rate default from a pair-count heuristic and can be set explicitly.
A deployment pins one fine-tuned model id. The stable per-project endpoint always routes to the active deployment; the per-deployment endpoint pins a version, so you can hold traffic on a known-good model while you retrain.
Where a project starts unless you say otherwise. Trains in minutes and runs comfortably on a CPU.
More accurate once the tool set grows past what a 12M model holds comfortably. Slower to train and slower to answer.
The accuracy ceiling, and what our own templates train on. Slowest to train and to answer.
Base model, epochs, batch size, and learning rate all default from the size of your approved training set, and the wizard pre-fills them. Set them explicitly if you have a reason to. They are fixed once the project has trained, so a retrain reproduces the same configuration.
One script tag. The bubble renders on your site, calls the keyless endpoint, and is constrained by your origin allow-list.
POST the utterance with a project key, get the call back, and execute it yourself against your API with your own auth and permissions.
The model is small enough to run on your hardware, so conversations never leave the building. Talk to us about a private deployment.
Server-to-server with a project API key, or keyless for the browser widget. Key-authed traffic skips the origin check and the rate limit; keyless traffic gets both.
Keyless projects answer only the domains you list, and the CORS grant reflects the caller instead of a wildcard. Requests with no Origin header fall through to the rate limit, since Origin is trivially forged outside a browser.
20 requests a minute per caller per project on the keyless endpoint, counted in the database so the window is shared across workers and survives a reload.
Latency, the resolved call, the fallback path, and a salted caller hash. The analytics tab rolls it up; the history tab lists it one row at a time.
Hoobert is a ⌘K command bar for WooCommerce, live on the WordPress.org plugin directory. It is an ordinary Fernfly project: 28 store actions, one endpoint, and a plugin that executes the returned call through the WooCommerce REST API with the shop manager's own permissions.
Every request is logged with what the model resolved it to, and the ones it declined are collected as the retraining queue. Approve them, retrain, and cut a new deployment. The previous version keeps serving until you switch, so there is no window where the endpoint is down.
Free to start, no credit card, and the first endpoint is live in an afternoon.