Flash API

Flash API guide

Approved customers use one HTTPS base endpoint and one stable product, Flash, with the bearer key delivered during direct onboarding. Build fast, low-latency integrations over an API that keeps prompt and response content out of application, billing, and log records.

Base endpointhttps://api.teralor.com/v1

Authentication

Send the assigned key as an HTTP bearer credential in the Authorization header. Treat it as a secret. Do not put it in URLs, source control, browser code, screenshots, or support messages.

Authorization: Bearer TERALO...

Public surface

Supported routes

GET/v1/models

List Flash

Returns Flash as the sole callable product with its current capabilities and limits. Treat this response as authoritative for access.

POST/v1/chat/completions

Create a Flash chat completion

Accepts authenticated non-streaming and streaming Flash chat requests.

Flash capabilities

Reasoning effort

The Flash record returned by GET /v1/models includes capabilities.reasoning when reasoning controls are available. Use only the listed reasoning_effort values; supported values, defaults, and disable support follow the active qualified implementation. Unsupported values are rejected before dispatch.

Request example

curl https://api.teralor.com/v1/chat/completions \
  -H "Authorization: Bearer TERALO..." \
  -H "Content-Type: application/json" \
  -d '{
    "model": "Flash",
    "messages": [
      {"role": "user", "content": "Summarize this text."}
    ],
    "max_tokens": 512,
    "stream": false
  }'

Set stream to true for a streaming response. Clients should handle interruptions and errors without automatically replaying a request whose dispatch status is uncertain.

Harness skill

Flash skill

Your AI leads. Flash executes.

Keep planning, decisions, and final review with your preferred assistant. Delegate bounded tasks to Flash, running independent work in parallel when your harness supports it. The executor and orchestrator setup guides configure your role and install this Flash skill; already-configured users can use it as a standalone skill from here. The coordinator can be Flash or another assistant.

Download skill

View skill instructions

---
name: flash-executor
description: Use when executing tasks with Teralor Flash, including independently verifiable coding, research, document and batch outcomes. Preserve the coordinator and use bounded, dependency-ready parallel work.
compatibility: Requires configured, authorized Flash access and supported harness tools. Concurrency requires verified account headroom and an actual concurrent dispatch mechanism.
metadata:
  author: Teralor
  version: "2.0.0"
---

# Flash

Keep the current coordinator model, whether Flash or another model. The coordinator owns decisions, contracts, scheduling and acceptance; Flash executes settled outcomes. Optimize verified completion, not worker count.

## Check readiness

Use the installed harness binding and verify nonsecret route/model evidence; a worker called Flash is not routing proof. If access, budgets or binding are missing, stop and use the harness-specific [Executor onboarding](https://teralor.com/executor) or [Orchestrator onboarding](https://teralor.com/orchestrator). This skill does not configure providers or switch the primary model. Keep credentials out of prompts and artifacts. Raw completions cannot execute tools; treat their proposed patches as unexecuted until the trusted harness validates and applies them.

## Decompose by verifiable outcome

Inspect the inputs and acceptance criteria. Settle shared interfaces first, then split only where each result can be checked independently: a module against a fixed interface, a document batch with distinct outputs, or a research question with its own sources. Keep dependent work queued. For a trivial or serial task, use one bounded execution; never manufacture sixteen tasks.

Maintain a compact ledger: task ID, dependencies, owner, artifact and state (`ready`, `running`, `produced`, `verified`, `failed`, `uncertain`, `blocked`). Only verified artifacts satisfy dependencies.

Give each worker this compact contract, not the full conversation:

- **Outcome:** task ID, observable result and expected artifact/count.
- **Inputs:** baseline, relevant paths/excerpts, settled interfaces and verified dependencies.
- **Ownership:** writable paths, isolated workspace, invariants, non-goals and permissions.
- **Acceptance:** runnable checks, return format, budgets and stop conditions.
- **Return:** actual artifacts/patch, changed paths, checks really run, failures and uncertainty.

For code, require a failing regression/reproducer before the fix where applicable and focused passing checks afterward. Workers must not recursively delegate, change global configuration, publish or broaden permissions.

## Run a replenishing queue

When the account allowance is verified as **16 concurrent requests**, dispatch up to that allowance—not sixteen workers unconditionally. Bound active requests by remaining account headroom, harness/tool limits, resource budget and independently ready work. Count other clients and the coordinator's own Flash requests. A worker can emit multiple requests; request capacity is not a worker entitlement. Unknown allowance: use at most one authorized request while resolving it; zero headroom: queue. Server admission remains authoritative.

Launch independent ready jobs together through supported asynchronous/batch tools, rather than awaiting each before starting the next. Consume completions, verify artifacts and replenish newly ready work without waiting for unrelated slow jobs. Use completion notifications or bounded waits; avoid duplicate submissions.

Concurrent writers require separate workspaces and explicit file ownership. Serialize shared interfaces, databases, ports and remote mutations. Without isolation, parallelize read-only proposals and keep one writer. Without concurrent tools, execute serially and say so.

## Verify, repair, integrate

Inspect actual bytes, scope, baseline compatibility and evidence; reconcile requested IDs against outputs for missing/duplicate items. Run combined integration checks after accepting individual artifacts. Never substitute worker confidence for results.

Repair only the failed slice, once, with concrete failure evidence; retain unaffected verified work. Authentication failure stops dispatch. Rate limits reduce pressure with bounded, safe retries. Interrupted or unknown dispatch stays uncertain until reconciled or confirmed cancelled—never assume its slot/workspace is free or replay blindly.

Report delivered artifacts, actual routing and observed concurrency, checks and remaining blockers. Claim neither parallel execution nor speedup without measured evidence.