Connect once. Let GitHub run the workflow.
Sign in with your approved Tbench account or configured company identity provider. Work-email domain discovery finds your company sign-in, and the portal returns you to the workspace page you opened.
- Review organization approval and choose the execution path.
- Install the Tbench GitHub App for the approved repository, or choose an independent runner policy.
- Install the signed worker once and use the contributor’s existing GitHub CLI identity. Review the repository’s approved workflow and run-specific runner group.
- Run tbench-worker push from your checkout. GitHub triggers the workflow and the temporary session runs its matching jobs on this computer, then confirms cleanup.
The dashboard checklist follows recorded state, with separate GitHub and independent-runner progress. Owners and admins add approved teammates by email, choose roles and review usage and budgets without passing around platform IDs.
Explore desktop controls and browser loginOpen your organization workspaceOne organization. GitHub App for control; your device for compute.
The Tbench GitHub App authorizes the approved repository and receives job events. The hosted broker uses that installation to prepare short-lived, one-job runner access; it does not run the build itself. An opted-in worker must be online to accept work, then GitHub’s official runner executes one job in a disposable Docker environment. On the independent path, Tbench signs an immutable policy assignment and an opted-in agent executes the approved local commit snapshot.
Run the checks. Repair the change. Keep the review.
Actions runs your existing workflow. tbench verify records the repository’s approved required and advisory checks against an exact commit. Add a local AI profile to review selected source against recorded Jira and Confluence requirements.
Enable bounded repair in that profile to let the local model propose source changes and rerun frozen tests, up to three attempts. A passing candidate opens a separate repair pull request and runs its GitHub workflow on the same developer’s computer. The configured Slack channel brings the exact change and test summary to an authorized lead.
Approval checks the current commit, GitHub maintainer permission, protected reviews and independent required checks before merging. Your original checkout stays intact and unsuccessful attempts remain in the evidence. The dashboard shows each submission’s actual approval state.
Infinity’s versioned 14-stage methodology evaluates Terminal-Bench tasks, environments, reference solutions and verifiers. Application checks and repair use the organization’s repository policy; the benchmark methodology remains a separate audit flow.
Our runner protocol. Your pipeline policy.
The portable source profile adds Tbench’s own agent and signed queue, independent of the GitHub runner executable. Organization owners approve the image, steps and resource limits; opted-in devices execute exact commit snapshots without changing a developer’s working tree. Portable policies pin a preinstalled image and its native amd64 or arm64 architecture.
| Mode | Command | Purpose |
|---|---|---|
| Actions | tbench actions | Run an approved pipeline locally, from an existing CI agent, or through the independent Tbench queue. |
| Application verification | tbench verify | Run a separately approved required/advisory check policy and produce commit-bound reports. |
Custom scripts, GitLab and Jenkins can invoke an approved Tbench policy while their existing pipeline engines keep scheduling and credentials. The portable agent is a separately qualified source profile; the existing GitHub download remains its own release.
Explore the independent runner and setupShare capacity on your terms.
Each user explicitly enrolls their device and starts a bounded worker session when they want it to serve CI. Start it once for the session—not for every PR. Your organization sets the repository scope and execution policy.
- Approve a private repository, workflow/ref policy and device enrollment separately.
- Cap job CPU and total device memory; keep headroom for the owner’s work.
- The current signed GitHub worker selects Ubuntu 24.04 x64 or ARM64 to match the Docker engine. The signed Mac-host pilot is available, but physical MacBook qualification remains pending; native Xcode builds require a separate Apple-host execution profile.
- Sleeping, stopped or disconnected devices leave work queued for eligible capacity.
- Keep GitHub App signing keys on the hosted broker. Configure any optional model workload and its credentials separately.
A job running on a device can access the workflow secrets GitHub grants it. Schedule deployment or signing jobs only on trusted computers and repositories. Same-label repository jobs remain eligible under GitHub’s runner matching.
Choose the right jobs for your devices.
| Workload | Availability | Conditions |
|---|---|---|
| Existing shell and JavaScript-action jobs | Supported profile | Ubuntu 24.04 x64; dependencies must fit the approved image, network policy and resource caps. |
| Push, PR, manual, scheduled and matrix workflows | Approved scope | GitHub keeps scheduling, needs, matrices, logs and artifacts. Private, same-repository source and explicit workflow/event/ref approval are required. |
| npm and Python package downloads | Opt-in | GitHub-only networking by default. The package-registries profile additionally permits npm and PyPI; arbitrary hosts remain blocked. |
| Execution duration and local availability | Bounded | Ten-minute job deadline. The owner must keep the device awake and serving; offline devices leave work queued, with no paid fallback. |
| Docker builds, container actions and services | Not supported | No Docker socket, privileged runner, service container or nested Docker build is exposed. |
| Mac hosts and native Linux ARM64 jobs | Signed client pilot | The current desktop/worker release supports Ubuntu x64 on Intel Macs and Ubuntu ARM64 on Apple Silicon or ARM64 Linux. The macOS installation command is available; actual MacBook installation, Keychain and job lifecycle qualification are pending. |
| Native Windows/macOS/Xcode/GPU jobs | Not qualified | These require separate execution backends and image qualification. Windows hosts serve Linux x64 jobs through Docker Desktop; a Mac host also runs Linux jobs, not native macOS jobs. |
| Public forks and hostile code | Not admitted | Use only private code and workflows trusted by the device owner. Docker is not a hostile-code microVM boundary. |
| Managed cache and hosted overflow | Not available | Persistent managed caches and paid hosted overflow are outside the current device plan. |
| Self-serve organization connect | Beta | Connect the GitHub App for your approved organization and private repository scope, then enroll devices through guided setup. |
This matrix describes the GitHub worker profile. GitHub evaluates triggers, dependencies, matrices and approvals. Portable policies use their own approved image, commands and limits; see the independent runner guide for that profile.
Choose where compute runs.
Local runners use a $15 contributor seat with no Tbench per-minute fee on your own hardware. The AI runner demo is $0.10 per started run with approved CPU compute included, up to 2 CPU / 4 GiB and ten minutes including preparation and cleanup. Separate workload approval, qualified capacity and organization budgets apply. Paid model inference requires its own configuration and allowance.
Hosted usage and spending controlsUnderstand the full cost of a build.
Compare elapsed time, power, hardware, storage and maintenance with hosted CI. Contributor seats cover execution on your enrolled compute; persistent managed dependency and build caches are outside the current plan.
Explore contributor pricingA controlled queue. A clear recovery path.
Jobs wait for your enrolled capacity, with paid cloud overflow disabled. The GitHub path uses worker-bound leases and independent GitHub job inspection. The portable queue uses signed policy assignments and fenced device-bound leases; an expired active assignment requires operator attention rather than automatic reexecution. Operators review started or ambiguous jobs before recovery and confirm owned-resource cleanup.
Your tools. Your identity. Your execution trail.
Connect GitHub for workflow events, authorized Jira and Confluence references for project context, corporate OIDC for company sign-in, and MCP clients for read-only context metadata. GitLab and Jenkins can invoke approved Tbench policies through their existing pipelines.
Explore integrations and company sign-inKeep execution, verification and authoring distinct.
| Product | Responsibility |
|---|---|
| Actions | Run GitHub workflows or approved portable CI policies on enrolled compute. |
| Application verification | Run named required/advisory repository checks with tbench verify and produce commit-bound reports. |
| Infinity Verifier | Audit Terminal-Bench tasks, environments, reference solutions and verifiers through a versioned 14-stage evaluation methodology. |
| Experts | Claim projects, propose and author tasks, submit PRs and complete controlled trials. |
Actions and local application verification are included in the approved organization trial. Hosted benchmark audits follow their separate project allowance; a CI result is not an audit certificate.