You never pick a model.
Every job in the Jinn suite is routed to the class of model it needs - fast and small for high-volume work, frontier only where the work demands it. The table that decides is one file, kept current as vendors ship new families, so you never have to figure it out, keep up, or experiment.
Model classes, never model names: what you read here is durable across every new model launch, because the routing rules are written in classes, not vendor ids.
What it is
Every job in the suite is routed to the class of model it needs. Fast, small models for high-volume work; frontier models only where the work genuinely demands one. You never choose.
How it decides
One routing table maps each job to a model class by plan tier. It is a single file, kept current as vendors ship new families, so the whole suite updates at once.
What it protects
Cost-critical paths are pinned to small models by rule. A premium plan buys more samples and more engines there, never a bigger model where the budget cannot hold one.
Which model does which job
Each job is mapped to a model class, not a vendor’s model name, so the rule survives every new model launch. These are the jobs you will meet most; the table holds more for work inside individual products.
- monitoring
- Fast, small models. Frontier models are forbidden on this path - run constantly, at scale, they break the cost ceiling immediately. A premium plan buys more samples and more engines, never a bigger monitoring model.
- fidelity
- Mid-weight, escalating to frontier at premium. Judging what an engine got right runs a mid-weight model; premium plans step it up to the most capable class.
- pin copy
- Fast, small models, every tier. A batch of short brand-voiced posts times many calls each cannot afford a frontier model, and short copy does not need one.
- deliverables
- Workhorse to frontier, by role. Narrative sections run the workhorse class many times per document; synthesis-heavy documents and the point-of-view letter escalate to the most capable model available. On an upstream error the call falls one class with a logged warning, never a silent substitution.
- briefs
- Always frontier. Opt-in and low volume, so the ceiling holds even at the top class.
Overrides are allowed, but every one is logged with a reason - the default path holds the guardrails.
That is the machinery that picks the model. The output is brand work you never had to configure. See it on your brand
What the single chokepoint buys
Every model call in the suite passes through one gateway. Routing decides which model; the gateway makes every call accountable, bounded, and honest about cost.
- metered
- Tokens and cost are recorded on every response - every generation is accounted for.
- ceilinged
- Spend is reserved before the call and settled to the actual cost after. If the meter is unreachable, the call is refused - fail closed, never an untracked spend.
- bounded
- Every call carries a deadline and is aborted past it - a hung engine never hangs the product.
- typed
- Failures come back named - rate limit, refusal, timeout - so products handle them instead of guessing.
- priced
- Four engine families are priced through one shared rate lookup: Anthropic, OpenAI, Google, Perplexity. An unknown model id is costed at a deliberately expensive fallback and flagged - never silently under-counted.
Every call is metered; a call is written to the cost ledger only when a product opts in, which is what keeps the totals honest and impossible to double-count.
Why you never keep up with model launches
When a vendor ships a new model family, the change is one entry in the routing table, shipped to every product at once. There is no per-product upgrade to chase and no setting for you to touch - the whole suite moves to the better model on the same day.
That is the point of routing by class instead of by name: the rule "high-volume work runs on fast, small models" does not care what this quarter’s fast, small model is called. You get the right model for each job, and the right model keeps getting better underneath you.
Keep going
This page is the model layer. The full tour shows how it connects to everything Jinn learns, wears, and works for a brand.
- The full tourThe mechanism end to end: how Jinn learns, wears, and works a brand.
- The recordThe 346-signal Brand DNA record, group by group.
- Guardrails & spendThe deterministic checks that guard your money and your name.
- Measurement disciplineThe floors our own measurements must clear before we publish them.
- Check it yourselfWhat “verified” means here: human approvals, recorded provenance, and facts that age on purpose.
Models, answered
- Do I choose which AI model Jinn uses?
- No. Every job is routed to the class of model it needs by a single routing table. You never pick a model, tune one, or keep up with model launches.
- Why not use the most powerful model for everything?
- Because the most powerful model on a high-volume path breaks the cost ceiling immediately. Visibility checks that run constantly are pinned to fast, small models by rule; a premium plan buys more samples and more engines there, never a bigger model.
- What happens when a new model comes out?
- The routing table is one file. A new family is one entry, shipped to every product at once, so you get the upgrade without changing anything.
- How do you keep model spend under control?
- Every call passes through one gateway that records tokens and cost, reserves spend before the call and settles it after, and refuses the call if the meter is unreachable. Fail closed, never an untracked spend.
The right model for every job, chosen for you.
Run the free brand read and watch the suite route every job to the model class it needs - without a single setting from you.