Builder Portal
A self-service dashboard for developers. View your spend and budgets, efficiency and safety scores, session history, projects, and manage your own access tokens — without needing admin access.
When Developer Auth creates a Builder Portal account on your first OIDC sign-in, it records the account creation and your authenticated identity in the configuration audit trail. If the account or its audit event cannot be saved, sign-in fails without issuing a credential. Later sign-ins reuse your existing account and role.
Overview — spend, budgets and scores
The Overview tab shows your spend across every session, the budgets that apply to you, and the efficiency and safety scores for your current or most recent session. Spend for a single session is on the Sessions tab.
Spend
The spend card at the top of Overview totals your model spend across all of your sessions and access tokens:
- Spent · month — your spend this calendar month, and the date it resets. This is the same monthly window a monthly budget rule uses.
- Today — your spend since midnight.
- Burn rate — the combined average spend per minute of your active sessions. The card header shows how many sessions are active.
- Headroom — how much is left on the budget your requests will reach first. Budget: None means no budget rule applies to you.
Spend comes from the daily cost rollup, so it can trail your live spend by a few minutes. Budget rows use the same spend admins see on Budgets → Rules.
Budgets
Under the stats, Budgets that apply to you lists every budget rule that applies to you: the organization-wide rule (ORG), each of your teams' rules (TEAM), your own user-scope rule (USER) and your access tokens' rules (TOKEN). Team here is the same thing as group; membership comes from your SSO identity provider's group mappings when SSO is configured, otherwise from the team assigned to your account. The list is shown whether or not you have an active session.
A request has to fit within every budget that applies, so a team or organization budget can stop you before your personal one does. If you don't have a personal budget, the list says so and your spend counts toward the team and organization budgets shown.
The list is collapsed by default to one line: the budget you'll reach first, how much of it is used, its mode, and how many other budgets apply. Click Budgets that apply to you to expand it; the Builder Portal remembers your choice in this browser. When a Deny budget is used up, the list opens automatically, can't be collapsed, and an alert above the stats says which budget is blocking requests and when it resets.
Each row shows the rule's scope, its model pattern (All models for *), its window (Monthly, Weekly, Daily or Hourly), spend against the limit with a progress bar, the percent used and reset date, and the rule's mode (Deny, Warn, Audit or Approval). Team and organization rows show the total for everyone under that rule, plus You: $…, your own share. Teammates' individual spend isn't shown. Your share isn't shown on hourly rules.
A row can also be marked:
- Limits you first — the rule with the least headroom; this is the one your next request will hit first. It shows the time left at your current burn rate when that comes before the reset. It reads Blocking requests once a Deny rule is used up.
- override — your personal (user-scope) limit replaces the team and organization limits for these models; see Set a budget → Override a shared limit.
- not enforced for you — a team or organization rule that your own override replaces. Your spend still counts toward it, but you can't request more against it.
Click Request more on a row (or Request increase on the used-up alert) to open Request a higher budget. Enter a New limit (USD) — it must be higher than the rule's current limit, and defaults to 1.5x it — and Why do you need it?, then Send request. This files the same request described in Request a config-target exception; an approver decides whether to give you a personal override, raise the shared rule, or grant a temporary exception — see Approve a budget request. While your request is pending, the row shows a Requested tag instead of the button.
Efficiency score
AIControls grades your AI usage across five dimensions:
| Signal | Weight | What it measures |
|---|---|---|
| Cache hit rate | 35% | How often your prompts hit the provider's prompt cache |
| Context efficiency | 20% | How much of your context window is productive content vs. noise |
| Model appropriateness | 15% | Whether you're using a heavier model than the task requires |
| Prompt repetition | 15% | Whether you're re-sending the same content across turns |
| Repeat file reads | 15% | Whether you're re-reading the same files instead of relying on earlier context |
A letter grade (A–F) summarises the five signals. Lower grades surface specific recommendations to reduce token waste.
Your score is compared against your rolling average across your recent completed sessions with the same purpose — until you finish one session of that purpose, there's no average yet to compare against. Streaks, consecutive-session badges, and the trend chart count completed sessions the same way; a session still in progress joins them once it ends.
Safety score
Tracks policy denials in your recent sessions. A high score means your requests are consistently within policy. Repeated denials on the same tool or operation appear as actionable items — click through to see which policy is firing and why.
Context health
A breakdown of your active session's context window: fill percentage, loop score, latency rot, verbosity, and repeat reads. Fill percentage is the most recent call's full input context (including cached tokens) divided by the model's context window, the same measurement as the context window ring, so it tracks current context size rather than total tokens spent in the session. High loop scores or verbosity suggest starting a new session or compressing context.
Access tokens
The Access Tokens tab is where you create and manage Personal Access Tokens (PATs). PATs are how your AI tools authenticate to the AIControls proxy — they replace direct API keys on your machine.
Each token has a name identifying the tool or machine it's used from, an expiry (30 to 365 days), and a status — tokens marked new have never been used. The token value is only shown once, at creation time.
The Builder Portal Setup wizard and the setup panel shown after creating a token offer the same products: Claude / Anthropic, Codex / OpenAI, GitHub Copilot, and Azure OpenAI. Each product has its own connection instructions. The wizard offers the optional skills installer only for Claude Code.
For products that support both connection methods, choose how you authenticate when your workspace makes both available:
| Mode | How it works |
|---|---|
| Proxy mode | Your AI tool routes all LLM and MCP traffic through the AIControls proxy using the organization's managed key. No personal API key or subscription needed — the token you paste is your PAT. Full governance coverage. |
| Passthrough mode | Your AI tool keeps its own credentials (a claude.ai subscription or personal API key); AIControls intercepts and adds governance on top. Lower setup friction. |
If your workspace has both modes enabled, the panel defaults to Proxy mode — the path that works even without a personal subscription or API key. Switch to Passthrough mode with one click if you'd rather use your own credentials.
See the Claude Code, Cursor, Codex, or GitHub Copilot pages for tool-specific connection details.
Sessions
The Sessions tab lists all sessions associated with your developer identity — status, purpose, spend, and call counts. Each row opens a session detail drawer with the same insights administrators see, scoped to your own sessions:
- Overview — status, intent, model, spend against budget, and call counts. Intent shows your declared purpose when present, otherwise the intent detected from recorded tool activity.
- Activity — a timeline of every tool call and LLM request, with websites contacted, documents read, and data queries.
- Insights — detected intent, areas of the codebase touched, attributed tickets, quality signals (committed, verified, focus), and an AI-generated summary of what was worked on.
- Optimization — an efficiency grade, per-model cost breakdown, cache savings, and ranked recommendations for reducing spend.
- Context — context window fill, a token breakdown by segment, and per-turn growth.
- Security — content-safety findings (credentials, PII) and unrecognized tools detected in your session, so you can self-correct before an administrator has to follow up.
Context detection uses recorded tool activity. OpenAI Responses sessions, including Codex, record function and custom tool calls; supported shell commands and patch paths can identify intent, work areas, repositories, and tickets. Opaque code runners can establish Execution intent, but code strings alone do not establish file edits, tests, or commits.
When a session has no supported activity evidence, Insights shows Unavailable for quality, commit status, and verification. An ended session with no detected context shows No context detected. Commit and verification signals describe observed commands; they do not certify that those commands succeeded. Older sessions whose tool activity was not captured cannot recover those signals automatically.
The Context tab estimates the token breakdown across system instructions, user messages, assistant history, tool results, and tool definitions using the request content and reported input-token count. If the model's context capacity is unknown, fill percentages are Unavailable and the growth chart is omitted. Token counts remain visible. Dated OpenAI model snapshots (e.g. gpt-5.2-2025-12-11) are recognized by matching them back to their base model, so fill percentages stay available for those without needing a separate table entry per dated snapshot.
Projects
The Projects tab aggregates your session history by project (repository path), with per-project cost, token usage, and activity trends. It's populated automatically from your coding agent's session metadata — no manual tagging required.
The tab lists only projects you worked on, with your own sessions and cost, whether you sign in with SSO, a session, or an access token. Opening a project shows your own sessions, cost, and activity on it. On a project you share with teammates, you don't see their sessions, cost, or activity, or a list of who else contributed. Administrators and viewers see every contributor when they open a project in the admin console. Contributor lists name people only, as on Adoption. Anonymous agents (anon:*), service accounts (sa:*), and Kubernetes agents are left out, and so is any owner that matches an agent in Inventory → Identities by its ID, agent ID, or display name. An email address always counts as a person. Project sessions and cost still include their activity. Usage across all projects and developers is shown only to administrators and viewers, on Productivity → Usage in the admin console.
Project data appears after your first coding-agent session. If the table is empty, complete a session and refresh.
User profile and activity
The User tab shows your profile (display name, password, role — role changes require an admin) and work patterns derived automatically from your session history: commit cadence, work area focus, language breakdown, and tool usage.
Connected accounts
The Connected Accounts tab manages per-developer credentials for upstream datasources (databases, APIs, internal services) that your AI tools access via MCP. Two types are listed:
- Stored credentials — OAuth tokens or API keys you've connected. Shows status (Connected, Expired, Disconnected), token prefix, and expiry.
- Client-configured — credentials passed as custom headers from your AI tool. AIControls doesn't store these; the card shows the expected header name and setup instructions.
Policy exceptions
The Policy Exceptions tab shows exceptions that have been granted for your identity — operations that would normally be denied by policy but have been explicitly approved. Exceptions are granted by admins and have an expiry date. You cannot create exceptions yourself; they're requested via the HITL approval flow or directly from your admin. See Approval Workflow for how a request moves from submission to grant, including requests that need more than one approver to sign off.
My Activity
My Activity brings your delivery and AI activity into one reporting period. It shows four summary cards for productivity points, merged PRs, gateway requests, and peak concurrent sessions, alongside your productivity band and percentile. Beside it, Compare with others shows your current primary team or the organization when your account has permission. The page also includes merged and AI pull requests, a productivity trend when the range supports one, and three aligned activity lanes. Existing links to the former My Productivity tab open My Activity.
AI pull requests include PRs with witnessed AI authoring, an AI authoring marker, or a Copilot review, matching the admin console.
Productivity standing and percentile
Your band uses the same Low, Medium, High, Elite rules as the other productivity views:
| Band | Meaning within the selected comparison group |
|---|---|
| Low | Below the median score |
| Medium | At or above the median, outside a higher band |
| High | The top 25%, outside Elite; requires at least four members with scores |
| Elite | The top 10%; requires at least ten members with scores |
The number of places in a percentage band rounds upward. Groups with fewer than four scores split at the median. Equal scores retain the existing deterministic band ordering, so a tie at a band boundary can cross bands. These bands describe relative standing, not engineering quality.
The percentile places your score within the full group for the same reporting dates, timezone, and PR filters. It uses 100 × (number of lower scores + half the number of equal scores) ÷ number of scored members. For example, scores of 10, 20, 20, and 40 give both members with 20 points P50. Tied scores therefore share a percentile even when the existing band tie rules place them in different bands. Your own score and recorded zeroes are included; unavailable scores are excluded. A percentile needs at least two members with scores. Displayed percentiles round to the nearest whole number. The standing card uses the same color for your band and percentile, with incomplete-scoring explanations in its info tooltip.
My team uses current primary-team membership. Organization is available only when your administrator permits organization comparison; it includes eligible active accounts in your organization. Changing this choice changes the comparison, band, and percentile while preserving your personal productivity points. An account without a primary team does not automatically fall back to organization comparison.
Your own standing remains visible when you page through members. Anonymous colleagues keep their names private while their bands, exact points, score bars, and whole-number percentiles remain visible. Members without a recorded score show an unavailable value. They remain part of the comparison group used for standing and appear on member pages. The footer contains only member navigation. On wide screens, the comparison card matches the height of the four summary cards beside it.
The displayed report stays unchanged when new activity arrives, a minute passes, or you return to the browser tab. Use Refresh activity, or change the selected period, timezone, PR filters, or comparison controls, to request new data. The As of time identifies the accepted reporting cutoff. Every new request rechecks access and sharing permissions. Refreshing starts the comparison permission check immediately, independently of the summary request. Peer details are hidden while that explicit check runs or if it fails. Your own standing stays visible while loading another member page for the same reporting view; it clears if the check fails or comparison is no longer permitted. A newly accepted reporting view reloads standing so the band and percentile match that view. If membership changes leave your selected page empty, the report returns to the last valid member page.
Info tooltips in the standing and comparison cards identify incomplete scoring evidence and missing cohort scores. These states can differ: a missing score can make the percentile incomplete without changing the existing band's status. No scored evidence, disabled scoring, unavailable comparisons, and request failures remain distinct from a recorded zero.
Saved reporting timezone
Choose an IANA timezone beside the period selector. The choice saves automatically to your user record and is restored when you next open the Builder Portal, including on another device. Saving… means the change is still pending; Saved appears after the server confirms it. If a save fails, the report retains its last confirmed timezone. A change made in another session is reconciled before your next save. Absolute Builder timestamps use this saved timezone; durations and relative ages keep their existing meaning.
On first use, the portal initializes the preference from your browser's supported timezone, or UTC if that is unavailable. Use browser timezone explicitly selects and saves the browser's current zone. Travelling or changing the computer's zone does not silently replace an existing saved preference. Read-only accounts can use an existing preference but cannot change it.
Reporting periods
| Selection | Meaning in your saved timezone |
|---|---|
| Last 7, 30, or 90 days | Complete local days, ending before today |
| Last week | The previous complete Monday–Sunday week |
| Last 4 complete weeks | Four complete Monday–Sunday weeks |
| Last month or last quarter | The previous complete calendar month or quarter |
| Today, this week, or this month | In progress, capped at the displayed server cutoff |
| Custom range | Inclusive local dates, up to 366 calendar dates; today is capped at the cutoff |
The server validates dates in the saved timezone. A rejected draft leaves your previous report visible under its original range. Refresh activity resolves the range again; returning to the visible page preserves the accepted report. Daylight-saving changes retain their actual intervals rather than assuming every day has 24 hours. Repeated hours include their UTC offset, and skipped civil dates are disclosed.
A range of 2–7 local dates, including Last 7 complete days and Last week, shows daily productivity points alongside the full-period score and team band. Points follow each PR’s merge date in your selected timezone. A current day is marked partial; a skipped calendar date has no interval. At least two actual day intervals are needed for a trend. A single-day range shows its score and band. Ranges longer than seven days show a trend only when they include at least two complete local weeks. For ranges over 90 days, complete calendar months are preferred when at least two are available. Partial weekly/monthly boundary periods are excluded from the trend and identified below it. Missing scores remain gaps; a recorded zero remains zero.
Activity and contributions
The summary uses four matching cards: productivity points, merged PRs, gateway requests, and peak concurrent sessions. Productivity standing appears separately with your band and percentile. The cards preview the same full-period time series shown in the larger charts below, with missing data kept as gaps. Info tooltips retain AI PR counts and scoring/classification explanations. Compare with previous period loads an optional comparison for the same scope. Completed calendar months and quarters compare with the preceding calendar period; other completed ranges compare with the preceding equal number of local dates. Percentage changes appear only when both periods have complete, comparable evidence and the previous value is nonzero. Retained subtotals remain useful even when a percentage comparison is unavailable.
Activity & Outcome over time groups the time series on the same time axis: Productivity first, then Merged pull requests, Gateway requests, and Peak five-minute session activity. The Productivity lane remains labeled when a trend is unavailable and explains incomplete delivery coverage or the need for more complete periods; missing scores are never plotted as zero. Use the Inspect a day calendar to see finer activity without changing your period-wide score, band, or contribution charts. Only dates within your selected period are clickable; skipped civil dates are disabled. Full period returns to the overview. During day inspection, the productivity trend is replaced by a note to return to the full period; daily points are not allocated to hours, and weekly/monthly points are not allocated to days. Use the previous/next interval buttons or Left/Right, Home, and End keys to pin the same position across the visible lanes. Each lane's tooltip and highlight use its interval containing that position. A pinned selection stays fixed as the pointer moves; Escape clears it. Repeated hours show distinct UTC offsets. Tooltips retain partial-evidence explanations, and the accessible values views include productivity intervals, daily PR counts, and requests that have no session identifier.
Each time series and summary thumbnail has an Expand chart control with two diagonal arrows. The expanded view shows one series in a large overlay with the same reporting period and values. Hover or click to inspect and pin an interval, or use its previous/next buttons and Left/Right, Home, and End keys. Clear pin releases the selection; Escape or the close button returns to the page. Expanding a chart does not change your reporting period or load another report.
Session activity counts distinct gateway sessions making requests in a five-minute interval. Requests include recorded LLM and MCP attempts, including retries and blocked or failed attempts. Overlapping independent tasks can be a useful practice to explore, but this activity proxy does not measure exact concurrency or establish that parallel sessions caused higher productivity.
PRs by project appears on the left and PRs by repository on the right in equally sized cards. They stack on narrow screens. Each chart is ordered by merged PR count from highest to lowest across all pages. Names break ties. Charts include only projects and repositories with at least one merged PR in the selected period and PR scope; zero-count entries are omitted before pagination. Coverage notices still explain unavailable data. Counts appear beside each bar for the full selected period and its PR filters. Projects use explicit repository assignments. A repository may belong to multiple projects, so project totals must not be added together. Full names and exact counts appear alongside each bar. Select a name or bar to open the underlying PR evidence with that repository or project filter. Pagination appears only when more than one page exists. PRs in repositories without a project assignment do not contribute to a project bar.
PR filters apply target-branch and delivery-candidate choices to PRs, productivity points, the trend, and contribution PR counts. Gateway request and session activity keep their full scope. Compare with others loads alongside the summary. Expand Supporting evidence to load your merged PRs or native work-type breakdown. The PR table follows the main selected dates and timezone and shows its matching count. Title search, sorting, work type (including Unclassified), repository, project and AI-status filters affect only this evidence list. Changing these filters returns to its first page. Open a PR to inspect its eligible lines, weight and recorded points; technical provenance and excluded lines are expandable. Previous/next navigation in the drawer covers the current page, and a direct GitHub link opens the original PR.
The PR table's Work type column is editable when your administrator permits the change on your attributed PR. Classifying an Unclassified PR and reclassifying a classified PR have independent permissions, both enabled by default. Selecting a different type saves immediately. Each row shows Saving… and then Saved, and other rows remain available for editing. The table keeps its current page, filters, sort order, and rows. Points, matching counts, and report metrics remain unchanged until you select Refresh results. A notice counts saved PR classifications and marks metrics as needing a refresh. Recalculation runs on the server whether or not you refresh the display. Opening the menu or canceling it does not save. A plain value means the PR is currently read-only. Classification details shows the original work type, latest editor, and change time. If another person changes the PR before your save completes, review the current value and choose again.
Closing and reopening the PR section, changing the reporting period or global PR filters, and selecting Refresh activity preserve the saved-classification count until the saved PRs and report metrics refresh successfully. If a report metric fails to refresh, the notice remains so you can retry without saving your classifications again.
If the save succeeds but its follow-up read fails, Saved selection identifies the acknowledged choice. Select Refresh to load the current classification and permissions before editing again; a later edit may have changed the value.
PR pagination retains a stable list for up to 15 minutes, subject to assessment expiry and current access checks. Ordinary background updates do not interrupt Next PRs. A temporary navigation failure keeps the current page visible while you retry. If the list expires or access changes, reload the list.
The Work-type breakdown uses the same reporting period and global PR filters. It includes scored PRs; pending and unscored PRs are excluded from its denominators. Switch between points and PR count to reorder its compact visual table. The Unclassified summary shows its share of scored PRs and points. Select a work type to filter the PR evidence list, where permitted work-type changes are available.
Data coverage and freshness consolidates source details in one disclosure. Material attribution and source problems remain visible above the charts, and affected metrics retain their partial or unavailable indicators.
Scores appear for eligible onboarded repositories after your administrator enables Productivity score in General → Features. Your GitHub account must be mapped to your developer identity for delivery evidence to appear. Coverage notes distinguish pending scores, recalculation, retention gaps, missing associations, and unavailable sources from observed zero. Peer PRs and activity remain private.
Historical PRs are associated with your current account email, ignoring case and surrounding spaces. This includes eligible PRs opened before My Activity was installed or your account was created. The same rule applies when your account email changes. Previously associated aliases remain available under their existing rules. An email known to belong to multiple accounts remains excluded, even if another account was renamed or deleted. PRs still need valid opening timestamps and must meet repository and scoring requirements. Historical coverage can remain partial because only retained evidence is available; the displayed values are retained subtotals.
Gateway coverage separately identifies collection and retention gaps. Activity deleted within a selected period can leave a gap while earlier activity remains retained. Reported gap ranges may combine several missing observations within a day; they do not mean every instant in that span is missing. Gateway counts describe retained activity, and empty intervals appear as unavailable gaps because complete collection cannot be confirmed. Requests without a session cannot be assigned to your account unless canonical ownership is independently verified; the current audit data does not provide that proof. Native PR metrics can still show recorded zeroes.
My AI Effectiveness
My AI Effectiveness uses the same date ranges and calculation as the admin view. Inspect your trend, score dimensions, and supporting PRs. Your overall score and comparable dimensions show the same Elite, High, Medium, or Low bands as the admin view for that period. The AI effectiveness score appears first in the summary card. Beside the My AI Effectiveness title, a Low → Medium → High → Elite strip shows all four bands together, with your current band larger and colored and the others muted. The metric label is bold, and a small current-band badge sits beneath the score. Current coaching recommendations appear in the same card. Expand Weekly history and team visibility for completed-week history and your score-sharing preference. If the weekly comparison cannot load, a warning appears and your personal history remains available.
Compare with your team
My Activity places Compare with others beside the summary, as described above. My AI Effectiveness retains its team table for the selected period. All active team members are included, including members with Admin or Viewer accounts. It includes AI effectiveness and productivity bands. Under Member choice, scores and comparison bars appear for you and teammates who opt in to share their names and scores; other teammates remain anonymous and show bands only. In both views, administrator visibility takes precedence: Team enables named team comparisons, Global also permits organization comparisons, and Self disables comparisons. Member choice is the default and lets members control whether their names are shown within their team. The name-sharing switch displays Managed by administrator when an administrator controls visibility, while retaining your saved preference for a later return to Member choice. Accounts without a team never automatically fall back to an organization-wide list of developers.
The existing My AI Effectiveness view also retains its historical productivity comparison chart and these optional overlays:
- My team productivity — your team's weekly average points per developer with scored PRs.
- My teammates productivity — individual lines for teammates who share their names and scores.
- All teams productivity — one average line per team, using the same calculation.
The AI effectiveness chart offers My team AI effectiveness, My teammates AI effectiveness, and All teams AI effectiveness. Team lines average the weekly developer scores on a 0–100 scale, using developers with enough evidence. Individual lines use the same weekly calculation as the personal and admin views.
Team averages use developers with an available score for the selected metric each week. Averages for one or two contributors are available when every contributor’s score is visible through administrator policy or member preference; your own score is always visible to you. When some scores are private, at least three private contributors must remain after your own score and shared scores are excluded. Otherwise the average is hidden to prevent recovering a private score by subtraction. Missing scores or averages hidden for privacy appear as gaps; a week with no recorded score does not imply zero productivity. These existing effectiveness-view averages use current active team membership, and the first and last weeks may cover only part of a week. Completed-week effectiveness history remains defined by Monday-based UTC weeks, independent of My Activity’s reporting timezone. These averages let you compare with larger teams without their headcount dominating the chart. Hover over or focus a disabled comparison toggle for an explanation of what may be missing.
In demo mode, sign in to the Builder Portal as alice@nirmata.com with password nirmata to explore both views, current coaching, and team trend comparisons. Demo comparison visibility follows the administrator’s visibility policy and member preferences. A custom demo domain replaces nirmata.com.