Execution control plane for generative media

Authenticate, validate, rate limit, reserve credits, select providers, execute workloads, fail over, persist artifacts, and deliver results — all through one control plane.

Website · Docs · Playground · Status · Trust Center · npm

BabySea open source projects are organized into three categories:

Application developers
  │
  ▼
babysea SDK
  │
  ▼
BabySea execution control plane
  ├─ rosetta-bridge     request normalization
  ├─ adaptive-island    provider ranking
  ├─ execution-arrow    /v1/generate image/video execution (coming-soon)
  └─ ledger-fortress    credit settlement

SDK for users. Primitives for builders. Application developers use babysea. Infrastructure builders study or reuse the primitives.

Pinned repo order:

1. babysea - Production TypeScript SDK for the BabySea execution control plane for generative media. One API, one schema, one lifecycle across image and video inference providers..
2. adaptive-island - Cache-first provider selection engine for multi-provider inference workloads. Built with Databricks, Supabase, and Upstash.
3. execution-arrow - Coming-soon, /v1/generate image/video execution.
4. ledger-fortress - Atomic credit settlement engine for async inference workloads. Built with Stripe and Supabase.
5. rosetta-bridge - Request normalization engine for multi-provider inference workloads. Built with JSON Schema and TypeScript adapters.

1. What BabySea is
2. Why it exists
3. Platform scale
4. Execution model
5. Product surfaces
   • API
   • Image generation
   • Video generation
   • TypeScript SDK
   • Playground
6. Core capabilities
7. Why teams move from DIY to BabySea
8. Open source
9. Production pattern
10. Adaptive provider selection
11. Multi-region execution
12. Trust and operations
13. Example lifecycle
14. Installation
15. Quickstart
16. Repository standards
17. Philosophy
18. Connect

BabySea is the execution control plane for generative media.

Developers building image and video products usually integrate multiple inference providers directly. Each provider has a different API, schema, latency profile, failure mode, pricing model, output format, and lifecycle behavior.

At small scale, this is manageable.

At production scale, routing, retries, failover, billing, observability, lifecycle state, and artifact delivery become fragile infrastructure.

BabySea standardizes that execution layer.

Developers send workloads through one API. BabySea manages provider selection, failover, execution state, billing, observability, and artifact delivery across inference providers.

Over time, provider selection adapts from real execution outcomes, so the system becomes faster, cheaper, and more reliable as it processes more workloads.

Generative media does not break only at the model layer.

It breaks at the execution layer.

Teams need to answer operational questions that model APIs do not solve by themselves:

• Which provider should execute this model in this region right now?
• What happens when the preferred provider times out?
• How do retries, refunds, credit reservations, and final settlement stay consistent?
• How do we normalize outputs across providers?
• How do we track lifecycle state for async image and video jobs?
• How do we observe latency, cost, failures, and provider behavior?
• How do we keep execution reliable across regions?

BabySea turns fragmented provider behavior into a predictable execution system.

BabySea separates application intent from provider mechanics.

Developer application
  -> BabySea API
  -> Execution policy
  -> Provider selection
  -> Failover/retry/lifecycle control
  -> Artifact delivery
  -> Billing and observability

Applications express what they want to run.

BabySea handles how it should execute.

One normalized API for generative media execution.

curl --request POST \
  --url https://api.us.babysea.ai/v1/generate/image/bfl/flux-2-max \
  --header 'Authorization: Bearer BABYSEA_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
  "generation_prompt": "A baby seal plays in the Arctic",
  "generation_ratio": "1:1",
  "generation_output_format": "png",
  "generation_output_number": 1,
  "generation_resolution": "1MP",
  "generation_provider_order": "fastest"
}'

curl --request POST \
  --url https://api.us.babysea.ai/v1/generate/video/google/veo-3.1 \
  --header 'Authorization: Bearer BABYSEA_API_KEY' \
  --header 'Content-Type: application/json' \
  --data '{
  "generation_prompt": "A penguin swimming in the Antarctica",
  "generation_ratio": "16:9",
  "generation_output_format": "mp4",
  "generation_output_number": 1,
  "generation_duration": "",
  "generation_resolution": "720p",
  "generation_generate_audio": false,
  "generation_provider_order": "fastest"
}'

npm install babysea

import { BabySea } from "babysea";

const client = new BabySea({
  apiKey: process.env.BABYSEA_API_KEY!,
  region: "us",
});

async function generate() {
  const result = await client.generate("bytedance/seedream-5-lite", {
    generation_prompt: "An astronaut walking on the Moon",
    generation_ratio: "16:9",
    generation_output_format: "png",
    generation_output_number: 1,
    generation_provider_order: "fastest",
  });

  return result.data.generation_id;
}

Try BabySea directly from the browser.

https://us.babysea.ai/playground

Change us to eu or jp depending on your region.

The playground supports:

• API key based execution
• Region selection
• Model selection
• Schema-driven inputs
• Generated cURL
• Response inspection
• Latency visibility
• Generation lifecycle actions: get, cancel, delete

We open-source production-derived infrastructure patterns from BabySea.

The goal is not to publish toy examples. The goal is to make reusable system boundaries available to teams building serious AI infrastructure.

For the full cross-repo narrative, see ARCHITECTURE.md.

BabySea's production architecture is built around one principle:

Adaptive intelligence should improve execution, never become a hard dependency on the request path.

A simplified execution loop:

Provider attempt records
  -> Regional operational database
  -> Governed analytics and ranking layer
  -> Provider ranking artifact
  -> Low-latency cache
  -> API execution path

The API reads routing decisions quickly, but remains fail-open.

If the adaptive layer is unavailable, execution falls back to deterministic provider order and normal failover behavior.

Customer traffic is never hostage to the intelligence layer.

generation_provider_order: "fastest" is the customer-facing abstraction over BabySea's adaptive routing loop.

Developers do not need to manually choose a provider for every request. BabySea can resolve the concrete provider at execution time based on real workload behavior.

Example:

{
  "generation_provider_order": "fastest"
}

A completed generation may then expose the provider actually used:

{
  "model_identifier": "bytedance/seedream-3",
  "generation_provider_order": ["fastest"],
  "generation_provider_used": "byteplus",
  "generation_status": "succeeded",
  "generation_metrics_total_time": 4.965
}

The request stays simple.

The execution layer handles provider selection.

BabySea runs across three regional execution domains:

Region is not just deployment geography.

For generative media, provider availability, latency, reliability, pricing, and compliance requirements can vary by region. BabySea treats region as part of the execution decision.

BabySea is designed as production infrastructure.

Operational surfaces include:

• Public status page
• Trust Center
• Regional execution endpoints
• API key authentication
• Request IDs
• Structured errors
• Webhook signing
• Rate limiting
• WAF and edge protection
• Observability through Sentry and PostHog
• Billing through Stripe
• Data and operational storage through Supabase
• Low-latency cache and rate limiting through Upstash

Links:

• Trust Center
• Status
• Documentation

A typical image or video execution follows this lifecycle:

1. Developer sends generation request
2. BabySea validates schema and account access
3. Credits are reserved
4. Provider order is resolved
5. Workload is submitted to an inference provider
6. BabySea tracks provider attempt state
7. Failover occurs if needed
8. Output artifact is persisted
9. Credits are charged, refunded, or adjusted
10. Final content state is available through API and webhooks

This lifecycle is why BabySea is more than a model API.

It is the system of record for generative media execution.

npm install babysea

import { BabySea } from 'babysea';

const client = new BabySea({
  apiKey: process.env.BABYSEA_API_KEY!,
  region: 'us',
});

const generation = await client.generate('bfl/flux-schnell', {
  generation_prompt: 'A cinematic photo of a baby seal on Arctic ice',
  generation_provider_order: 'fastest',
});

console.log(generation.data.generation_id);

Retrieve the result:

const content = await client.getGeneration(generation.data.generation_id);

console.log(content.data.generation_status);
console.log(content.data.generation_output_file);

Or use the convenience helper for scripts and demos:

const completed = await client.generateAndWait('bfl/flux-schnell', {
  generation_prompt: 'A cinematic photo of a baby seal on Arctic ice',
  generation_provider_order: 'fastest',
});

console.log(completed.data.generation_output_file);

Full quickstart:

https://docs.babysea.ai/quickstart

BabySea open-source repositories are maintained with production-grade expectations:

• Typed public interfaces
• Clear setup instructions
• Environment variable examples
• End-to-end or integration test guidance where applicable
• CI-ready structure
• License included
• Security notes for production use
• No production secrets, customer data, or private workload data

Each repository exposes a reusable pattern from BabySea's infrastructure without exposing the proprietary workload data, customer graph, or production tuning that compounds inside the platform.

The pattern is reusable.

The workload data is not.

BabySea open-sources infrastructure patterns because the ecosystem benefits from better execution primitives.

The moat is not knowing that routing, failover, billing, observability, or adaptive selection should exist.

The moat is the compounding workload graph flowing through the production system.

• Website: babysea.ai
• Documentation: docs.babysea.ai
• Playground: us.babysea.ai/playground
• Trust Center: trust.babysea.ai
• Status: status.babysea.ai
• npm: babysea
• Email: dev@babysea.ai