CentroSky API Reference

Base URL: https://centrosky.com/v1

CentroSky is an OpenAI-compatible AI infrastructure gateway. Applications use one API key and one stable contract while CentroSky handles routing, provider health, failover, request metering and execution telemetry.

The recommended route is auto. It is provider-independent. Historical model names remain accepted as compatibility aliases during the migration, but new integrations should use auto or an explicit supported model.


Authentication

http
Authorization: Bearer csky_your_key_here

Create and manage keys in the CentroSky Console. Do not expose a CentroSky key in client-side code.


Quickstart

cURL

bash
curl https://centrosky.com/v1/chat/completions \
  -H "Authorization: Bearer csky_your_key_here" \
  -H "Content-Type: application/json" \
  -d '{
    "model": "auto",
    "messages": [{"role":"user","content":"Explain database indexes briefly"}]
  }'

Python

python
from openai import OpenAI

client = OpenAI(
    api_key="csky_your_key_here",
    base_url="https://centrosky.com/v1",
)

response = client.chat.completions.create(
    model="auto",
    messages=[{"role":"user","content":"Explain database indexes briefly"}],
)
print(response.choices[0].message.content)

JavaScript

javascript
import OpenAI from "openai";

const client = new OpenAI({
  apiKey: "csky_your_key_here",
  baseURL: "https://centrosky.com/v1",
});

const response = await client.chat.completions.create({
  model: "auto",
  messages: [{ role: "user", content: "Explain database indexes briefly" }],
});

Routing

auto invokes CentroSky's health-aware smart router. The router can consider task shape, provider health, quota pressure, latency, cost and available capacity before execution.

Useful request hints include:

Field Type Purpose
reasoning boolean Prefer stronger multi-step reasoning routes
task string Workload hint such as code
model_prefer array Prefer matching backend identifiers
model_exclude array Exclude matching backend identifiers
agents integer or "auto" Explicitly enable multi-agent orchestration
candidates integer Request best-of-N execution where supported

The resolved backend is returned in CentroSky metadata rather than hidden from the developer.


Chat Completions

POST /v1/chat/completions

json
{
  "model": "auto",
  "messages": [
    {"role":"user","content":"Design a retry strategy for this API."}
  ],
  "max_tokens": 4096
}

CentroSky adds an extension block to compatible responses:

json
{
  "centrosky": {
    "model_tier": "auto",
    "model_actual": "resolved-backend-id",
    "provider": "resolved-provider",
    "routing_pool": "execution-profile",
    "spu_consumed": 0.42,
    "latency_ms": 843,
    "run_id": "..."
  }
}

OpenAI SDKs ignore unknown response fields, so the additional CentroSky metadata does not break normal SDK use.


Models

GET /v1/models

The public contract is capability-first:

Route Status Purpose
auto Recommended Provider-independent smart routing
flash Compatibility Low-latency legacy route
sp Compatibility Balanced legacy route
sp+ Compatibility Premium/orchestration legacy route

CentroSky can expose explicit provider/model choices in the developer console where useful, but applications do not need to hardcode upstream providers.

Audited model fleet

GET /v1/fleet returns the current audited capability pools for the authenticated account without consuming an inference request. The fleet is derived from verified provider/model routes, provider health, quota/concurrency state, route cooldowns and fresh capability evidence from real successful workloads or bounded operator audits.

Each capability reports live model and route counts, its redundancy target and whether the pool is healthy, degraded or unavailable. Counts intentionally describe verified/audited capacity, not every model a provider may advertise.

For substantive coding workloads, clients may send quality_floor: "reason" and allow_fast: false. CentroSky then prefers Code-class capacity and may fall back only to reasoning-class peers; it will not silently make a production coding request Fast. Capacity failures include safe rejection summaries such as cooldown, quota, provider health or missing verified routes.


SkyPower

SkyPower is CentroSky's execution meter. A request can consume different resources depending on its resolved model, routing path, search/tool use, orchestration and provider execution.

Use the response metadata and Console usage views to track consumption by API key and run.


Other current endpoints

Endpoint Method Purpose
/v1/models GET Available routing profiles
/v1/fleet GET Audited live capability pools and redundancy state
/v1/execution-profiles GET Auto/Web/Deep/Verify/Consensus workflows
/v1/responses POST Responses-style provider-independent execution
/v1/execute POST CentroSky-native execution workflows
/v1/account GET Plan, key allowance, RPM and account summary
/v1/requests GET Sanitized request/execution ledger
/v1/network/skypower GET Live capacity and SkyPower network snapshot
/v1/usage GET Ledger-backed usage analytics
/v1/keys GET List keys
/v1/keys/create POST Create a key
/v1/plans GET Commercial plans

Additional CentroSky-native intelligence endpoints will be documented as they are promoted from internal execution services into stable public contracts.


Compatibility note

Older CentroSky builds exposed SkyMind/Aeva model identifiers directly. Those identifiers remain accepted by the backend during the compatibility window so existing applications are not broken. They are no longer the public CentroSky product model. New integrations should use auto.

Nerddi SkyMind is the conversational application. CentroSky is the infrastructure service beneath applications.

CentroSky Execution Engine (9.0 Run 4)

CentroSky separates routing profiles from execution workflows.

GET /v1/execution-profiles lists auto, web, deep, verify, and consensus.

POST /v1/execute accepts:

The response includes answer, sources, verification, and meta. meta.trace describes execution stages without exposing proprietary router scoring weights.


Commercial developer platform — Run 5

Run 5 adds a stable customer-facing account and telemetry layer on top of the existing CentroSky ledgers. These endpoints never expose prompts, generated content, raw key material, provider credentials, or proprietary router scores.

Account

GET /v1/account

Returns the authenticated key, current plan, API-key allowance, effective RPM limit, current 30-day usage summary, and developer links.

bash
curl https://centrosky.com/v1/account \
  -H "Authorization: Bearer csky_your_key_here"

Read-only account/usage requests validate the key without incrementing its workload counter.

Request ledger

GET /v1/requests?limit=25&status=completed&profile=auto

Returns sanitized request records for the authenticated account: request ID, key label/prefix, requested profile, resolved model, status, token counts, SkyPower, latency, and normalized error code.

GET /v1/requests/{request_id} additionally returns sanitized routing attempts (provider type, success/fallback state, latency, token count and normalized error code). Prompt text, response text, provider key IDs and routing scores are not returned.

Usage analytics

GET /v1/usage?window=30d

Optional query parameters:

The response preserves the legacy subscription and key_stats objects and adds ledger-backed summary, by_profile, by_day, and rate_limit fields.

Responses-style API

POST /v1/responses

This is a provider-independent Responses-style facade over the CentroSky Execution Engine.

json
{
  "model": "auto",
  "input": "Compare these two deployment strategies.",
  "execution_mode": "deep",
  "web_search": "auto"
}

The response includes a standard-style output message plus a centrosky extension containing the execution mode, routing profile, resolved model list, SkyPower, latency, sources and verification metadata.

For existing OpenAI Chat Completions integrations, /v1/chat/completions remains the primary drop-in-compatible endpoint.

Current commercial plan contract

The application reads plan limits from centrosky_plans. The current seeded plan contract is:

Plan SkyPower RPM API keys Price
Free 60 SP/month, 12 SP/week, 10 SP+ Spark 10 1 Free
Starter 600 SP/month, 100 SP+ Spark 30 2 100 CENTRO/month
Pro 3,000 SP/month, 500 SP+ Surge 60 5 400 CENTRO/month
Business 12,000 SP/month, 2,000 SP+ Apex 120 10 1,200 CENTRO/month

The Console enforces the plan's max_keys when creating new API keys. Existing keys remain valid unless explicitly revoked.


Evidence integrity — Run 9

Evidence-bearing /v1/responses, /v1/execute, Nerddi bridge and evidence-first search responses now include a deterministic evidence-integrity audit. Independent model verification is still used when available, but a verifier outage no longer forces a generic confidence value.

verification may include:

Each returned source may also include quality_label, quality_score, freshness_label, freshness_score, stale, authoritative, and evidence_score. These values describe evidence quality; they do not expose proprietary router weights.

For live sports, weather, news and markets, stale evidence receives stronger penalties than it does for historical/general knowledge requests. Structured official/first-party live data receives the highest authority treatment.

Durable Jobs (coordinated upgrade)

CentroSky exposes a durable work ledger for long-running tasks. Jobs have a stable job_id, state, stage, progress percentage, bounded metadata, timestamps, and stage-event history.

The job ledger is intentionally separate from inference routing. Later tool/runtime stages can resume against the same job without changing the API identity of the work.

Last updated 12 Oct 2026 · Raw markdown