Get started

Scan coding-agent sessions for a free cost baseline, then connect your team for continuous analysis and optimization.

Agent usage grows, token budgets run out sooner than expected, and teams cannot see which work consumed the spend or why. gjalla observes agent sessions, attributes cost, and helps identify overhead and rework to reduce.

Start with a passive scan of the coding agents you already use. For the agents you build, instrument their runs with the Python SDK. Both appear in the same Observe and Measure views.

Try it

pipx install gjalla && gjalla scan

No signup form, no password. Enter an email and the 6-digit code it sends you, and the scan uploads straight into your own preview dashboard: Measure and Sessions, open right away.

What a preview account can do

A preview account is metadata-only and free: Measure, Sessions, and session detail are open, everything else is locked. Preview uploads never include prompt or response text, tool inputs, or error excerpts, only timestamps, token counts, models, and commits. A preview team is deleted 60 days after creation unless it’s made full.

To unlock the rest, request beta onboarding from the banner in the app (team size and how you heard about us), or email ellie@gjalla.io. That starts a call and, once the team is made full, you can turn transcript analysis on to get the weekly session judgement.

After beta onboarding

The steps below connect your codebase and agents after beta onboarding. Team starts at $499/month for continuous measurement and analysis.

Add a codebase

In the web app, open Master specs in the side nav and hit the + to connect the repository you want to track. gjalla starts a background analysis to discover your architecture, capabilities, rules, and tech stack. It takes a few minutes.

Connecting GitHub here is what enables two key features of gjalla:

  • reviews on your GitHub pull requests
  • the generation of your full master spec

Set your rules

Open Rules in the side nav and add the things you expect to be true in your code. Teams capture rules like “customer data can never be sent to external APIs” here. Anything you find yourself describing to new teammates is a good candidate.

Write rules in plain language. gjalla turns them into real gate behavior for reviews and agent workflows, not just advisory text.

Install the CLI

pipx install gjalla
cd your-repo
gjalla setup

The wizard installs everything your agent needs in one pass: it links the repo to your project, installs hooks, configures MCP where available, and writes each agent’s native guidance and skill files. Install once; every supported agent in the repo gets the same harness.

Reviews on every PR

With GitHub connected, gjalla runs an independent production-readiness review on each pull request. It’s grounded in your master spec, verifies your rules, and checks against industry best practices.

The result is a review that tells you what actually changed about your system and whether anything needs your attention.

Results are available directly in GitHub, and are surfaced in your gjalla dashboard.

If you’d prefer daily, weekly, or on-demand reviews instead of on PR, you can adjust the cadence from Automations.

PR reviews are part of the broader context and verification workflow available after beta onboarding.

Orient the agent

Open your coding agent in the repo and ask it something deliberately architectural, a question that requires it to know the system before answering:

What are our core architecture elements, and which rules apply when changing the auth flow?

A grounded agent will call gjalla state show and gjalla rules show (or the MCP equivalents) before answering. If it just guesses from filenames, re-run gjalla setup and restart the agent session.

Why teams find this useful

One of the most common patterns in early sessions: an agent that would’ve invented a new auth pattern instead pulls up the existing decision and proposes work that fits the system. The architecture isn’t in its training data. It’s in your gjalla state.

Use your coding agent like normal

That’s it. From here on, you have:

  • Steering: agents read the same rules, decisions, and project context before generating code.
  • Native process: skills and rules install into the machinery each agent already uses, so the harness is automatic.
  • Visibility: reviews show what changed, what rules were checked, and what needs attention.

When the harness changes, sync the repo:

gjalla sync

Every supported agent picks up the update on its next session.

After beta onboarding

You can connect a codebase, share rules and context with your team, and review changes against your master spec. Availability depends on your plan and setup.

Your living master spec

When you connect GitHub, gjalla builds a map of your system: architecture, data flows, dependencies, and more. Review it from the codebase’s Master Spec tab. Your agents can use it as context while they build.

Bring your team in

Invite the people whose agents touch your codebase under Team Settings. One consistent set of rules, context, and steering is then available to every engineer and every agent. Custom deployments can group multiple repos into a System for cross-repo context.

If something didn’t work

  • Hook didn’t run on commit: run gjalla setup hooks, or check whether you’re using husky/simple-git-hooks (see the CLI guide)
  • Agent ignored the guidance file: confirm it’s in the repo root and your agent is configured to read it
  • Empty Overview after analysis: Troubleshooting covers the common causes
  • Anything else: email support@gjalla.io with a screenshot. We read every one.

What’s next