Continuous learning

Continuous learning is in private preview and disabled by default. The API and SDK surface here are stable enough to build against, but you must have it enabled for your organization. Contact support@tzafon.ai. Calls made without the flag return 403 feature_not_enabled.

Lightcone learns from your corrections. Because Lightcone is your inference endpoint, most of those corrections are already in your traffic. When a user pushes back mid-conversation (“use the §4.2 wording, the term is 24 months, not 12”), that reply is a training signal. Lightcone detects it, reviews it, and folds it into tonight’s model. One base_url change takes a static model to one that gets better at your work every day.

Metering is one number in two directions: forward 1 CU, backward 2 CU per 1,000 tokens.

1. Deploy a model

One command provisions capacity and returns an OpenAI-compatible endpoint, a key, and a compute-unit balance.

tzafon deploy lc-8b
  → provisioning capacity … done (2m 14s)
  → endpoint: https://api.tzafon.ai/v1
  → key: sk-…f2a4 · balance: 2,500,000 CU  (fwd 1 · bwd 2)

2. Point your client

It speaks the API you already use. Change base_url and keep the rest. SDKs, streaming, and tool calls all work unchanged.

from openai import OpenAI
import os

client = OpenAI(
    base_url="https://api.tzafon.ai/v1",
    api_key=os.environ["TZAFON_API_KEY"],
)

import OpenAI from "openai";

const client = new OpenAI({
  baseURL: "https://api.tzafon.ai/v1",
  apiKey: process.env.TZAFON_API_KEY,
});

3. It’s already learning

You don’t need a labeling pipeline or a training call. The corrective turns in your normal traffic are the signal. When a user replies to fix a response, Lightcone detects it automatically and queues it for tonight’s batch.

r = client.chat.completions.create(
    model="lc-8b",
    messages=[
        ...,
        {"role": "user",
         "content": "Use §4.2 wording, the term is 24 months, not 12."},
    ],
)
# that turn is the training signal, detected automatically
# queued → tonight's batch · 2 CU / 1k tok · same review queue, same eval gate

const r = await client.chat.completions.create({
  model: "lc-8b",
  messages: [
    ...,
    { role: "user",
      content: "Use §4.2 wording, the term is 24 months, not 12." },
  ],
});
// that turn is the training signal, detected automatically
// queued → tonight's batch · 2 CU / 1k tok · same review queue, same eval gate

Watch the queue in console → training. Turn capture off per key (training: off) or per request with a header:

r = client.chat.completions.create(
    model="lc-8b",
    messages=[...],
    extra_headers={"X-Lightcone-Training": "off"},
)

const r = await client.chat.completions.create(
  { model: "lc-8b", messages: [...] },
  { headers: { "X-Lightcone-Training": "off" } },
);

4. Precision teaching (optional)

For pipelines with ground truth, non-conversational workloads, or teaching after the fact, attach a correction explicitly. It lands in the same review queue, behind the same eval gate, and meters as backward passes.

client.corrections.create(
    completion_id=r.id,
    correction="Use §4.2 wording, the term is 24 months, not 12.",
)
# queued → tonight's batch · backward pass @ 2 CU / 1k tok
# tomorrow, lc-8b knows.

await client.corrections.create({
  completion_id: r.id,
  correction: "Use §4.2 wording, the term is 24 months, not 12.",
});
// queued → tonight's batch · backward pass @ 2 CU / 1k tok
// tomorrow, lc-8b knows.

For computer-use workflows, the same idea applies: a failed-run outcome or a human takeover is a correction. Submit it here and the model improves at that workflow specifically.

How it works

Corrections don’t touch the live model. Each night (02:00–02:45 UTC, on your capacity, serving uninterrupted) the queued corrections train a candidate checkpoint by on-policy self-distillation (our SDPO method, Self-Distilled Policy Optimization): the model learns from its own verified-successful behavior, distilling it against a moving average of its own recent weights, so it generalizes the lesson rather than memorizing one phrasing.

• Verified outcomes are the signal. No external labels or annotation pipeline. Only runs that pass their check are learned from.
• Stable by design. Anchoring each update to the model’s own recent self is intended to keep new lessons from regressing what it already did well. (A design goal, not yet a published measurement.)

The candidate is promoted only if it beats the incumbent on your evals. If a promotion ever regresses something, rollback is one call. The weights are a private, per-organization model. Your corrections never train the shared base model or any other customer’s.

Core concepts

Concept	What it means
Compute units (CU)	One meter, two directions: forward 1 CU, backward 2 CU per 1,000 tokens. The meter is the invoice, with no separate training bill.
Corrections	Plain language in, gradients out. Captured automatically from your conversations; the explicit API is for precision.
Checkpoints	Nightly candidates that promote only if they beat the incumbent on your evals. Rollback is one call.
Capacity	Shared pool while you serve base weights; dedicated nodes the moment your weights diverge from the base.

Manage checkpoints

status = client.learning.status()
print(status.current_checkpoint, status.cu_balance, status.queue_depth)

checkpoints = client.learning.checkpoints.list()
client.learning.checkpoints.rollback("ckpt_00006")   # instant revert

const status = await client.learning.status();
console.log(status.current_checkpoint, status.cu_balance, status.queue_depth);

const checkpoints = await client.learning.checkpoints.list();
await client.learning.checkpoints.rollback("ckpt_00006"); // instant revert

Each checkpoint carries the eval results it was promoted on. See the eval report in the console before promoting or rolling back.

Rate limits & batch window

• Nightly training runs 02:00–02:45 UTC on your capacity; serving is uninterrupted.
• Serving rate limit is per key: 600 req/min on shared capacity, unmetered on dedicated nodes.

Scope and guarantees

• Private, per-org weights. Learning updates a model scoped to your organization. Your corrections never train the shared base model or another organization’s model. See Security and data handling.
• Weight updates, not prompt-stuffing. Corrections change the weights, so the lesson generalizes and survives across sessions. It is not a rules file appended to the prompt.
• Gated by your evals. Every correction passes a review queue and an eval gate. A candidate promotes only if it beats the current model on your own evals.
• Reversible. Roll back to any prior checkpoint in one call.

API reference

All routes require the preview flag; bodies and errors follow the standard error model.

Method	Path	Description
POST	/corrections	Attach an explicit correction (completion_id, correction)
GET	/learning/status	Current checkpoint, CU balance, training queue depth, next batch time
GET	/learning/checkpoints	List checkpoints with their eval results
POST	/learning/checkpoints/{id}/rollback	Revert to a checkpoint

Per-request control: X-Lightcone-Training: off skips capturing that request. Per-key control: set training: off on the key in the console.

Next steps

• Pricing: how compute units meter forward and backward passes
• Wrap a legacy app in a REST API: where a failed run becomes a correction
• Security and data handling: how per-org weights and your data are isolated
• Chat Completions: the OpenAI-compatible surface you deploy onto