Optimization

Because every inference and feedback signal is already in Postgres, the LLM Service Daemon (LSD) can launch optimization jobs directly against that data, with no export/import step to a separate platform.

Launching a job

curl -X POST http://localhost:3000/experimental_optimization_workflow \
  -H "Content-Type: application/json" \
  -d '{"function_name": "my_function", "optimizer_config": {"type": "openai_sft", ...}}'

The response includes a job handle. Poll it with:

curl http://localhost:3000/experimental_optimization/{job_handle}

GEPA jobs use a dedicated pair of endpoints instead: POST /v1/optimization/gepa to launch, GET /v1/optimization/gepa/{task_id} to poll.

Available strategies

type	What it does
dicl	Dynamic in-context learning: embeds past examples and selects the most relevant ones to inject as few-shot context at inference time, instead of retraining a model
openai_sft	Supervised fine-tuning via OpenAI’s fine-tuning API
openai_rft	Reinforcement fine-tuning via OpenAI’s training API
fireworks_sft	Supervised fine-tuning via Fireworks
together_sft	Supervised fine-tuning via Together AI
gcp_vertex_gemini_sft	Supervised fine-tuning of Gemini models via GCP Vertex AI
gepa	Evolves prompts/configuration through mutation, evaluation, and Pareto-based selection across generations

Each strategy reads its training examples from the inferences and feedback already stored for a given function, so the dataset is whatever you’ve already sent through the gateway (optionally filtered into a named dataset; see /v1/datasets).

Where state lives

Job configuration and progress are stored in the optimizers_configs table; DICL examples are stored in dicl_examples. There’s nothing to keep in sync outside Postgres.