How many MTD for Income Tax quarterly updates have been successfully submitted to HMRC through Dext Solo to date, and how many practices and income sources are connected to HMRC?
Basis: Available Dext Solo account identifiers; the model does not expose successful quarterly-update submi, latest available snapshot. Governed filters applied. Every row's «Distinct Solo Individual IDs (Not Successful Submissions)» came back as 0. That is usually a wrong segment filter rather than a real zero.
Per-step detail — each LLM call, each Omni request, each rejected draft —
is traced to stdout only and is not stored, so it cannot be shown here.
Query attempts counts run_query executions, not model turns.
SELECT MAX(omni_dbt__eds_calendar_day."DATE_DAY") AS "Snapshot Date", COUNT(DISTINCT omni_dbt__eds_all_accounts."HMRC_INDIVIDUAL_ID") AS "Distinct Solo Individual IDs (Not Successful Submissions)", COUNT(DISTINCT omni_dbt__eds_all_accounts."PARENT_ACCOUNT_CRN") AS "Parent Practices Linked to Solo Accounts (Not HMRC Connectivity)", CAST(NULL AS NUMBER) AS "Successful Quarterly Updates Submitted to HMRC", CAST(NULL AS NUMBER) AS "Practices Connected to HMRC", CAST(NULL AS NUMBER) AS "Income Sources Connected to HMRC" FROM PROD."EDS_ALL_ACCOUNTS" AS omni_dbt__eds_all_accounts INNER JOIN PROD."EDS_CALENDAR_DAY" AS omni_dbt__eds_calendar_day ON omni_dbt__eds_calendar_day."DATE_DAY" >= omni_dbt__eds_all_accounts."VALID_FROM" AND omni_dbt__eds_calendar_day."DATE_DAY" <= omni_dbt__eds_all_accounts."VALID_TO" WHERE omni_dbt__eds_calendar_day."IS_LATEST_AVAILABLE_DATE" = TRUE AND omni_dbt__eds_all_accounts."IS_SOLO" = TRUE AND (omni_dbt__eds_all_accounts."IS_DEXT_DEMO" = FALSE OR omni_dbt__eds_all_accounts."IS_DEXT_DEMO" IS NULL) AND omni_dbt__eds_all_accounts."IS_SUSPENDED_DEXT" = FALSE AND omni_dbt__eds_all_accounts."SALESFORCE_ACCOUNT_TYPE" <> 'Reseller' LIMIT 1
No feedback linked to this request.
Cost is the LLM completion spend LiteLLM priced for each call, summed per
request.
Chandler is running on the Codex CLI, which draws ChatGPT plan quota
rather than per-token API billing, so this figure is not money paid —
it is what the same traffic would have cost on the API, priced from the
token counts Codex reports. Read it as the size of the bill avoided.
Two known limits: embedding spend is not recorded, so
retrieval and matching cost is missing, and because the figure is one sum
per request it cannot be split by model within a request — a
request's classifier and agent calls can use different models while
llm_model holds only one name.
Only authenticated calls are logged, USAGE_LOG_ENABLED can
switch logging off, and log writes are fail-soft — this is not a complete
record of traffic. Questions are grouped into sessions: a session is
exact when the caller echoed its id back to us and otherwise inferred from
a 30-minute gap in that user’s activity, so a grouping is only as
good as the source shown on the session itself. A call with no
attributable user gets no session at all; those questions are listed
separately rather than dropped.