Model comparisons ยท 2026-09-25

Tool calling and JSON Schema with Ember-1

Tool calling means a model proposes a function an application may call, not that it performed an external action. Ember-1 supports automatic and required tool choice, but business rules remain in the application. JSON Schema reduces parsing errors but does not make data true; amount, ownership, permission, and freshness need server validation.

Technical flow visual for Tool calling and JSON Schema with Ember-1.

Purpose of this guide

Tool calling means a model proposes a function an application may call, not that it performed an external action. Ember-1 supports automatic and required tool choice, but business rules remain in the application. JSON Schema reduces parsing errors but does not make data true; amount, ownership, permission, and freshness need server validation.

Design the first experiment

A tool call is a model proposal, not authority to act. Enforce a server-side allowlist, user permission, ownership, and idempotency for every function; `tool_choice: required` does not replace those controls.

Keep contracts small and explicit. Parse model arguments with Zod or an equivalent validator and return a recoverable error for invalid values instead of calling an external system.

Application boundary

Use `json_object` when an object is useful, but do not assume strict JSON Schema support. Validate shape in the application and keep narrative responses separate from executable arguments.

Basic Ember-1 call through LLMTR

curl "$LLMTR_BASE_URL/v1/chat/completions" \
  -H "Authorization: Bearer $LLMTR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"model":"fireworks/ember-1","messages":[{"role":"user","content":"Write a concise technical summary."}],"max_tokens":800}'

API limits to verify

Function calling, `tool_choice: "required"`, and a forced named tool are supported. `json_object` and strict `json_schema` are supported. Tool permissions come from a server-side allowlist; validate arguments with Zod or an equivalent schema.

Add human confirmation for payments, deletion, and access changes. Test wrong users, stale records, duplicate requests, and nonexistent tools. The application, rather than the model, makes the safe final decision.

  • Use model ID `fireworks/ember-1` and request surface `/v1/chat/completions`.
  • This model runs on third-party infrastructure; assess provider data policy for sensitive data.
  • Validate model output on the server before an application action.

Release decision and evidence

Run `moonshot/kimi-k3` as an alternative in every evaluation. LLMTR plans to retire the `fireworks/ember-1` identifier on 6 October 2026 at 00:00 Europe/Istanbul; this is not an absolute closure announced by Fireworks. For Tool calling and JSON Schema with Ember-1, record the test-set version, catalog capabilities, expected request shape, and unacceptable result. When a new provider response appears, preserve the example and reproduce the behavior. Collect failures, empty responses, and unexpected outputs as well as successes. A change should be measured for both user outcome and operating cost. Record minimum metadata such as request ID, model ID, latency, usage figures, and error class, without retaining prompt or response content by default. Decide in advance who may change thresholds and when rollback begins. Review results on a regular schedule rather than trusting one launch day. When the provider description changes, reread the source page and compare the catalog claim with a real request. This discipline does not hide preview uncertainty, but turns it into a product decision that can be reversed.

Design invalid tool tests alongside valid calls. Missing fields, extra fields, invalid currencies, and identifiers owned by another user are expected cases. Verify that the application rejects them before action and returns an understandable error.

Remove sensitive fields before returning a tool result to the model. A raw payment-provider response or internal access record can contain unnecessary information. Give the model only the state summary needed for its next language decision; keep the authority source in application data.

Use an idempotency key for timeout and double-click scenarios. The model can propose a tool again and a client can retry a connection. The key prevents the second call from becoming another charge or deletion; JSON shape does not provide that protection.

A human-confirmation screen should show the verified amount, target, and action summary from the application, rather than free-form model prose. Check authorization again after confirmation. This makes a tool proposal an auditable operation.

At the end of the Tool calling and JSON Schema with Ember-1 work, keep three concrete pieces of evidence: a summary of accepted and rejected examples, usage and latency measurements, and the reason for a rollback decision. This record avoids reopening the same debate at the next model update. The relevant product owner should read the results with the technical team, because a change that looks correct can affect user flow, support load, or cost budget differently. Document the condition under which the new behavior applies in short user-facing language. That keeps the catalog claim, application validation, and real operating result traceable without conflating them.

Frequently asked questions

Is required tool choice safe by itself?

No. It creates a tool call; the application decides who may perform an action.

Does a schema solve authorization?

No. It validates shape; authorization and business rules are separate.

Can I connect payments directly?

For irreversible actions add human confirmation, server policy, and idempotency.

Related posts