MetaCaster: Meta-Learning Agents Train Lightweight Forecasters in Minutes Instead of Hours

MetaCaster, a new meta-learning system, enables agents to train lightweight time-series forecasters in minutes using few-shot examples and textual context, avoiding the high cost of foundation model API calls. The system uses a meta-agent to orchestrate data generation, architecture selection, and training, producing deployable models that run inference without further foundation layer access. It includes a model registry for caching and versioning, and addresses challenges like overfitting and low data diversity.

Foundation models are expensive. A trading agent that calls GPT-4 for every price prediction burns budget fast. Lightweight forecasters are cheap to run but expensive to train, especially when you only have a handful of examples. MetaCaster introduces a meta-harness architecture where agents don't forecast directly. Instead, they train specialized lightweight models on-demand from few-shot examples and textual context. This is not another AutoML wrapper. The meta-agent orchestrates data generation, architecture selection, and training loops to produce task-specific forecasters in minutes. The result is a deployable model that runs inference without touching the foundation layer again. Time-series forecasting in production faces a resource trap: MetaCaster targets the intersection: resource-constrained environments where you need specialized models but can't afford foundation API calls or long training cycles. The system has three layers: The top-level agent receives a few-shot time series as few as 5-10 examples and optional textual context domain descriptions, seasonality hints . It decides: The meta-agent uses a learned policy, not heuristics. It's pre-trained on a meta-dataset of diverse forecasting tasks so it generalizes to new domains. These agents expand the few-shot examples into a trainable dataset. Strategies include: The generated data is not generic. It's tuned to the target task's distribution based on the meta-agent's analysis of the few-shot examples. The meta-harness spawns a training job with the selected architecture and synthetic dataset. This is a standard supervised loop, but the harness monitors: Once trained, the lightweight model is serialized and cached. The meta-agent never touches it again unless the task distribution shifts. The critical design choice is where the meta-agent stops and the forecaster starts. MetaCaster uses a clean separation: This boundary matters for versioning and reproducibility. You can snapshot the trained forecaster and deploy it independently. The meta-agent is only needed when you want to train a new model or retrain an existing one. MetaCaster includes a model registry that hashes: If an agent requests a forecaster for a task it's seen before, the system returns the cached model instead of retraining. This is crucial for production systems where multiple agents might request forecasters for overlapping tasks e.g., different trading strategies on the same asset . The registry also tracks: The meta-agent can overfit during harness optimization if it tunes too aggressively to the validation set. The paper mitigates this with: In practice, you'll see this as high variance in forecaster performance across similar tasks. The fix is to expand the meta-training dataset or add noise to the meta-agent's policy. If the data generation agents produce low-diversity samples, the forecaster learns a narrow distribution. Symptoms: The meta-harness monitors synthetic data statistics entropy, autocorrelation, spectral density and rejects degenerate datasets before training starts. The meta-agent might select an architecture poorly suited to the task. For example: MetaCaster uses a learned architecture selector, but you can override it with domain-specific rules. The paper shows that hybrid policies learned + rule-based outperform pure learned policies in specialized domains like finance. Here's a simplified training harness in Python: python class MetaCasterHarness: def init self, meta agent, model registry : self.meta agent = meta agent self.registry = model registry def train forecaster self, few shot examples, context text : Check cache first task hash = self. hash task few shot examples, context text cached = self.registry.get task hash if cached and not cached.needs retrain : return cached Meta-agent decides architecture and data strategy plan = self.meta agent.plan few shot examples, context text Generate synthetic training data synthetic data = self. generate data few shot examples, plan.data strategy Instantiate lightweight forecaster model = self. build model plan.architecture, plan.hyperparams Train with early stopping trained model = self. train model, synthetic data, validation=few shot examples, max time=plan.time budget Cache and return self.registry.store task hash, trained model, plan return trained model def train self, model, data, validation, max time : optimizer = torch.optim.Adam model.parameters best loss = float 'inf' patience = 0 start = time.time for epoch in range 1000 : if time.time - start max time: break train loss = self. train epoch model, data, optimizer val loss = self. validate model, validation if val loss < best loss: best loss = val loss patience = 0 else: patience += 1 if patience 10: break return model The key is that meta agent.plan is a learned policy, not a fixed heuristic. It's trained on a meta-dataset of diverse forecasting tasks using policy gradient methods. | Approach | Training Time | Inference Cost | Data Requirement | Adaptability | |---|---|---|---|---| | Foundation Model TimeGPT | None | High $0.002-0.02/call | Zero-shot | High | | Lightweight from Scratch | Hours | Low | Thousands of samples | Low | | AutoML AutoGluon-TS | Minutes to hours | Low | Hundreds of samples | Medium | | MetaCaster | Minutes | Low | 5-10 samples | High | MetaCaster trades meta-training cost one-time, offline for fast task-specific training online, per-task . AutoML systems like AutoGluon-TS search over hyperparameters but don't generate synthetic data or use learned architecture selectors. Production deployments need visibility into: The paper doesn't specify an observability layer, but you'd want structured logs and metrics that feed into a monitoring dashboard. Key alerts: MetaCaster is not a single service. It's a pipeline: You can scale each component independently. The meta-agent and inference services are CPU-bound. Training workers need GPUs but only for minutes per task. The registry is the only stateful component and can use object storage S3, GCS with a metadata database. Use MetaCaster when: Avoid MetaCaster when: The sweet spot is resource-constrained environments with recurring but varied forecasting tasks: trading systems, supply chain optimization, energy grid management, and personalized health monitoring.