Teams

Signing in and joining a team org are both optional — kikimimi web and local Parquet work with no account at all. This page covers what changes once you do sign in.

What teams can understand

• Who uses what: admins and owners can review per-member usage, then open sessions to inspect agents, models, and tools. The Models view also shows organization-wide model and effort totals.
• Where to optimize: use token counts, available cost data, retry patterns, and MCP overhead estimates to identify settings or workflows worth changing. Missing cost is unknown; these views do not reconcile every subscription bill or guarantee savings.
• Which behavior needs review: detection patterns surface permission detours, repeated denials, retry spirals, and context growth. For example, a denied tool followed within five recorded events by a Bash or browser call is a potential detour. Inspect the session to determine what happened; the sequence alone does not prove a bypass. Collection observes activity and does not block agent actions.

Use these views to improve the team’s setup and investigate specific sessions. Member usage and cross-member drilldowns are restricted to admins and owners and audited, as described below.

Sign in

kikimimi login

kikimimi login never opens a browser itself — it prints a code and waits for you to approve it on the web:

To authorize this device, open:
  https://kikimimi.dev/activate
and enter code: ABCD-1234
waiting for approval...

Approving on kikimimi.dev goes through GitHub OAuth sign-in. On success the CLI prints which account and org it landed on:

logged in as you@example.com (org you [personal])

kikimimi logout revokes the token on the server (best-effort) and forgets it locally either way.

Personal vs. team orgs

Your first GitHub sign-in auto-creates a personal org — just you, always owner, never filtered (see repo allowlist below). Anyone can also create a team org on kikimimi.dev; the creator becomes its owner and invites the rest of the team.

kikimimi orgs lists every org your account belongs to, across both kinds, and marks the one this device is currently bound to:

orgs:
  you       personal  owner   (this device)
  acme      team      admin

Invite links

An admin or owner mints an invite link for a team org from the web UI — role, an optional expiry, and an optional use-count limit are all set at creation time. Following the link and signing in with GitHub joins that org at the invited role; a revoked, expired, or exhausted invite is rejected with the specific reason. An admin can’t mint an invite for a role above their own (an admin can’t invite another owner).

Roles

Four roles, in order: owner, admin, member, viewer. They govern what a team org’s drilldowns show:

• member / viewer in a team org see only their own sessions when they open a per-session drilldown.
• admin / owner see every member’s sessions — and every one of those drilldowns writes a row to the org’s audit log (who looked, when).
• A personal org has no “other members” to scope away from, so it always behaves like the unscoped, unaudited admin path — it’s just you.
• admin / owner also see the org’s onboarding funnel on the Team page: how many of the org’s machines ran kikimimi login, got a token, sent their first events, and belong to an account that has opened a view — plus 30-day retention. Counts only, no per-person rows.

Above the org roles there is one deployment-wide flag, operator, on the account itself. It adds exactly one thing: the same onboarding funnel across every org on the deployment (scope=all), which is how the people running an instance measure where new machines drop off (Privacy). It is not granted through the web UI or the API — the operator sets it in SQL on their own instance (see Self-hosting).

Members usage view

The “Members” view on kikimimi.dev is a per-member usage rollup — sessions, API requests, tool calls/failures, token totals, estimated cost — over the trailing 30 days. In a team org it’s admin/owner-only (a member or viewer gets turned away, both in the UI and if they hit the API directly) and every view of it writes an audit log row, same as an admin’s session drilldown.

It’s sorted alphabetically by member, on purpose — not by cost or usage. This is meant to explain what’s driving a number (loops, heavy cache re-reads), not to rank people by spend.

A loop-suspect sessions column flags members with at least one session that made 50+ API requests — worth a look for a runaway loop, not proof of one. Any nonzero count surfaces both an inline badge on that row and a summary callout above the table.

Per-machine org binding

A device is bound to exactly one org’s cloud sink at a time — there’s no per-request switching. Bind (or re-bind) a machine with:

kikimimi login --org acme --repo 'github.com/acme/*'

--org is only a hint for pre-selecting the org on the approval page; the org a device actually ends up bound to is whatever gets approved there, server-side. Signing in again keeps this machine’s locally-configured repo allowlist — it isn’t reset just because you re-authenticated.

Use one or more --repo flags to replace the allowlist before the new connection becomes active. Omitting --repo preserves it. Login and logout notify the running collector, so a restart is not required. Changing the workspace you view in the dashboard does not rebind a device.

Repo allowlist

kikimimi repos allow 'github.com/acme/*'
kikimimi repos list
kikimimi repos remove 'github.com/acme/*'

This allowlist only ever matters for a team org’s cloud sink: an event is pushed to the team cloud only when its repo matches one of these globs. A personal org is never filtered, even if patterns are configured — kikimimi repos says so directly when you’re on one:

(repo filter only applies to team orgs; this org's events are never filtered)

The local Parquet file and any BYO sink (S3, see Sinks) always receive every event, unfiltered — this allowlist only controls what leaves your machine for the shared team cloud.

Leaving the list empty doesn’t mean “block everything” — it means “send everything,” and kikimimi status warns about it:

repo filter: none configured -- every event is sent to the team cloud unfiltered (run `kikimimi repos allow <glob>` to restrict)

SSH vs. HTTPS form. Claude Code and Codex don’t record a repo URL the same way: Claude Code keeps whatever form the git remote actually uses (often SSH, git@github.com:acme/api.git), while Codex records HTTPS. A glob anchored to one scheme will silently miss the other. Shape it to match both instead:

kikimimi repos allow '*acme/api*'

An event with no repo at all (hooks outside a git tree, OTel events, which never carry cwd) is treated as not matching a non-empty allowlist — conservative by design, since there’s no repo to confirm against.

Self-hosting

kikimimi login talks to https://kikimimi.dev by default. Point it at your own instance instead:

kikimimi login --endpoint https://kikimimi.your-company.internal
# or, to avoid repeating the flag:
export KIKIMIMI_ENDPOINT=https://kikimimi.your-company.internal
kikimimi login

--endpoint always wins if both are set; a previously-saved login is used if neither is. See Development for running kikimimi cloud yourself.

To read the onboarding funnel across every org on your instance, flag your own account as operator once, directly in Postgres:

UPDATE accounts SET operator = true WHERE email = 'you@example.com';

AI allocation: roster, contracts, and observed use

The AI allocation page (/allocation) lets workspace admins and owners register people before they have joined or sent activity. Add people manually or download the CSV template, fill it in, review the import, and save it. The roster does not provision subscriptions or invite accounts.

Each person has an email, name, department, and zero or more assigned tools. Each tool has a plan, optional allocated-model description, optional monthly contract amount, and currency (USD, JPY, EUR, or GBP). Use one assignment per tool per person. For annual contracts, enter the monthly equivalent; leave unknown amounts blank. A person with no assignments still belongs in the roster.

CSV columns are email,name,department,tool,plan,allocated_model,monthly_amount,currency,account_id. Repeat the same person’s details on separate rows for multiple tools. Leave the tool and contract fields blank for an unassigned person. Emails are normalized to lowercase. Importing an existing email replaces its details and all assignments; omitted people are kept. Invalid imports are rejected as a whole.

Usage matches a workspace member’s email, or an explicitly selected usage account when the sign-in email differs. The optional CSV account_id is that member’s account UUID. Only members of the current workspace can be linked. Roster deletion removes the inventory record, not the account or collected events.

The department filter scopes the roster, observed-use fraction and contract totals. Observed use covers the last 30 UTC calendar days including today and counts each person once when there are events for at least one of their assigned tools. This is a lower bound on adoption, not a productivity score. No records may mean inactivity, missing collection, unsupported tools, or repo-sharing filters. Only Claude Code and Codex currently have automatic collectors; other tools can be inventoried but are labeled as unsupported when no usage is present.

Monthly contract totals remain separate by currency, with missing amounts counted explicitly. They are entered contract amounts, not reconciled invoices. Per-tool API estimates come only from observed api.request records, prefer OTel over transcripts within each session, and show pricing coverage. They are never added to contract totals. No budget enforcement, invoice sync, spend forecast, automated model recommendation, or cloud subscription-limit sync is included in this view.

Roster reads and mutation attempts are audited. All endpoints require admin/owner access and roster storage is isolated by workspace with database row-level security.