Give me the exact definition, description, and any filters/criteria for the NECE field as defined in Product Usage - Accounts.topic.yaml
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.
| When | Rating | Comment |
|---|---|---|
| 2026-09-11 13:49 | negative | Follow-up to request_id 88a3514d (earlier feedback: NECE not found despite being defined in Product Usage - Accounts.topic.yaml). After that feedback, a retry (request_id 0630408d) silently resolved NECE to a query labeled "Attached Corporate Clients" — filtering only on account status flags (Corporate type, has Dext parent, not suspended/demo/reseller), with no usage/engagement criteria despite "Engaged" apparently being part of what NECE stands for. Immediately after, asking Chandler to state the definition/filters it had just used for NECE (request_id e5be185b) returned "NECE not defined" again. This is inconsistent across three calls in the same session: not defined -> silently mapped to a plausible-but-unverified query -> not defined again. The user flagged the resulting numbers (770k-810k) as implausibly high, likely because "attached" (linked account) and "engaged" (actual usage) are being conflated. Please have someone confirm the correct NECE definition/filters against Product Usage - Accounts.topic.yaml and check why resolution is unstable across identical/near-identical queries in one session. |
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.