Podar
§01Podar Foundry

Don't just buy the cheapest model. Manufacture it.

Route first. Observe repetition. Distill the repetitive work. Route to the distilled model. Escalate failures. Retrain continuously. That turns Podar from a model router into a self-improving AI cost-reduction system.

§02Two engines

The Exchange buys intelligence efficiently. The Foundry manufactures it more efficiently.

Podar Exchange

Routes each request to the best existing supply source — trimmed, cached, scored, and priced against every major gateway in real time.

See the pipeline →
Podar Foundry

Creates new, smaller supply when a recurring workload justifies it — a growing portfolio of tiny, task-specific models that become new destinations inside the router.

MicroModels →

Podar stops asking only “which existing model is cheapest?” and starts asking “has Podar seen enough of this task to manufacture a cheaper specialist?” Podar will not attempt to distill a general-purpose mini model — it distills tasks, not intelligence.

§03Architecture

Where a MicroModel sits.

Enterprise request
        |
Prompt trimming and normalization
        |
Semantic cache
        |
Podar task classifier
        |
+----------------------------------------------+
|  Can a Podar MicroModel handle this safely?  |
+----------------------------------------------+
   | Yes                          | No
Podar MicroModel          Cheapest external model
   |                              |
Confidence and quality check      |
   | Failed                       | Failed
   +-----------> Frontier model fallback

The classifier decides whether a certified MicroModel can handle the request safely. If it can, the MicroModel answers and a confidence and quality check gates the response. Anything uncertain — from either path — falls back to a frontier model.

§04The portfolio

A growing shelf of narrow specialists.

Podar-Extract

Field-level extraction from documents and prose

Podar-Classify

Intent, topic, and priority classification

Podar-Summarize

Short, domain-specific summarization

Podar-JSON

Prose-to-schema transformation and JSON repair

Podar-SQL

Text-to-SQL against a stable schema

Podar-PolicyMatch

Matching a request to the governing internal policy

Podar-SupportReply

Standard customer-service responses

Podar-Acme-Invoice

Customer-specific models, isolated by tenant

These models are only hundreds of millions to a few billion parameters. Open small-model families already ship at 135M, 360M, and 1.7B parameters, and Google has demonstrated task-specific QLoRA fine-tuning of a 1B-parameter Gemma model on a single T4 GPU.

§05The critical distinction

Distill tasks, not intelligence.

A tiny model does not inherit the reasoning, world knowledge, and versatility of a frontier model. It does not need to be broadly intelligent — it needs to be certifiably good enough for one task family. Research on distilling step-by-step has shown that smaller task-specific models can sometimes outperform much larger prompted models when trained on answers and reasoning-derived supervision.

Distillation suitability by task type
TaskDistillation suitability
Intent classificationExcellent
Entity extractionExcellent
Convert prose to JSONExcellent
Invoice or document categorizationExcellent
Redaction and PII identificationExcellent
Standard customer-service answersStrong
Policy matchingStrong
Short domain-specific summarizationStrong
Text-to-SQL for a stable schemaStrong
Open-ended strategyPoor
Complex multidisciplinary reasoningPoor
Novel legal or medical judgmentsPoor
Long-horizon autonomous agentsPoor
Current-events answers without retrievalPoor
§06The flywheel

Eight steps, on repeat.

Podar has something model labs generally do not: visibility into which expensive requests keep getting sent to frontier models unnecessarily. That telemetry is what creates specialists.

  1. 01

    Observe

    Every request leaves a record: the original prompt, the trimmed prompt, the model selected, the cost incurred, whether it passed evaluation, whether it escalated, which cheaper models failed, and why they failed.

  2. 02

    Cluster

    High-volume, high-cost task families surface on their own. “This customer sends 600,000 requests a month asking an expensive model to extract ten fields from insurance documents.”

  3. 03

    Build a teacher dataset

    A permitted teacher model, customer-approved outputs, and human-reviewed examples generate high-quality training pairs — each one carrying data lineage.

  4. 04

    Fine-tune an open base

    Podar starts from an existing open-weight model and applies supervised fine-tuning, LoRA, or QLoRA. It does not pretrain from zero.

  5. 05

    Shadow-test

    The candidate runs silently alongside the production route and is compared on accuracy, format compliance, hallucination rate, latency, cost, human acceptance, and failure categories.

  6. 06

    Certify

    Activation waits on a customer-defined quality threshold — for example at least 99.5% structured-field accuracy, with 100% escalation whenever confidence falls below the approved boundary.

  7. 07

    Route

    The MicroModel becomes the first destination for that task family, ahead of any external model.

  8. 08

    Escalate and learn

    Every uncertain or failed request climbs to a stronger model, and those failures become the next training curriculum.

§07When to build one

A Distillation Opportunity Score, calculated automatically.

Opportunity

Volume × Cost Spread × Task Stability × Evaluability × Expected Success Rate

Break-even requests

(training + evaluation + deployment cost) ÷ (current cost per request − MicroModel cost per request)

  • The task occurs frequently.
  • Inputs and outputs are reasonably consistent.
  • Correctness can be measured.
  • The workload is likely to continue.
  • A tiny model would be materially cheaper.
  • Training and maintenance cost can be amortized.
  • Podar has clear rights to use the data.
Distillation opportunity detected
Current annual cost
$480,000
Projected MicroModel cost
$42,000
Estimated implementation cost
$18,000
Projected first-year gross savings
$420,000
Quality target
99.2%
Frontier fallback rate
3.8%

Illustrative — single workload, single tenant

§08Three types of model

Universal, industry, private.

Universal MicroModels

Trained from properly licensed, non-confidential data and used to improve Podar's own platform economics.

  • · Prompt classifier
  • · Complexity estimator
  • · PII detector
  • · JSON repair model
  • · Prompt compressor
  • · Output quality judge

Industry MicroModels

Shared across consenting customers inside a single vertical, and a proprietary asset over time.

  • · Insurance-document extraction
  • · Ecommerce product normalization
  • · Hospitality-review categorization
  • · Banking-policy matching

Private customer models

Trained on one enterprise's workflow and data, running in dedicated infrastructure or the customer's own cloud.

  • · A bank's internal policy assistant
  • · A retailer's catalogue classifier
  • · A software company's support-response model
§09Teacher rights

Distillation with the paperwork done first.

Podar cannot casually train commercial models on the outputs of every proprietary frontier model. OpenAI's services agreement generally prohibits using its outputs to develop competing models, with limited exceptions, and Google's Gemini API terms similarly prohibit developing competing models or replicating the service. So Podar operates a teacher-rights policy.

  1. 01Use open-weight models whose licenses permit the intended training and commercial use.
  2. 02Use customer-owned labeled data.
  3. 03Use human-reviewed production outcomes.
  4. 04Negotiate explicit distillation rights with model providers.
  5. 05Use provider-hosted fine-tuning where external distillation is prohibited.
  6. 06Maintain data lineage for every training example.
§10The moat

Routing commoditizes. A closed-loop dataset does not.

Gateways, clouds, and model providers can all build a better router. What is far harder to copy is a closed loop connecting task characteristics, prompt construction, model selection, actual quality, actual cost, escalation behavior, distillation performance, and model degradation over time.

Stage 1

Optimize existing supply

Routing, trimming, caching, evaluation, and cost attribution come first. Podar needs production traffic before it knows what should be distilled.

Stage 2

Launch Podar MicroModels

Five extremely measurable workloads to begin: classification, structured extraction, JSON transformation and repair, PII detection, and short-form summarization. Never open-ended conversation.

Stage 3

Build the Podar Model Foundry

Automate task clustering, dataset construction, candidate-model selection, fine-tuning, evaluation, quantization, shadow deployment, router integration, drift detection, and retraining.

Stage 4

Distillation-routing co-optimization

The router and the models learn together: expand allocation where a MicroModel wins, train on the clusters where it loses, shrink allocation when the task shifts, and retire it when an external model is genuinely cheaper.

Podar remains economically neutral — even toward its own models. If an external model becomes cheaper than Podar's own inference cost, traffic moves there.

§11Questions

Foundry — frequently asked.

What is the Podar Foundry?
The Podar Foundry is the engine that manufactures new AI supply. Where the Podar Exchange routes each request to the best existing model, the Foundry observes recurring workloads, distills them into tiny task-specific MicroModels, certifies them against a customer-defined quality bar, and adds them to the router as new destinations.
Will Podar build a general-purpose mini model?
No. Podar distills tasks, not intelligence. A tiny model will not inherit the reasoning, world knowledge, and versatility of a frontier model, but it can become extremely good at one narrow and measurable task family.
When does Podar decide to create a MicroModel?
Podar computes a Distillation Opportunity Score from volume, cost spread, task stability, evaluability, and expected success rate, then divides training, evaluation, and deployment cost by the per-request saving to get a break-even request count. A model is only built when that break-even is comfortably inside the workload's expected life.
How large are Podar MicroModels?
Typically a few hundred million to a few billion parameters, depending on the task. Open small-model families already ship at sizes such as 135M, 360M, and 1.7B parameters, and Google has demonstrated task-specific QLoRA fine-tuning of a 1B-parameter Gemma model on a single T4 GPU.
How is customer data kept separate?
Customer-specific MicroModels are isolated by tenant by default. One client's proprietary data is never mixed into another client's model without explicit permission, and every training example carries data lineage.
What happens when a MicroModel gets something wrong?
Confidence and quality checks sit between the MicroModel and your application. Anything below the approved boundary escalates to a stronger model, and the failure is added to the next training curriculum.

Stop paying for AI overspend that buys you nothing.

A free assessment reads two weeks of your AI traffic and returns your current AI Yield and the dollar value of the waste we can remove.

Request a free assessmenthello@podar.ai