Omniscio documentation
Browse all documentation
  1. Getting Started20
  2. Sessions & Agents147
  3. Inbox & Notifications75
  4. Projects & Tasks106
  5. Automation & Scheduling82
  6. Knowledge & Memory29
  7. AI Features75
  8. Integrations118
  9. Plugins & Marketplace47
  10. Cloud & Teams60
  11. Settings & Customization84
  12. Account & Billing31
  13. Troubleshooting92
  14. CLI & API Reference29
  15. Legal & Policies5
  16. Uncategorised25

Model throughput (how fast each model and vendor actually generates)

Omniscio measures how many tokens per second each model and each vendor actually produces, keeps that as a day-by-day history, and reports it to your inbox once a week. It is a speed reading only — it says nothing about whether an answer was good, or what it cost.

What it is

Every time an agent finishes a turn, Omniscio already knows two things about that turn: how many output tokens it produced, and how much time the provider's API spent on it. This readout puts those two numbers together, labels them with the model and the vendor, and keeps one summary row per model per vendor per day.

Over a week it answers questions like "is this model getting slower", "which vendor is fastest right now", and "did the thing I changed last Tuesday make my agents crawl". Without it, the app could tell you how much time the fleet spent with models — but not which model was spending it.

The number is an effective generation speed: the API time it divides by includes the model reading your context (prefill) and any queueing, and thinking tokens count as output. So it is not the same as a raw "words per second" of visible text, and it should be compared between models rather than against a published benchmark.

Where to find it

  • In your inbox, once a week — a card titled Model throughput — weekly naming the models and vendors measured that week, their average speed, and anything that had to be excluded. It is information only: nothing on it asks you to act, and it carries no buttons.
  • On demand, from a terminal — npm run perf:throughput, optionally -- --days=30 for a longer window or --json for machine-readable output.

There is deliberately no panel or screen for it in the app yet.

How it behaves

  • It fills in as you use the app. Nothing needs switching on. Each launch folds yesterday and today into the history, so a day is recorded once and a late-finishing turn corrects its own day rather than being lost.
  • The first week is a check on itself. A turn that ran helper agents produces more output than the main response did, and the provider's timing may or may not include that work. The report therefore shows two figures — turns with no helper output, and all turns — each with its count. If they disagree badly, the clean one is the honest one.
  • It says what it left out. Every report states how many turns had no usable timing, how many measured an impossible speed, which vendors had nothing usable, and which days have no data. A day with no data is shown as missing, never as a zero.
  • A quiet machine is not a fast machine. If nothing was measured it says "unavailable" rather than 0 tokens per second, so an empty reading can never be mistaken for good news.
  • History starts the day it ships. Nothing before that can be recovered, because the raw timing the app keeps is short-lived by design.

Related

The Performance Monitor's agent-action readout, which answers where agent waiting time went, is the other half of the same question — this page answers how fast the model itself produced its answer, that one answers how long the agent sat waiting for everything else.

Last verified 2026-10-24