Flynn Service Terms

These Flynn Service Terms ("Flynn Terms") apply to your use of Flynn, the AI inference API provided by Digital Frontier Unipessoal LDA ("Digital Frontier," "we," "us," or "our"). They supplement our Terms of Service (the "Terms") and are incorporated into them.

1. Scope and Order of Precedence

1. The Terms, the Acceptable Use Policy and the Privacy Policy apply to Flynn. These Flynn Terms add the rules that are specific to Flynn. They do not repeat the Terms.
2. If these Flynn Terms conflict with the Terms on a matter specific to Flynn, these Flynn Terms prevail for Flynn. On every other matter, the Terms prevail.
3. Words with an initial capital that are not defined here have the meaning given in the Terms. For Flynn, "Customer Data" in the Terms includes your Inputs and Outputs (section 3).

2. The Service

1. Flynn is an API at api.flynn.digitalfrontier.so. It accepts requests in the OpenAI-compatible format (POST /v1/chat/completions) and the Anthropic-compatible format (POST /v1/messages and POST /v1/messages/count_tokens) and returns text generated by large language models. GET /v1/models lists the models available to your API key. The web console at flynn.digitalfrontier.so is where you manage keys, usage and billing.
2. Flynn offers two kinds of model:
   • Self-hosted models: model servers that Digital Frontier runs itself on compute capacity on the Akash Network. In GET /v1/models, these carry the tag self-hosted or akash in .flynn.tags.
   • Third-party models: models served by an external provider that Digital Frontier calls on your behalf. The providers are currently OpenRouter (tag openrouter) and NVIDIA, through its NIM API (tag nim).
3. Which model serves a request depends on the model you send:
   • flynn, a flynn- router version, or no model: the Flynn router chooses a model from self-hosted models only, including for any fallback. If no self-hosted model is available, the request is refused (HTTP 503). It is not sent to a third-party provider. On the Anthropic-compatible endpoint, a model name beginning claude- is served the same way.
   • A specific model id: only that model serves the request. If it cannot serve it, you receive an error. Flynn does not substitute another model.
   • auto, default, any or none: Flynn chooses among all models, self-hosted and third-party. If the chosen model fails, Flynn may retry the request on up to two other models, which may be third-party models.
4. Each response carries an X-Flynn-Worker header naming the model that served it.
5. The capacity behind self-hosted models is described by section 7.3 of the Terms. Where that capacity is not on Digital Frontier Provider Nodes, Digital Frontier does not guarantee its data residency.

3. Your Inputs and Outputs

1. "Inputs" means what you send to Flynn: prompts, messages, system prompts, tool definitions and any files. "Outputs" means the content Flynn returns to you.
2. You keep all rights in your Inputs. As between you and Digital Frontier, you own the Outputs, and Digital Frontier assigns to you any rights it may have in them. Section 7.1 of the Terms applies to both.
3. You must have the rights and, where personal data is involved, a lawful basis needed to send your Inputs to Flynn and to have them processed as described in section 4. You are responsible for complying with any licence or usage policy that applies to a model you choose.
4. Outputs are produced automatically by machine-learning models. They may be inaccurate, incomplete, out of date or offensive, and other customers may receive the same or similar Outputs. Digital Frontier gives no warranty that any Output is accurate, fit for a particular purpose or free of third-party rights.
5. You are responsible for how you use Outputs, including reviewing them before you rely on them and before you use them in decisions that affect people.

4. How We Handle Prompts and Outputs

4.1 What is recorded for every request

For every request, Flynn records: your account and API key, the time, the model requested and the model that served it, the routing decision, token counts, the amount charged, latency, an error class if the request failed, and a quality score that Flynn computes automatically from the response when it is served. This record is kept in both retention modes.

4.2 Retention modes

Each account has one of two retention modes.

• Standard (the default). In addition to section 4.1, Flynn stores the messages of your request, the response text (up to its first 60,000 characters), hashes of the request and the response, and your request parameters. A daily job deletes the stored request (including its messages) and the response text once they are more than 180 days old. The record in section 4.1 and the hashes are kept.
• No-store. Flynn does not store your messages, the response text, hashes of either, or a conversation key derived from your prompt. Only the record in section 4.1 and your request parameters are kept, marked as not retained. Requests are metered and charged exactly as in standard mode. The Batch API (section 4.6) is not available in this mode.

How the mode is set:

1. The mode is set per account by Digital Frontier at your written request to support@digitalfrontier.so. It cannot be changed from the console or the API.
2. Switching to no-store does not delete content already stored. We therefore enable no-store only for an account that has no stored prompts or outputs and no active API keys, which in practice means before its first key is issued.
3. When we enable no-store, we issue that account's keys as self-hosted-only keys (section 4.4), because third-party providers apply their own retention to what they receive.
4. We switch an account from no-store back to standard only on your written instruction.
5. No-store governs what Flynn stores in its own records. It does not yet cover request logging on the self-hosted model servers.

4.3 Third-party providers

1. When a request is served by a third-party model (section 2.3), Digital Frontier sends your Inputs to that provider and receives the Outputs from it. The provider processes them under its own terms and its own data-retention practices, which Digital Frontier does not control.
2. Third-party providers are not part of the Digital Frontier infrastructure described in section 1 of the Terms, and the data-residency statement in section 7.3 of the Terms does not apply to them.
3. Sending your Inputs to a provider in this way is part of providing the service you requested and is not an access to Customer Data under section 7.2 of the Terms.
4. If you do not want any request sent to a third-party provider, use the flynn router or a self-hosted model id, do not send auto, default, any or none, or ask for self-hosted-only keys (section 4.4).

4.4 Self-hosted-only keys

On request to support, Digital Frontier can issue API keys that may only use self-hosted models. With such a key, every request, including automatic routing and fallback, is served by a self-hosted model, and a request that names a third-party model is refused (HTTP 403). This setting is applied by Digital Frontier and cannot be set from the console.

4.5 Use of requests to improve Flynn

1. Flynn's router learns which model to choose from the record in section 4.1: the routing decision, the model that served, the outcome, latency, cost and the automatic quality score. Only the score is stored, not the text it was computed from.
2. For accounts in standard mode, Digital Frontier may also use stored messages and response text to improve Flynn, including to compute embeddings of prompts for routing and to build datasets for training models that serve Flynn.
3. For accounts in no-store mode, requests are not used to update the router, and are never embedded or included in a training dataset. This also applies to content stored before an account switched to no-store.

4.6 Batch files

Where the Batch API (/v1/files, /v1/batches and /v1/messages/batches) is available to your account, uploaded files are kept for 30 days from upload. A batch and its results are kept for 30 days after the batch ends. Both are then deleted.

5. Acceptable Use

The Acceptable Use Policy applies to Flynn, including to your Inputs and to how you use Outputs. In addition, you must not:

• attempt to access, infer or extract another customer's Inputs, Outputs, API keys or account data;
• circumvent or attempt to circumvent rate limits, token limits, spending caps or credit requirements, including by using additional accounts to exceed the limits set for your account;
• attempt to obtain service from a third-party provider through Flynn in a way that breaches that provider's usage policies;
• share your API keys outside your organisation. You are responsible for all use of your keys.

Digital Frontier may revoke API keys, refuse requests or suspend access to Flynn under section 13 of the Terms and section 6 of the Acceptable Use Policy.

6. Pricing, Prepaid Credit and Caps

6.1 Pricing

1. Flynn is charged per token, in US dollars, with input and output tokens priced separately per one million tokens.
2. Each model's list price is the pricing object on that model in GET /v1/models (pricing.prompt for input, pricing.completion for output), and is shown on the console's Models page. The price charged for a request is the list price of the model that served it, in effect when it was served. A model listed without a pricing object is charged at Digital Frontier's provider cost plus a margin.
3. Failed requests are not charged.

6.2 Prepaid credit

1. Flynn is prepaid. You add credit to your account in advance, and the charge for each request is deducted from your credit balance.
2. You add credit by top-up from the console where top-ups are offered (between 5 and 500 US dollars per top-up), or otherwise by contacting support@digitalfrontier.so, including by bank transfer quoting the payment reference shown on your Billing page. Credit counts towards your balance once the payment is confirmed.
3. Your balance, your deposits and your daily spend are shown on the console's Billing page.
4. Digital Frontier may refuse requests when your credit balance cannot cover them. Charges that take your balance below zero remain payable.
5. Refunds are governed by section 15.7 of the Terms. You may request a refund of unused credit from support.

6.3 Limits and caps

1. Your account has a requests-per-minute limit and may have a tokens-per-minute limit, a monthly token cap and a monthly spending cap. Your current values are in limits on GET /api/v1/me and GET /v1/usage. When you create an API key, you may give it a lower requests-per-minute limit or monthly spending cap than your account's, but not a higher one.
2. A request refused by a limit receives HTTP 429 with a machine-readable reason:

reason	Limit	Resets
rpm_window	requests per minute	at the next minute
tpm_window	tokens per minute	at the next minute
monthly_token_cap	monthly tokens	at the start of the next calendar month (UTC)
monthly_cost_cap	monthly spending	at the start of the next calendar month (UTC)

3. The monthly caps are checked before each request against usage already recorded. A request admitted before a cap is reached is charged in full, so your spending in a month can exceed your cap by the requests that were in progress when it was reached.
4. Sections 15.1 (taxes) and 15.4 to 15.5 (invoicing and non-payment) of the Terms apply to Flynn.

7. Availability and Changes

1. No service-level agreement or service credits apply to Flynn unless agreed in writing. Section 6 of the Terms applies. Flynn depends on third-party providers and on compute capacity on the Akash Network, and requests may be refused when that capacity or a shared provider budget is unavailable.
2. Models may be added, changed or withdrawn, including when a provider stops serving a model. A withdrawn model is no longer listed in GET /v1/models, and a request that names it receives an error.
3. Flynn follows the OpenAI and Anthropic request formats. The Flynn compatibility promise lists what stays stable. Removing or renaming anything it lists as stable, or changing what an existing error reason means, gets 90 days' notice, announced in the Flynn API changelog with the date it takes effect. A fix for a security problem may ship with less notice. Changes to these Flynn Terms are governed by section 21 of the Terms.

8. Support and Contact

For Flynn support, including retention-mode changes, self-hosted-only keys, credit and refunds, contact support@digitalfrontier.so. Legal notices and the contact details for competent authorities are in section 23 of the Terms. To report illegal content, use the report form.