Models and routing: what the composer control changes

You do not pick a vendor in Tvijo; you pick a route. The service decides which model answers, keeps the provider's key, and writes down which model was used. The receipt is the only place where "what answered and what it cost" is authoritative.

That design has a practical consequence: when someone asks "which model wrote this?", the answer is in Usage, not in the chat text.

🔹 What a route is

A route is a named policy, not a single model id:

• Cheap routes answer fast and are the ones the sponsored preview supports.
• Premium routes require paid credit.
• A route can be served by a different model on a different day — the provider decides what is healthy, and the service records what actually answered.

So the same question asked twice can produce two different receipts. That is expected, and it is why the receipt is attached to the task rather than to the account.

🧭 What you control

What you do not control: the provider, the exact model, or whether the service retries. There is no automatic paid retry — a failed attempt ends the task.

🧭 Reading a receipt

Open Usage. For each task you should find:

• the provider and model that answered;
• input and output token counts;
• the task limit and the spend for that task;
• the state: completed, cancelled, or uncertain.

The last one matters. Uncertain means the service does not know whether the request was billed. Tvijo does not turn that into $0.00; it keeps the task marked and blocks further paid turns until the state is resolved. An honest unknown is cheaper than a wrong zero.

📊 Cost shape, before you run anything

Two rules of thumb, both visible in the receipt:

1. Context dominates. Attaching a whole file usually costs more than a longer question about one function.
2. Output tokens are not free either. Asking for a long rewrite costs more than asking for a diff.

A budget-conscious habit: ask for a decision or a diff, not for a full rewrite, then run the deterministic check yourself.

🔹 Where the service runs the model

The model call happens server-side. The local client (browser or editor) never holds a provider key:

• credentials are bound to the service URL you signed in with;
• the CLI stores its state under ~/.config/dshrempub/ with owner-only permissions;
• the editor does not collect a provider API key at all.

Connection modes currently save an explicit pilot preference only. Nothing switches to your own provider account, and no key is collected — so "BYOK" today means "registered interest", not "your key is in use".

🚧 When this does NOT work

• You need a pinned model for reproducibility. The route is a class, not a pinned id. Pin it on your side by recording the receipt (provider, model version, token counts) with the result.
• You need a specific vendor for compliance. Do not assume the route maps to one vendor. Ask for the current mapping in writing before you commit to a regulated use case.
• You want to compare two models on the same task. That means two tasks and two receipts. Tvijo does not silently fan a question out to several models — and you would pay for each.
• You expect a failed call to be free. It is either recorded as zero (a provider refusal before generation) or as uncertain. Never assume zero.

➡️ Next

• Costs, budgets and limits — the arithmetic behind the receipt.
• AI judging — why "the model said it is done" is not acceptance.
• Permissions and data flow — what the service sees.