La Jefa

It runs as a GitHub Action on every pull request, which is the only integration point that matters to me: no seats to provision, no desktops to manage, and the cost is a model key rather than sixty licences. The whole rollout is a workflow file and a review of what we let it comment on.

The gaps are the usual ones for a young tool: no identity integration of its own and no retention statement. It comes from a vendor we can already put a contract in front of, which is worth more than any feature here. Approved with conditions: comment-only until we have watched it for a quarter.

The demo is an issue that becomes a pull request while nobody watches. Procurement is mostly done: the GitHub account exists, Business and Enterprise carry policy controls and IP indemnity, and the audit log is the one we already read. Onboarding is a license assignment.

Sixty Pro seats is $7,200 a year, and that is not the number; premium-request credits are, because the agent modes draw on them and nobody budgets a meter that starts after the seat. CI fit is native, the cloud agent runs in Actions. Approved, with an organization-level cap on the meter and a monthly report of who spent it.

The demo is an agent returning a validated object, which is exactly as exciting as it should be. Procurement is short. Nothing to buy, no seats to multiply, nobody holding our data. It emits OpenTelemetry over OTLP, so agent traces land in the monitoring stack we already pay for and the telemetry discussion closes before it opens. Background work runs on a durable queue our platform team already operates.

It runs unattended, so agents sit in the pipeline beside the tests instead of inside one person's editor. Onboarding is brief for anyone writing typed Python, which here is everyone. Approved, with a named owner for upgrades.

The demo is competent and beside the point. What matters is that this is listed free and included with a subscription we already hold, so sixty seats adds nothing to the invoice and nothing to the procurement queue. The connectors an administrator must switch on in Setup mean access is centrally governed rather than configured per laptop. Identity and retention inherit from the platform contract, which legal has already reviewed.

Onboarding is half a day for anyone already writing Apex. Approved.

This is the rare free thing that actually reaches my estate: it executes without a person present, so it can live in a pipeline and produce records rather than impressions. For a platform team trying to answer what our agents actually did last quarter, that is the missing piece.

The caveat is where the traces land. Observability is documented through an external tracing service, which puts prompts and intermediate state in a supplier's system, and that is a data processing agreement I do not currently hold. Approved with conditions: self-managed trace storage, or a signed agreement before the first production workflow.

This is the rare row where procurement is a formality. There is no per-person charge, so sixty engineers cost nothing beyond model consumption, and the organisation maintaining it is one our legal team has already papered, which means no new vendor assessment and no new questionnaire cycle.

It runs unattended, so agents become pipeline steps producing artefacts we can review, and observability is described as part of the framework rather than a separate purchase. Onboarding is about a week for a mid-level engineer, since the model-driven style needs unlearning. Approved.

Procurement is the easy part for once. There is nothing to buy, and the organisation behind it is one we already have agreements with, so the questionnaire is a formality rather than a quarter. The consistent surface across our two main languages means a single set of internal patterns and one set of examples, which is where the sixty-engineer saving actually comes from.

It runs unattended, so agents belong to services rather than to individuals. Onboarding is a week for a mid-level engineer, mostly the orchestration vocabulary. Approved. Condition: decide deliberately where agents are hosted before the default decides for us.

The demo is an editor that fixes a bug while the engineer watches. Teams is $40 per user with SAML SSO, so sixty seats is $28,800 a year before Cloud Agents bill on top at API rates, which is the line nobody budgets. SCIM, audit logs and auto-run controls sit on Enterprise at custom pricing, and auto-run controls are the item security will insist on, so Enterprise is the real tier. Onboarding is trivial; half the engineers already use it.

Approved with conditions: Enterprise pricing in writing, a monthly Cloud Agent spend cap, and auto-run policy set centrally.

Path controls are the detail that changes my answer. A repository containing several projects with different sensitivity is the normal case in my organisation, and being able to bound which roots an agent may touch is the difference between a tool I permit and a tool I argue about. The licence costs nothing and clears review in one pass.

What is still absent is the estate layer: no console, no directory integration, no audit export, nothing running in a pipeline. Approved with conditions: path restrictions defined centrally and pushed, not left to each engineer.

This is the easy kind of adoption. Sixty engineers already have the parent product on their machines, so there is no new vendor, no new invoice and no new questionnaire for the tool itself. It exposes a documented API server with streaming and a session database, which means our pipelines can call it like any other service and keep a record of what ran. Model spend lands on keys we already issue.

The row records no identity features of its own, so authentication is whatever we put in front of it. Approved with conditions: server mode behind our gateway, and the shell toolset off by default.

The demo is chat inside IntelliJ. Procurement is short: AI Enterprise at $60 per user is $3,600 a month for sixty, on top of IDE licenses we already hold, and centralized management lets an admin preconfigure MCP servers and decide whether engineers may add more, which is the control security will ask for first.

Nothing runs in CI, fine for an IDE feature. Onboarding is zero, the plugin is bundled and the engineers already know the IDE. The remaining question is the credit burn on agent tasks, which the pricing does not forecast. Approved.

The controls exist and they are the right controls. Assets are governed at enterprise, team and individual scope, so a rule my architects write is not something sixty engineers can quietly override, and quotas cap the meter before finance discovers it. An address allow-list and repository isolation answer two questions my security team always asks.

The gap is the contract, since amounts are published in one currency on one portal and my procurement runs in another. Approved with conditions: a quote in my currency, a written retention policy, and directory provisioning confirmed before rollout.

The demo is a plan that steps through the debugger. Procurement: AI Enterprise is $60 per user, so $3,600 a month for sixty, with credits pooled through JetBrains Central and per-user spending limits an admin sets, which is the control that stops one enthusiast from spending the team's month.

The unknown is credit consumption per agent task, which the table does not list, so the pool size is a guess until measured. CI fit exists through the CLI's headless mode. Onboarding is a plugin the IDE already suggests. Approved with conditions: a two-team pilot to measure burn rate before the pool is sized.

This is the shortest procurement note I will write this year. Nothing to purchase, nothing to provision, and edit tracking happens locally, so the residency question that consumes weeks elsewhere does not arise. Sixty developers already have it whether or not I approve it.

What I get for that is small: modest ergonomics, no throughput number I could defend, and nothing that appears in a pipeline or a report. It is a floor rather than a strategy, and it does not compete with the tool I will actually have to buy, which is a separate line in the same budget. Approved.

The demo is a terminal that fixes a test and explains itself. Procurement rides on the ChatGPT contract: Business is $20 per user monthly with SAML SSO, so sixty seats is $14,400 a year from a vendor procurement already knows; audit logs and SCIM are on Enterprise at a custom price, which is where a security questionnaire sends us anyway. If the org is on ChatGPT already, this is a line item, not a project.

Onboarding is a brew install. Approved with conditions: Enterprise tier for audit logs, permission levels locked down by policy, API spend capped.

Two paths and the cheap one is not free. Running it ourselves means a database, a container platform and a named owner, which is roughly a quarter of an engineer indefinitely. The hosted Team plan at $1,590 a year is less than we spend on coffee, and identity federation and the controls I would need for sixty people are in the tier with no published price.

It integrates with nothing in our pipelines, so this is a product surface rather than a build tool. Approved with conditions: self-host, one owner, and no customer data in it until retention is settled.

The demo is a multi-agent team traced in the adk web UI. As a dependency: maintained by Google, $0 for sixty engineers, and when agents run on Google's runtime, support and SLAs come through the cloud agreement procurement already signed, which turns a framework question into a line item we already have.

CI fit is headless by nature, a framework runs wherever Python or Go runs. Onboarding is a scaffolding CLI and a visual debugger, so a mid-level engineer has a working agent on day one. Approved with conditions: cloud terms reviewed for agent data, and the deploy target agreed before the first service ships.

The demo is a triage agent handing off to two specialists. As a dependency it costs sixty engineers $0 in seats, the tokens land on an OpenAI contract procurement already signed, and support is a GitHub issue tracker rather than a phone number, normal for a library and unusual for something in production.

The procurement question is tracing. Built-in tracing lands on OpenAI's platform by default, so a span may contain a customer record before anyone has read the retention terms. Onboarding is a day for a mid-level Python engineer. Approved with conditions: the tracing exporter reviewed by security, and disabled until it is.

One sentence on the demo: the agent ran somewhere I could point at on a diagram. That is the whole value. It deploys on our own infrastructure, so residency and retention are answered by where we put it, the brokering layer gives security a record of what each agent called, and it runs unattended in our pipelines rather than only on a laptop. The obstacle is the missing number on the paid tier, which turns budgeting into a negotiation.

Onboarding is two weeks including the platform work. Approved with conditions: a named owner and a quoted annual price.

Finally, pricing that does not multiply by headcount. The published cloud ladder is EUR 20, 50 and 667 a month, charged for the workspace rather than per person, so sixty engineers cost the same as six. The business tier is billed annually, which is a commitment I have to defend in a budget cycle but a predictable number once defended.

It runs unattended, so it belongs in our pipeline properly, and the self-hosted route answers the residency question outright. Directory integration sits in the negotiated tier. Approved with conditions: self-hosted first, and a named owner for the workflows.

The demo is an agent that fixes a bug in an existing repository, built in an afternoon. As a dependency: maintained by Anthropic, callable through Bedrock, Vertex AI and Foundry, so it lands on an invoice we already pay; sixty engineers add $0 in seats and whatever the tokens cost, which is the number nobody budgets. Products may not use claude.ai subscriptions or be called Claude Code, so legal reads the terms once.

Onboarding is a package install and a key from the cloud contract. Approved with conditions: API spend caps per team and a review of any product that ships it externally.

Procurement is a formality here: nothing to sign, nothing to negotiate, and a licence my legal team reads once. The work lands on my platform team instead, because sixty installations configured individually means sixty places a provider setting can drift and no central answer to which model touched which repository.

It does not run unattended, so it never appears in my pipeline metrics and never becomes a dependency of a build. That limits the upside and also limits the damage. Approved with conditions: managed configuration, and provider settings pushed rather than chosen.

Procurement is half solved and half opaque. Access control needs no new vendor because it is the same account my team already administers, and runs execute on CI/CD runners we already budget, so there is no separate compute line. That is the easy half.

The hard half is the meter. Duo Pro and Duo Enterprise are per-seat add-ons without a published figure, and platform usage consumes Credits bought separately, so I cannot hand finance a number for sixty people before a call with sales. Approved with conditions: a quoted annual cap, and Credits alerting wired to my dashboard, not theirs.

This is the first open framework this quarter that anticipated my questions rather than deferring them. Spend limits enforced by the runtime, approval gates as a first-class step and redaction before data leaves are three separate projects my platform team does not have to run, and durable sessions mean a long-running task survives a restart.

The costs are staffing and support: it is a framework we would operate ourselves, with a public issue tracker as the escalation path. Licensing is free across all sixty developers. Approved with conditions: one owning team, and the cost ceiling configured before the first deployment.

The enterprise checklist is genuinely answered: deployment inside our own network boundary, policy enforced below the application layer, and audit trails that exist without me asking. That is more than most of this category offers and it is why this gets a meeting.

The cost is the meter. An entry seat is twenty dollars and the included allowance spans a twenty-seven-fold range, with top-ups sold in blocks, so sixty developers could be a modest bill or an alarming one depending on behaviour nobody can forecast. Approved with conditions: a contractual spend cap and per-team unit reporting from day one.

This is the cheapest rollout on the board. One marketplace identifier goes into the extension allowlist we already maintain, and sixty engineers have it the next time the editor restarts; no new application, no packaging, no endpoint exception. That is a memo, not a project.

What it does not solve is spend. Each engineer still brings their own agent and their own subscription, so I get no consolidated invoice and no view of what is being used. There is no audit trail and nothing runs in a pipeline. Approved with conditions: a standard configuration pushed with the extension rather than sixty personal ones.

Configuration is the reason this is easy. One place defines behaviour for everybody and a project-level file lets a repository override it, so I can set the model, the tools and the limits without visiting sixty machines or trusting sixty developers to read a wiki page. That is a rollout memo rather than a project.

What it will not do is run unattended, so it never becomes a measurable pipeline step, and the permissive licence means legal review is a formality. Approved with conditions: the global configuration is owned by the platform group and shipped with the plugin.

The boring answers are good for once. No seat cost across sixty engineers, so the only bill is model spend on an account we already reconcile. It runs as a step in the pipeline rather than as a service, so there is no vendor holding our source.

What is missing is a console. There is no central place to see which repositories run it, which model each one uses or what any of it cost last month, so governance is whatever our pipeline templates enforce. Onboarding is a merge request. Approved with conditions: templates owned by the platform team, and a spend limit on the provider key.

Sixty developers, one npm command, no licence line: the finance answer takes ten seconds. The operational answer takes longer, because a globally installed package on sixty machines is sixty versions unless someone owns the pinning, and nothing here reports centrally on what it found or what it cost.

It does run unattended, which puts it ahead of most of this shelf. No single sign-on, no directory sync, no audit export. Approved with conditions: pinned through our own package policy, run in CI rather than on desks, and reporting into the same dashboard as every other gate.

This is the shape I can approve. It sits in the pull-request path where sixty engineers already are, so onboarding is a webhook and a memo rather than a training session, and there is no per-seat line. One Docker container on Linux, a database we already run, and the spend is the model spend.

The dashboard reports cost per repository and per model, which is the number finance asks for and no review vendor has ever given me. Self-hosting means the code never leaves our network, which shortens the security questionnaire to nothing. Approved with conditions: start on two repositories and compare the comment volume.

A budget the tool enforces is worth more to me than any capability in the row. Everything else on this shelf tells me what was spent; this refuses to spend past a number I set, which converts an open-ended liability into a line item. Across sixty engineers that matters.

It also runs unattended, so it can be a pipeline step rather than a desktop habit, and it installs from a package index we already mirror. No single sign-on, no directory sync, no audit export. Approved with conditions: budgets set centrally, the package pinned in our index, and a named owner for every repository it runs against.

Tenancy separation expressed as policy, rather than as a convention engineers are asked to respect, is what lets one deployment serve sixty developers across teams without me writing the separation myself. Approval steps for consequential actions are built in, so the control I would otherwise bolt on is already part of the workflow definition.

Licence cost is nothing and it executes unattended, so it can carry scheduled work with records attached. The gap is a supplier: support is a repository. Approved with conditions: my platform team owns the deployment and the upgrade path.

The demo is a workflow that pauses for approval and resumes. As a dependency: maintained by LangChain Inc, the library costs sixty engineers nothing, and it runs in whatever CI already runs Python. The paid path is LangSmith Deployment at $39 a seat on Plus, $2,340 a month for sixty, and SSO waits in the Enterprise tier at custom pricing.

Onboarding is the real cost: graphs are a new mental model and a mid-level engineer needs a week with the docs. Approved with conditions: the library now, LangSmith only after a retention review, because traces contain prompts and prompts contain data.

The demo is a terminal that fixes a failing test. Team standard seats are $20 per seat per month with SSO; audit logs arrive only at Enterprise, priced as seat plus usage, which is the tier a security questionnaire will require. Sixty engineers on standard seats is $14,400 a year before anyone hits a limit, and agentic workloads are exactly the ones that hit limits.

Onboarding is an npm install and a login. Approved with conditions: Enterprise tier, hooks enforced by policy so verification is not optional, and a monthly usage report by team.

As a library this never reaches procurement, which is fine, and whatever my engineers build with it becomes a service my platform team runs, budgets and pages on. That is the usual trade and I am used to it.

The part that is not usual is the shipped browser extension. Anything that installs into a developer's browser and reads the page they are on is a data path my security review has to approve separately from the framework itself. Approved with conditions: the library yes, inside a service we operate; the extension no, until it has been through review.

This is the first row this quarter that answers my hardest question before I ask it: inference can be self-managed inside our infrastructure or fully air-gapped, on the orchestration platforms my team already runs, which means the data protection review is about our own network rather than a vendor's promises. Automation is covered too, with a documented unattended command and a supported continuous integration path.

What I do not have is a number, because enterprise pricing goes through sales, and the desktop client is macOS with Windows in beta. Approved with conditions: a self-managed deployment, a fixed-term price, and an SSO commitment in writing.

The demo is an agent in a notebook. Procurement is about the platform behind it: LangSmith Plus is $39 a seat, $2,340 a month for sixty, and the sign-on on that tier is Google and GitHub login, not SAML. Custom SSO, RBAC and self-hosted deployment are Enterprise, priced by conversation. Traces contain prompts and prompts contain customer data, so the retention question goes to legal before the seats go to finance.

CI fit is fine, it is Python. Onboarding is a week of reading for a mid-level engineer because the ecosystem is wide. Approved with conditions: library now, platform after the retention review.

The demo is a curl command, which I appreciate. Sixty seats cost nothing and the meter belongs to whichever agent sits behind it. This is the unusual case that fits our pipelines natively, because an HTTP process is something my platform team already knows how to run behind its own authentication and its own logging. What the row will not give me is identity: no SSO, no SCIM, no audit log, because this is a component rather than a product.

That is acceptable inside our own perimeter and unacceptable outside it. Approved with conditions: internal network only, and one named team owns the deployment.

Finance has nothing to approve. Security does. Code that reaches the browser of every customer gets a supply-chain review, a version pin and a place in our dependency monitoring, which is a standing cost measured in review hours rather than dollars, and one my platform team has to accept before the first team adopts it.

The Slack and Teams channels are the part my internal-tools group would actually use, because that is where our people already ask questions. Onboarding a React engineer is a day. Approved with conditions: pinned versions, a named owner, and no customer-facing use before an audit.

This is the rare case where adoption is a smaller decision than it looks, because the boring parts are already solved. Agent workloads inherit the security posture, the reliability behaviour and the observability we configured for everything else, so an incident here reaches the same on-call rota through the same alerts rather than through a developer noticing.

The limits are ordinary. It is a library in one language, so the cost is engineering time and the audience is the teams who write in it. Approved with conditions: it ships inside services my platform group already operates, never as a tool handed to developers.

There is no seat cost and no procurement, because there is no product. It is a dependency inside an application that already has our SSO, our audit trail and our retention policy, which makes this the quietest way anything on this board enters my estate.

What it does add is a new outbound path to a model provider and a new spend line nobody has budgeted. Onboarding is a day for anyone who knows the codebase. Approved with conditions: provider spend capped in the service, and no agent action reaching a customer without a review.

The demo is a bot commenting on a pull request. Procurement: Essentials at $24, Team at $48 and Advanced at $72 per developer means sixty seats costs $1,440, $2,880 or $4,320 a month, with no credit meter on top, the first review tool on this board I can put on a purchase order without a forecast. The vendor's own precision number says to expect noise, so the throughput gain is smaller than the demo.

Onboarding is an app install and a config file. Approved with conditions: SSO and retention terms confirmed in writing at Team or above.

The demo is a task queue in the cloud. Procurement: Business at $20 per user is $1,200 a month for sixty, extra usage is bought as credits priced per model, and Enterprise and Edu tiers sit above, the shape procurement already knows from ChatGPT and the same admin console. The account is the ChatGPT workspace we already administer, so identity is solved by inheritance. Headless runs suit CI.

Onboarding is a repository connection and an environment file, an afternoon per repo. Approved with conditions: a credit ceiling per workspace before rollout, and secrets scoped per environment.

The demo is spec generation, and it maps onto how a team actually works, because the spec is the thing the tech lead would have asked for anyway. Procurement: Pro at $20 per user is $1,200 a month for sixty seats before overage, and the enterprise tier lists centralized billing, SSO, usage analytics and security controls.

CI fit is the headless CLI, which a pipeline can call with a restricted tool list. Onboarding is an IDE install and a steering file. Approved with conditions: disable automatic overage and set per-team credit budgets first, because a credit meter with an overage switch is a budget with a hole in it.

One sentence on the demo: it found a real bug and one imaginary one. The commercial case is that this is not a new purchase, it is a line inside an agreement my procurement team already processed, so the security review, the data terms and the invoice are all settled work. At $2,400 a month for sixty it competes with a dedicated review vendor and saves us managing a second relationship. It attaches to pull requests as a check, so nothing changes in our pipeline.

Onboarding is a dashboard toggle. Approved.

The demo knows the Jira ticket. Procurement: $20 per developer per month, $1,200 for sixty, with a 30-day free trial for the pilot. The hosted models run under zero-data-retention terms, which answers security's first question, and identity rides the Atlassian account we already administer, so SSO is already done. Headless mode exists for CI.

Onboarding is an afternoon for anyone who has used the Atlassian CLI, a day for anyone who has not. Approved with conditions: a credit budget per seat before rollout, and the overage line reviewed monthly.

This is the first tool in the category that answers the questionnaire without a follow-up call. Access control, directory login and an audit trail are product features rather than an upgrade tier, and the spend caps are the item I never get: a ceiling I set per team, before the invoice, instead of an alert after it.

The cost is headcount. Agents are declared as Terraform resources and run as scheduled workloads, which fits how we already deploy, but it needs the platform team that deploys them. Approved with conditions: the platform team owns it, and no product team gets a cluster.

Observability as a first-class concern is the feature that decides whether something is operable. Services built on this emit into the monitoring my platform group already runs, which means an agent failing at three in the morning reaches the same rota through the same alerts as everything else, rather than through a developer noticing something odd the next day.

There is nothing to install on desks and no console, because it is a library. The real cost is engineering time in one language plus the model spend those services incur. Approved with conditions: platform-operated services only, with spend attributed per service.

This is the cheapest adoption on the board for an organisation like mine, because the expensive part of adopting anything is usually the operational surface it adds. Here there is none: the agent ships inside services that already have logging, deployment, alerting and an on-call rota, so what changes is a dependency rather than an architecture.

It is a library, so there is no console and nothing for developers to install. The real cost is engineering time and the model spend those services incur. Approved with conditions: it ships inside services my platform group already operates, with spend attributed per service.

Three languages is the detail that decides adoption here, because the team that has to integrate this does not have to learn a fourth. It runs unattended, so it becomes a step in a pipeline rather than a habit on sixty desks, and a step in a pipeline is something I can measure and turn off.

What is absent is everything around it: no console, no single sign-on, no directory sync and no audit export, so whatever governance exists is governance we write. Approved with conditions: it lives inside a service the platform team owns, with a named owner for the service.

The default is the whole reason I am reading. Native operating-system isolation switched on without anybody choosing it means the risky behaviour is contained on machines where nobody configured anything, which is most machines. Docker is offered as an alternative and so is turning it off.

The rest is the usual shortfall: no single sign-on, no directory sync, no audit export, and it does not run unattended, so it never becomes a pipeline number. Sixty seats cost nothing beyond the provider keys. Approved with conditions: that setting managed centrally, and nobody permitted to turn it off on their own.

Distribution is where these tools usually die and this one is alive. A signed and notarised universal build removes the security conversation, and a cask that updates itself removes the version drift I spend most of my time on. That combination is worth more to me than any feature.

The Linux side is a beta with an AppImage and a package, which is fine for volunteers and not for a standard. No single sign-on, no directory sync, no audit export, nothing in a pipeline. Sixty seats cost nothing. Approved with conditions: the Apple side rolled out through the cask, the Linux side left to individuals until it leaves beta.

Somebody here has met a security team. Signed releases with provenance attestation and an installer that verifies before it executes turn the riskiest line in any open-source rollout into a paragraph I can put in the questionnaire and move on. Across sixty engineers that is worth more than a feature.

The rest is thinner. No single sign-on, no directory sync, no audit export, and it does not run unattended, so it never becomes a pipeline step I can measure. The model spend lands on subscriptions we already hold. Approved with conditions: developer machines only, and the parallel dispatch capped by policy rather than by habit.

One sentence on the demo: it commented usefully and it commented a lot. The arithmetic is straightforward at $1,260 a month on the monthly rate, less if we commit for a year, and the editor plugin can go to every engineer at no cost, which is a rare thing to be able to say. It runs on pull requests as a check, so it fits our existing flow without a new pipeline. The business tier is custom, which is where the controls conversation goes.

Onboarding is half a day. Approved with conditions: standards agreed first, blocking gates second.

This is the cheapest thing on the board for a team our size. It arrives as a workflow file of about a dozen lines, runs on our own pipeline minutes, and identifies itself with the repository's built-in token, so there are no user accounts to create, no directory to synchronise and nothing to revoke when somebody leaves. Cost is pipeline time plus whatever the model provider charges.

The data question is the only real one: our diffs go to whichever provider we key, and that choice is ours to make and document. Onboarding is a merged pull request. Approved with conditions: one owner, one provider decision, written down.

The finance case is the easy one: $19 per user per month, $1,140 a month at our headcount, on a bill our finance team already processes and under a contract our lawyers signed years ago. The administrative controls we need for a rollout are in the paid tier rather than sold separately, which avoids a second negotiation.

Rollout is a plugin push to four editor families plus a chat integration, so onboarding for a mid-level engineer is an afternoon. Support is a vendor with a support organisation, which is the part startups cannot match. Approved.

Four code hosts are supported, and we run three of them, so this is one deployment rather than a per-host negotiation. Running it ourselves means no seat licence at all and inference billed to an account finance already reconciles, which makes the sixty-developer figure a compute line rather than a contract.

A command-line entry point means it runs as a pipeline step, not only as a webhook, so coverage is enforceable. Identity integration and retention terms are not documented for the hosted edition. Approved with conditions: self-hosted only, behind our own gateway.

The security surface is more thought through than the category average. Keys are isolated per agent, egress can be restricted by allowlist, and the container is ours to configure, so the controls my team applies to every other workload apply here without inventing anything new.

It also runs unattended, so it becomes a measured step rather than a desktop habit. What it does not have is identity: no directory integration and no audit of who launched what, which at a hundred agents is a gap. Approved with conditions: a named owner for the hosts and an inventory before we pass one team.

The automation story is what earns this a meeting. An unattended run returns exit codes my pipeline can branch on, and there is a documented recipe for wiring it into our forge's automation, which means it becomes a check rather than a habit. Licensing is zero across sixty engineers and the spend lands on provider keys we already issue and can already attribute.

Against that, the row records no single sign-on, no SCIM and no audit trail, and the vendor is one publisher with no support terms. Onboarding is under an hour. Approved with conditions: pinned version, keys issued centrally, and no production credentials in reach.

The approval gate is the part procurement can use. A documented interruption before a tool runs means an operator can be inserted into the loop by policy rather than by convention, and that is the difference between a control and a hope. I would make it mandatory in anything we deploy.

Everything else remains ours. No console, no identity integration, no retention statement, and nothing that runs unattended, so this is a component my platform team wraps in a service and operates. Approved with conditions: approval gates on, and one owning team accountable for the spend.

Cost is the easy part: nothing, for sixty engineers, plus whatever the model endpoints bill. The hard part is that it does not run unattended, so a flow cannot be executed as a gate in the pipeline and regressions are found by a person clicking. Anything that reaches customers this way reaches them untested by us.

Single sign-on, audit trails and retention policy are not documented for the self-hosted deployment, and support is a community repository, not a contract. Onboarding is genuinely cheap, a couple of hours. Approved with conditions: prototypes and internal tools, nothing customer-facing.

Financially this is the easiest approval of the quarter: nothing per seat, and inference billed to an account we already reconcile. The open licence means legal review is a formality rather than a negotiation.

Operationally it is sixty independent installations. There is no administrative console, so model configuration, key distribution and version drift are all mine to solve with the tooling I already use for desktops. It does not execute unattended, so it never becomes a measurable pipeline step. Approved with conditions: managed deployment, and keys issued centrally rather than by developers.

Spend is tracked in the product, health is monitored across the fleet, and each agent is contained separately, which are three of the four things I normally have to build myself. Self-hosting means the data question answers itself and the cost is infrastructure my team already runs.

The fourth thing is identity: no SSO, no SCIM, and nothing mapping an action to a person in my directory. Sixty engineers sharing a fleet without that is an attribution gap. Approved with conditions: identity integration on the roadmap in writing, and a spend ceiling per agent.

The demo is a familiar editor agent plus a CLI. Procurement: Teams is $15 per user, so sixty seats is $900 a month before gateway usage, the cheapest seat here that covers both VS Code and JetBrains, so the two editor camps get one invoice. The acquirer is a vendor procurement may already know from the data team.

CI fit is real, the CLI runs headless, and onboarding is an extension install with a shared config. Approved with conditions: SSO and retention confirmed in writing, and gateway spend capped per team, because a pay-as-you-go gateway is a meter with sixty hands on it.

The demo is an agent that finds the right file in a monorepo, which is the demo our engineers actually ask for. Procurement: Business pools usage across up to 50 seats, so sixty engineers means Enterprise, where SSO, OIDC and SCIM live anyway, and a pooled meter means one team's heavy month is everyone's budget. Every plan lists SOC 2 Type II, CMEK, audit trails and exclusion from training, which clears most of the questionnaire before the call.

Onboarding is an extension install and an index build. Approved with conditions: Enterprise contract, a monthly usage ceiling per team, and a report showing who spent the pool.

Finally something built for operators. Runs happen behind an interface my platform team controls, it executes without a human present so it becomes a pipeline step we can gate on, and the spend is metered infrastructure rather than sixty seats, which my finance team already knows how to forecast.

What is missing is the identity layer: no directory integration and no user model, so access control is whatever we build in front of it. Approved with conditions: it sits behind our own gateway, and no engineer reaches it directly.

Flue is useful for internal platform teams looking to assemble customized TypeScript agents rather than purchasing turnkey seats. It handles agent harness primitives like sessions, durable recovery, subagents, and Model Context Protocol client connections. Deployment targets include local CLI runs, Node.js, Cloudflare Workers, and headless CI pipelines, which fits existing deployment patterns without introducing proprietary seats.

The trade-off is operational ownership. The framework is open-source and free, but your team pays the unmetered model provider invoices under a bring-your-own-key model. Without native SSO or vendor audit logging out of the box, compliance rests entirely on your custom backend deployment. Approved with conditions.

The unit is unusual and I have mixed feelings about it. Only developers who open at least two pull requests a month against an enabled repository count, so of sixty engineers perhaps forty bill in a busy month and thirty in a quiet one, which is fairer than seats and impossible to forecast to the finance team.

Enabling it per project and per repository is the control I need, so exposure can be grown deliberately. It is an add-on to a subscription we already hold. Approved with conditions: two repositories first, and a three-month billing history before we widen it.

An evidence chain per change is the most useful thing on this row for me. Screenshots, commands, console output, test results, video, network captures and diffs are collected so a reviewer can accept or reject on the record rather than on a summary, and that record is the thing an auditor asks for.

What is missing is identity: no SSO, no SCIM, and no mapping from an action to a person in my directory. Self-hosting answers residency and costs infrastructure. Approved with conditions: identity in front of the browser interface before anyone outside one team gets a login.

The deployment model is what gets this through procurement. Source stays on infrastructure we control, which removes the single objection that kills most assistants in review, and sixty desks cost nothing. That is a shorter meeting than I am used to having about this category.

What is missing is everything after the install. No single sign-on, no user provisioning and no audit trail are documented, so I would be running a service with no idea who used it or what it read. It does not execute in a pipeline either, so it never becomes a step I can measure. Approved with conditions: one team first, behind our own identity proxy.

The prerequisite is the project. Containers by default means a working container runtime on every developer machine, licensed and supported, which on this fleet is a piece of work with its own budget line. Where that already exists, the isolation is a straight win and the security conversation gets shorter.

Distribution is a tap or an install script, so version pinning is ours to arrange. No single sign-on, no directory sync, no audit export, and nothing that runs unattended. Sixty seats cost nothing beyond the provider keys. Approved with conditions: only on machines where the container runtime is already managed by us.

The interesting sentence in the description is that it runs in continuous integration. That moves it from a thing individuals install to a thing a pipeline calls, which is where measurable value lives. Cost for sixty people is model spend only, with no seats to negotiate and nothing to renew.

Against that: no identity system, no central log, no vendor to send a questionnaire to, and support is one maintainer with a chat channel. Onboarding is a single install command, so training cost is near zero. Approved with conditions: use it as a pipeline utility with a scoped token, not as the tool we standardise sixty desktops on.

One sentence on the demo: it does the work no engineer volunteers for. Procurement is the easy part, because there is no new vendor, no new agreement and no new security review; the controls come from the account and the console, which our team already administers. What it does not do is fit our engineering workflow at all, since it is a console-driven programme rather than something that runs on our pipelines.

Onboarding is a project plan, not a training session. Approved with conditions: scoped to one wave, with a named owner and a spend alarm.

Somebody here has sat in a compliance meeting. A policy object that blocks personal data before it reaches a provider is a control I can point at in an audit, and a tracer that captures prompts, responses, tokens, latency and errors without anyone editing code is the observability I normally have to build myself.

What it is not is a tool sixty engineers use. It is a library a few of them import into a service we then operate, and there is no console, no single sign-on and nothing to onboard anybody onto. Approved with conditions: it lives inside a service we own, with the guardrail policy set centrally.

This is closer to something I can operate than most of the open projects I see. One deployment serves everyone, so provisioning is central rather than sixty laptops, and unattended execution means jobs can be scheduled and attributed instead of run by whoever remembered. Output arriving in chat is not a gimmick; it is where review already happens.

What I do not have is a written answer on retention, identity federation or a support commitment. Approved with conditions: our own infrastructure, our own model account, and a named internal owner before anyone outside the platform team touches it.

Procurement is trivial and governance is absent, which is the trade. The licence costs nothing at any headcount, and the only new line item is inference the agents consume. Exit codes mean a workflow becomes a pipeline step our existing runners can gate on, which is the part I actually wanted from this category.

Against that: no single sign-on, no user directory, no record of who changed a definition beyond what repository history shows. Approved with conditions: definitions live in a protected repository and changes take the same review as production code.

This one was built for the person who signs the invoice, which is rare enough to say plainly. Environments, model access and task assignment are administered centrally rather than configured sixty times over, and the deployment sits inside our perimeter, so the data question answers itself before legal asks.

What is still missing is identity: no directory integration is documented, so those central controls run against accounts I create by hand. There is no published figure for a hosted seat either, which makes the budget conversation a phone call. Approved with conditions: self-hosted only, single sign-on before the second team.

Provisioning from the directory we already run means joiners and leavers are handled by the process that handles joiners and leavers, and that alone puts this ahead of most of the open projects I am shown. Self-hosting keeps the deployment inside our perimeter, and the licence costs nothing across sixty developers.

What it does not do is run without a person. There is no scheduled or pipeline execution, so this is a desk tool with good governance rather than automation I can measure. Support is a repository. Approved with conditions: internal systems only, and a named owner for the gateway.

A recognisable corporate publisher changes the conversation in my review board, because the questions about provenance, patching and contributor agreements have familiar answers even without a support contract. That is worth more than most features I am shown.

Operationally nothing changes: this becomes a dependency inside a service my team builds and operates, so identity, retention and the on-call rota are ours, and no engineer is handed it directly. Nothing per seat across sixty of them. Approved with conditions: a dependency we own, with the model provider chosen by us.

This is the shape I keep asking vendors for. There is no new identity system, because access is whatever the cluster already enforces, and no separate audit trail, because the record is the one my team already collects. Sixty engineers cost nothing in licences and the compute is a line I forecast anyway.

The prerequisites are real and manageable: a recent cluster version and a certificate manager, both of which we run. It also executes unattended from a webhook or a schedule, so it becomes a measured delivery step rather than a desktop habit. Approved with conditions: one namespace, quotas set, pilot team owning the budget.

The demo is fast and the agent panel is capable. Procurement is a different meeting: sixty Business seats is $1,800 a month before tokens, and the pricing page says SSO, SAML and SCIM are planned but not currently available, which is a sentence that ends the conversation with security before it starts. There is no headless mode, so nothing runs in CI and nothing is auditable centrally.

Onboarding is a day, mostly keybindings. Not yet. Revisit when SAML ships, and ask for audit logs in the same release.

Licensing is zero and the meter belongs to the providers we already pay, so nothing new appears on the invoice. What interests me is the credential pool and key rotation, because it lets one team hold provider keys centrally rather than sixty engineers pasting them into config files, and that alone answers half of a security questionnaire. A documented Docker Compose deployment means my platform team can run it as a service.

There is still no SSO in front of the console and no audit trail attached to a person. Approved with conditions: it runs as an internal service, and keys never leave it.

One sentence on the demo: the reviewer step is the part I liked. Commercially this is the cheapest row on the board, because the plugin costs nothing and the inference can run through a subscription we already hold rather than a new provider agreement, which removes an entire procurement cycle. Against that, there is no console, no policy surface and no identity integration, and nothing here runs unattended in our pipelines.

Onboarding is an hour for engineers already in this editor and irrelevant to everyone else. Approved with conditions: personal tooling, existing subscription only.

Consumption pricing means finance gets an estimate instead of a number, and the estimate depends on how chatty our agents turn out to be, which nobody knows before shipping. A hundred thousand calls and fifty thousand events a month are free, then it is three ten-thousandths of a dollar per call, and anything beyond the standard tier is a conversation with sales.

It runs unattended, which suits our services. The condition is a spend cap and a monthly review before anything customer-facing depends on it. Approved with conditions, and one engineer named as the owner of that meter.

Onlook is useful for design-heavy teams shipping directly to Next.js and TailwindCSS codebases. It provides real-time two-way synchronization between browser DOM changes and source files, running in web containers or locally. Model routing flows through OpenRouter without seat charges for the open-source client. It handles terminal execution, Git operations, and multi-file code updates directly.

The trade-off is governance. There is no SSO, SCIM provisioning, or centralized retention tracking for external model usage across sixty seats. Operating sixty isolated configurations without unified telemetry introduces unmanaged risk for our security review. Not yet.

The demo is an agent answering support tickets in a browser. Pro is $150 a month for three seats and $30 for each seat after that, so sixty engineers is $1,860 a month before the $300 SAML SSO add-on; audit logs and end-user roles are in Enterprise at custom pricing. Telemetry sends an event per agent run by default and is turned off with AGNO_TELEMETRY=false, the first line of any rollout doc.

CI fit is good: it is Python in a container. Onboarding is a week with unusually good documentation. Approved with conditions: Free tier for development, Pro only once SSO is in the budget.

Remote Pane is the part that decides this. The workspace runs on a machine we host and engineers drive it from a desktop app or a phone browser, which means source code reachable from a handset over whatever network it is on. That is a conversation with security before it is a conversation with finance.

Licence cost is zero across sixty seats and the real cost is the CLIs inside it, which we already pay for. There is no directory integration, no audit trail and nothing that runs in a pipeline. Approved with conditions: the remote host on our own network only, and no phone access outside it.

The demo is ten agents on ten worktrees in one window. Procurement: the free plan is capped at one user, so sixty engineers means Pro or Enterprise. Pro at the monthly rate is $20 a seat, $1,200 a month for sixty, and it includes the Linear and Slack integrations we would use. SAML SSO, SCIM provisioning, audit logs, IP restrictions and the SOC 2 Type II report are Enterprise, custom priced, annual only.

It does not run in CI; it is a desktop app. Onboarding is a download and a subscription the engineer already holds. Approved with conditions: Enterprise pricing in writing before rollout.

Procurement will move quickly on this, because the publisher is a company my legal team has heard of and the terms are standard. That is the whole easy part.

Operationally it gives me nothing: no console for sixty installations, no SSO, no audit log, no retention policy and no unattended mode, so it never becomes a step I can measure. The absence of any execution boundary means I would not put it near a machine with credentials on it. Approved with conditions: learning and local work only, on non-production checkouts.

The demo is an agent in a Next.js page. As a dependency it costs sixty engineers nothing and runs in whatever CI already runs Node. The platform is where procurement starts reading: the Starter tier keeps 100K observability events for fifteen days, SSO and SOC 2 documentation arrive at the Teams tier with six months of retention, and RBAC, audit logs and uptime SLAs are in Enterprise at custom pricing. Support on that tier is 8 to 5 Pacific, Monday to Friday, poor for a team in Europe.

Onboarding for a TypeScript engineer is a day. Approved with conditions: the framework now, the platform after a retention and residency review.

Two details make this more adoptable than most of its neighbours. There is an administrative interface, so configuration is a place rather than a folder on each laptop, and setup runs non-interactively, which means my configuration management can install it the way it installs everything else.

What is missing is identity. No SSO, no SCIM, no audit log, so sixty installations produce sixty unlinked histories and I cannot answer who asked for what. Zero licence cost, provider spend uncapped. Approved with conditions: central configuration, and a spend limit per key.

The number that matters to me is the language level. Half my services still run on an LTS release nobody wants to touch, and a library that refuses anything below Java 17 is a library my platform team cannot introduce without a migration project attached. This one does not force that.

Against it, there is no console, no audit trail and nothing to point a security questionnaire at, because this is an import rather than a product. Whatever we build with it is ours to run, log and page on. Approved with conditions: inside a service my team owns, with keys issued centrally.

Cost at sixty is the model bill and nothing else, which is the best answer procurement gets all quarter. It runs unattended, so we can schedule it on hardware we control and keep the spend visible. Two things block a general rollout: platform support covers macOS and Linux only, and there is no console, therefore no single sign-on and no central audit of who dispatched what.

Onboarding is fast for anyone who already reviews pull requests. Support is a community. Approved with conditions: a shared runner, our own access logging, and a named internal owner.

The demo answers in Slack and Teams. Procurement: Teams is $60 a month plus $40 per seat, so sixty seats is roughly $2,460 a month before the rolling rate limits, which are the number nobody can budget. BYOK routes inference through our own model contract, which keeps the data terms we already negotiated. SSO, audit logs and retention are not stated on the pricing page.

CI fit is real, headless mode drops into a pipeline step, and onboarding for a mid-level engineer is a curl install and a login. Approved with conditions: rate limits and retention written into the contract, and BYOK mandated so the model terms are ours.

Sixty seats lands at $1,200 a month on Core and $2,400 on Pro, which is legible budget rather than a meter, and that alone puts it ahead of most of this category in a finance review. A 14-day trial is enough to run it against two repositories before the purchase order.

The blockers are above that line. Self-hosted code hosting and API access are both Enterprise features, so anyone on an internal GitLab is quoting custom before they can pilot. Identity integration is not documented anywhere I can cite. Approved with conditions: Core tier, two repos, and a written answer on retention first.

This is built by somebody who has met a finance department. One instance hosts several organisations, each with its own budget, approvals and governance rules, which means spend can be bounded per team instead of discovered per invoice, and an approval step exists before work begins.

What is still missing is identity: no SSO, no SCIM, no audit log tied to a directory. A server-only mode installs on a headless host, so it can live in our infrastructure rather than on sixty laptops. Approved with conditions: budgets set centrally, and identity mapped before the second team joins.

The demo is a research agent that writes a report and runs the code. Procurement finds more than usual for a free project: OIDC single sign-on is documented, authentication design covers per-user isolation and CSRF, and personal access tokens exist for non-interactive clients. Kubernetes deployment is supported through a provisioner, and the multi-worker gateway requires Postgres and Redis, which is an ops cost but a known one.

Sixty engineers cost nothing in licences and a real platform team in hosting. Onboarding is heavy because the stack is wide. No vendor to call. Approved with conditions: a platform owner assigned and an internal SLA before the first team depends on it.

Sixty seats cost nothing in licence and everything in operations: we host the server, we patch it, we own the uptime, and nobody is on call for it but us. Budget it as a service my platform team runs, not as a tool I buy.

The trigger surface is the part I like. Work starts from a schedule, a webhook or a table event, and approval steps can sit in the middle, which is the first thing procurement asks about automation touching production. No directory integration or audit export is documented. Approved with conditions: server-run agents only, and human approval on anything that writes.

Seat maths first. Sixty people at $20 is $1,200 monthly, at $60 it is $3,600, and at $200 it is $12,000, so the tier choice matters more than the vendor choice, and the tier choice depends on consumption I cannot model before a pilot. The trial is thirty days, which is enough for one team and not for a forecast.

The shell form integrates with pipelines, which is the piece that matters to us. Identity and retention terms are not on the pages I can read. Approved with conditions: entry tier, one squad, and contract answers before the second invoice.

Three things here are unusual for this category and all of them matter to me. It is driven by a manifest with no human in the loop, so it schedules. Attempts can be written to a real database rather than a file, so there is something to query. And a mock engine exists, so my pipeline can test the integration without spending anything.

Against that: no SSO, no audit log tied to identity, and Windows only through a compatibility layer. Approved with conditions: attempts logged to our database, and a spend ceiling per swarm.

This is not a purchase, it is a dependency, and the review that matters is the one my mobile team does before it ships inside a product customers install. There is no console, no seat count and nothing for procurement to sign, which resolves the budget question and creates a different one about what our app is doing on a customer's device.

For sixty engineers it is relevant to the handful writing Swift. Nothing runs in a pipeline, so it never appears in my metrics. Approved with conditions: the mobile team owns it, and the guardrails it ships with are configured before anything reaches a release build.

Give me the inventory and keep the rest. Knowing which MCP servers exist on a machine, and which agents can reach each one, is the closest thing to an access review anybody has offered me for this class of tool. It answers a question I have been putting to vendors for a year.

It is a per-machine view, though, not a fleet view: sixty desks means sixty inventories and nobody to aggregate them. No single sign-on, no central policy, nothing that runs in a pipeline. Approved with conditions: it goes on developer machines as a convenience, and the actual access review stays where it already lives.

Nothing to buy for sixty engineers, and it only helps the ones writing Go, which narrows the audience before we start. The deployment story is a single command that copies over SSH and runs under systemd with no container involved, which is admirably direct and the opposite of every standard we have written down since 2019.

There is no administrative console and no identity story, because it is a library. Support is genuinely purchasable, which is rarer than it sounds and would satisfy the question legal always asks. Approved with conditions: Go services only, and deploy it through our own pipeline.

The demo is a plan and a per-file diff. Procurement is where this product lives: on-premises or air-gapped deployment, SSO, zero code retention, SOC 2 and IP indemnification, which is the whole questionnaire answered on one page. The Agentic Platform is $59 per user on an annual contract, so $3,540 a month for sixty, and the CLI gives CI a path.

The vendor changed hands this year, so legal adds a change-of-control clause and a data-migration term. Onboarding is an installer pointed at our host. Approved.

One sentence on the demo: it reached the goal by a route nobody specified. Commercially this is the easiest kind of adoption, because it enters through the same dependency declaration as every other library we use, with no new vendor and no new agreement. The starter for a major cloud vendor's inference matters more than it sounds, since that contract already exists and the data terms are already reviewed. Nothing here runs unattended on its own.

Onboarding is three days for a platform engineer. Approved with conditions: one service, existing inference contract.

The demo is a review bot with a dashboard. Sixty seats at $30 is $1,800 a month before the credit packs, and credit consumption per review is the number nobody budgets until the second invoice, so finance needs a pilot repository and a month of data. SSO and on-prem are Enterprise-only at custom pricing, which means the security questionnaire waits for a sales call.

CI fit is native, since the product lives on the pull request. Onboarding is a rules file and an afternoon. Approved with conditions: Enterprise quote for SSO, credit burn measured on one repo, and a hard cap on the packs.

Tracker integration is what turns this from a toy into a process. Work arrives from the systems we already use and returns as a reviewable change, so the tool fits between two things procurement approved years ago rather than sitting beside them. Self-hosting also removes the data-residency conversation entirely.

The open questions are ours to answer: no identity integration is described, the sandboxes are infrastructure my team will run, and model spend lands on our keys with no per-task budget I can see. Approved with conditions: our infrastructure, scoped repository access, and a monthly spend report.

Two controls here would survive a security review. Execution tools are confined to a container or a restricted directory with isolation drawn per conversation or per user, and traces are audited by the library itself, so an incident has a record without us building one.

There is no seat cost, because this is a dependency inside a service my team operates, which means identity and retention are inherited from that service rather than purchased here. Approved with conditions: the container path in production, and provider spend bounded in the service that wraps it.

The headless runner is what changes the conversation. A desktop application is a thing sixty engineers each use differently; a binary emitting structured lines on a schedule is a delivery step with a record I can graph. That is the difference between a tool and a control.

Everything else is unresolved. Sixty desktop installs with no central configuration, no identity integration and no audit of which playbook ran against which repository, and the model spend lands on whatever subscriptions people already hold. Approved with conditions: the runner in a pipeline we own, the desktop app on the pilot team only.

This is closer to something I can operate than most of the board. Unattended execution means it belongs to a pipeline rather than to sixty desks, so the cost is compute we already forecast and the ownership question has an obvious answer: the platform team.

What blocks a wider rollout is identity. No single sign-on, no user model and no stated retention behaviour for what the runs record, which is three sections of a questionnaire I cannot fill in. Approved with conditions: one team operates it, non-production accounts only, until those answers exist.

A signed desktop installer from an established vendor removes the two objections my endpoint team raises first, which puts this ahead of almost everything else in the category before anyone evaluates the product.

Then it stops. There is no administrative console for sixty machines, no SSO, no audit log and no retention policy, and it does not run unattended, so it produces no delivery metric. Licence cost is zero and the model spend belongs to accounts my engineers hold. Approved with conditions: managed deployment, and no dependence on it in a documented process.

The storage detail is the one that reaches my desk. Conversations kept across sessions in a database my team operates means whatever users typed is now subject to our retention schedule, our backup policy and our deletion obligations, and none of that is the framework's problem once it ships.

There is no console and no vendor relationship, because this is a dependency rather than a product, so the operational burden is entirely internal. Approved with conditions: a retention policy on the memory store agreed before the first deployment, not after.

It ships a terminal tool, and that is the sentence my security review will stop at. Whatever we embed this in inherits the ability to run commands on the host it lands on, so the question is not whether the library is good, it is what our own product does with a capability we handed it.

There are no seats and no invoice, so this is an engineering decision rather than a purchase. Nothing here runs in my pipeline and there is nothing to audit centrally, because whatever we build becomes ours to log. Approved with conditions: the terminal tool disabled unless a specific feature needs it.

Somebody wrote this for my department rather than for a demo. Sixty people cost nothing because it runs on our own hardware, the health endpoints plug into monitoring my team already operates, and an approval gate on the dangerous actions means the compliance conversation has an answer instead of a promise.

What is missing is the paperwork behind it: no vendor, no support contract, no directory integration named, and per-channel error isolation is a design note rather than a service level. Approved with conditions: my platform team runs it, and the audit export is proven before any regulated process touches it.

The deployment answer is the part I care about. Whatever developers assemble comes out as images we run through the same registry, the same scanning and the same rollout as everything else, so the operational question is answered before anybody asks me. Sixty engineers cost nothing in licences.

What is missing is governance of the thing itself: no accounts, no roles, no audit of who deployed which application against which model. It also runs on two of the three operating systems my engineers use, which is a support conversation I would rather not have. Approved with conditions: the platform team owns deployment.

Nothing to purchase and it needs a Java runtime we have deployed for a decade. Integration with the two frameworks our services already use means the rollout is a dependency addition rather than a new platform, which is the shortest path any of these tools can offer. Traces export to the observability providers rather than into a proprietary console.

Two blockers. The maturity label means we would be signing up to rewrites, and support is a public chat channel plus an issue tracker, with no commitment attached. Onboarding for a Kotlin engineer is a day. Approved with conditions: one service, one team, and a review before it spreads.

This is the rare one that fits where the work already happens. It installs as a job on the pull request, so nobody learns a new tool and nothing changes about how a change gets merged. It also reaches the trackers my teams run, so a finding lands where the work is tracked.

The bill is inference on every pull request, which is a number I can model from last quarter's volume and then cap. There is no seat price and no vendor contract, and therefore no vendor to hold to anything. Approved with conditions: one repository first, and a spend cap before it goes wider.

The demo is a terminal agent. Procurement: Team at $24.99 per user is $1,499.40 a month for sixty, Enterprise is custom, and nothing on the pricing page names SSO, SCIM or retention, which for a European vendor is a surprise, since that is the sales pitch. A headless mode makes CI reachable.

Onboarding is a curl install and a login, and the config file can be distributed centrally even if it cannot be enforced. Approved with conditions: Team now for the pilot, Enterprise once the SSO and retention terms are in writing, and the config distributed from one repo.

The demo is a CEO agent delegating to a team. Procurement liked one thing immediately: monthly budgets per agent with hard stops, overspend pausing the agent and cancelling queued work, and token cost tracked by company, agent, project, goal and provider. That is a finance report I can hand over. What is missing is everything else: no SSO, no audit export named, no support line, and a Node.js 24.11 or newer requirement on whatever hosts it.

Sixty engineers would share one deployment, which is the right shape. It does not touch CI. Approved with conditions: a single hosted instance, SSO behind a proxy, and a retention review.

The demo is five lines. As a dependency: maintained by Hugging Face, $0 for sixty engineers, no SLA, and issues go to GitHub. The concern is the Hub integration: agents and tools can be shared as Gradio Spaces, so an engineer can publish internal tooling, prompts included, with one call and a token that was meant for downloads.

CI fit is a pip install. Onboarding is a morning. Approved with conditions: Hub publishing blocked at the org level, tokens scoped to read, and the executor reviewed before anything runs on a shared runner.

Zero licence cost, and the real cost is operational: this expects a working container runtime on sixty machines, which is a fleet standard, an image policy and a support queue rather than an install command. There is no headless mode, so it stays a desktop habit and never becomes a control I can enforce centrally. Nothing on the row offers SSO, an audit log or a retention statement, because there is no service to attach them to.

Onboarding is an hour for anyone comfortable with branches. Approved with conditions: teams already running containers locally, and no claim to security in the questionnaire.

A dedicated headless permission mode is the detail that matters to me. It means unattended runs are governed by a policy chosen in advance rather than by whatever the interactive default happens to be, so a job in a build pipeline cannot approve its own destructive step. That is a question I ask every vendor and almost nobody has an answer for.

There is still no console, no directory login and no central configuration, so desktop use stays sixty independent setups. Approved with conditions: the pipeline job runs as a service account, and desktop adoption is individual.

This one crosses the line from a tool engineers use into a step I can measure. Structured output means the result lands in the systems my team already runs, and a workflow triggered from a comment fits the review process rather than asking sixty people to change how they work. The licence costs nothing across all of them.

What is absent is everything around it: no directory integration, no audit export, no vendor to call. Approved with conditions: it runs in the pipeline under our own credentials, and it does not get installed on laptops.

Individual tiers are published at $20, $60 and $200, which multiplies out to between $1,200 and $12,000 a month for my headcount, but every one of them is metered in Credits, so the tier is a floor and not a forecast. Team and enterprise terms are quoted separately, which means a call before I can compare anything.

There is no unattended execution, so this never becomes a pipeline step and its value stays whatever sixty individuals get from it. Not yet: I need a quoted cap and a written data handling answer first.

The demo is an agent finding an IDOR. Procurement cares about the workflow: a GitHub Actions job runs strix -n -t ./ in quick-scan mode on pull requests, which is the shape of a control an auditor recognises. The enterprise tier is self-hosted, with dedicated support, custom SLAs and a priority Slack channel, and integrations reach Jira, Linear, GitLab and Bitbucket.

The cost line is blank, because the cloud pricing page is not public, and sixty seats of anything priced by conversation is a quarter of negotiation. Legal must sign the scope, since the tool attacks what it is pointed at. Approved with conditions: a written target list and a quoted number.

Licence cost across sixty engineers is zero and the model spend lands on whichever provider keys we issue, which at least makes the meter ours to watch. The REST API is the part that matters to me, since it means an integration is possible without a human clicking. Against that: the row records no single sign-on, no SCIM and no audit trail, and self-hosting the browser UI puts a service on my platform team's plate with no vendor to call.

Onboarding is half a day for anyone who has run the underlying tool. Approved with conditions: one team hosts it, and provider keys are issued centrally.

Zero per seat across sixty desks, and an application that installs on macOS, Linux and Windows, which is unusual enough to note because it means no group gets excluded. What it does not have is an administrative surface: no SSO, no SCIM, no audit log, no central configuration.

It does not run in CI, so it never becomes a measured step in delivery and the throughput claim stays anecdotal. Onboarding is short for anyone who already uses worktrees and longer for the rest. Approved with conditions: managed installation, and model keys issued by us rather than typed by developers.

The demo is confident. Procurement is where it stops: the published plans each cover up to fifty seats, and I have sixty engineers, so I am in a custom Enterprise conversation before I have a figure to take to finance. The row records nothing about single sign-on, SCIM or retention, which means my security questionnaire goes out unanswered. Windows engineers get this through WSL only, which is a support ticket I can already picture.

In its favour, a print flag gives me a scriptable run, so pipelines are genuinely possible. Approved with conditions: a written SSO and audit commitment in the contract, or no signature.

The arithmetic is clean and that is worth something: a per-user rate with included usage means I forecast a fixed figure rather than a meter, and finance prefers a fixed figure. What it does not tell me is whether a directory integration, an audit export or a retention policy exists, because none of that is on the pages I can read.

There is no unattended mode either, so this improves how engineers work and never becomes a build step I can measure. Approved with conditions: a security questionnaire answered in writing before the contract.

It runs headless and logs events to stdout, which is the sentence that separates a tool from a demo. That means it can sit in our infrastructure, be scheduled by something we already run, and produce output a log pipeline can read without anyone screen-scraping a terminal.

Against that: it holds tracker credentials, and there is no SSO, no audit log and no retention policy describing what it keeps. Sixty engineers' worth of agent runs against one tracker account is an attribution problem. Approved with conditions: a service account per repository, and logs shipped somewhere we retain.

One sentence on the demo: it fixed three things while I watched. The problem is forecasting. The seat line is $1,440 a month and predictable; the review line is charged against processed volume, and the included annual credit is small enough that it functions as a trial rather than an allowance, so a busy quarter and a quiet one produce very different invoices. It runs on every pull request, which suits our pipeline.

Onboarding is a configuration file per repository. Approved with conditions: a hard cap on the metered line.

The deployment detail that matters is the runtime floor: it needs a recent Node release, which means my endpoint fleet has a version requirement before anyone can start, and that is a ticket per machine on the laptops that have drifted.

Nothing per seat, and the model spend sits on provider accounts my engineers already hold. There is no SSO, no audit log, no retention policy, no console, and nothing runs unattended. Approved with conditions: managed runtime versions, and loopback binding enforced by policy.

The demo is a bot summarizing a pull request. Procurement: Team is $24 a seat, so $1,440 a month for sixty, 20% less on annual, with 3x Pro's rate limits, which matters on a busy monorepo. GitHub Enterprise Server and self-hosted GitLab are supported, so our hosts are covered; self-hosting the reviewer itself is Enterprise only. SSO, SCIM, audit logs and retention are absent from the page.

CI fit is native, onboarding is an app install and a config file. Approved with conditions: those four items in writing before the seats, and a rate-limit test on the largest repo first.

Costs nothing for sixty engineers, and it runs without a person present, so agents become pipeline steps that produce reviewable artefacts rather than laptop experiments. The console being deployable on our own infrastructure is the detail that matters most, because agent traces contain prompts and prompts contain whatever an engineer pasted in.

What is missing is the support side: below any negotiated arrangement, escalation is a public repository, and no directory integration is described. Onboarding is a few days for a TypeScript team. Approved with conditions: the console self-hosted, and a support arrangement in writing before anything customer-facing.

Three quarters of my checklist is already here, which is more than I expected. I can see what ran, prove that a result was delivered, read the usage figures per person and restore the whole thing from a consistent backup, and none of that required a tier upgrade or a sales call.

What is missing is identity. There is no single sign-on and no provisioning, so accounts are created and removed by hand and a departure is a manual checklist. Nothing runs in a build pipeline either. Approved with conditions: one team first, and offboarding scripted before the second team joins.

The demo is a pipeline surviving a restart. Procurement is short because there is nothing to purchase: sixty engineers cost zero beyond model spend, which is the meter nobody puts in the budget. It runs unattended, so it becomes a step in the pipeline we already operate without standing up a new runner.

What is absent is everything security asks for: no single sign-on, no audit trail, no retention statement, no named support channel. Onboarding is the other cost, since this is Python only and the decorator model takes a mid-level engineer several days. Approved with conditions: internal pipelines only.

A single service my platform group runs is a completely different proposition from a desktop application on every machine. One deployment, one upgrade, one place to back up, and the engineers reach it through a browser rather than through an installer. That is the shape my organisation already knows how to operate.

What is missing is identity. There is no single sign-on, no provisioning and no audit trail, so the board records what happened without recording who authorised it. Approved with conditions: it sits behind our authenticating proxy, and the review column is not treated as an approval record until it does.

The demo edits files in IntelliJ. Procurement: Standard is $19 per user per month on an annual commitment, $1,140 for sixty, or $1,368 at the $22.80 monthly rate; Enterprise is $45 annual, $2,700 for sixty. Billing rides the Google Cloud account, so the invoice needs no new vendor.

No headless mode, so CI gets nothing, and the tool's value is entirely in the editor sessions of the engineers who use it. Onboarding is an extension install. Approved with conditions: annual only, and measure agent use per seat before renewal, because the seats nobody uses are the ones that cost.

The headless mode is what makes this discussable. orca exec runs in a script or a pipeline, sessions resume and fork, so a failed run can continue rather than start again, and that is the difference between a demo and a step I can put in front of a merge. Nothing per seat for sixty engineers either.

Everything else is missing. No identity provider, no audit export, no retention statement, and support is a repository with one maintainer's name on it. Onboarding is small: install, one key, one config. Approved with conditions: pipeline use only, with the key issued centrally rather than per developer.

The demo is two agents talking a problem into pieces. As a dependency it costs sixty engineers nothing and installs into whatever already runs pytest, so the finance conversation ends in a sentence. What we do not get is a control plane. No admin surface, no central record of which group calls which provider, and no data policy to file, because no counterparty holds anything.

Onboarding is the real number. The surface is wide enough that a mid-level engineer needs a week before writing something we would ship, and abstractions move between releases. Approved with conditions: pin the version and name an owner for upgrades.

The print and JSON modes are the only reason this reaches my desk. They accept piped input and emit structured output, which means it can sit in a pipeline and produce something a build step can act on, and Windows is supported, which most of this category is not.

Everything governance-related is absent: no identity, no audit trail, no retention statement, no organisation behind it. The sixty-seat cost is zero in licence and entirely in provider keys, which I would want issued centrally rather than personally. Approved with conditions: pipeline use with a service key, and nothing interactive on a machine that holds customer data.

The useful half is that work runs without a person present, which means it can be scheduled, measured and attributed, and the emitted deployment stack gives my platform team something familiar to operate rather than a bespoke service.

The awkward half is the install path, which registers a background service and a menu-bar item on developer machines. That is a desktop tool wearing infrastructure clothes, and I would rather one managed deployment than sixty. Support is a repository. Approved with conditions: a central deployment only, and no installer on individual workstations.

Contact sales as the only pricing is my least favourite sentence, and here it costs me a quarter before I can compare anything. What buys back the meeting is deployment: an air-gapped edition exists, which means the source never leaves our perimeter and the security review becomes a network diagram rather than a negotiation.

Runs are scriptable, so this becomes a scheduled job rather than a habit sixty people have to form, and that is the correct shape for a migration tool. Approved with conditions: the air-gapped edition, a fixed-term contract, and a measured pilot on our two largest repositories.

Piped input is a boring feature and it is the one that matters to me. A tool that takes work from a pipeline can be scoped, budgeted, timed and reported on like any other stage, and its output lands in the review process we already run rather than on somebody's laptop.

What is missing is everything about identity: no single sign-on, no directory sync, no audit export and no console, so access control is whatever the runner already enforces. Nothing to license across sixty engineers. Approved with conditions: pipeline use, with credentials issued by us.

Per-run cost and token accounting held in a queryable store is the number I have been asking vendors for all year. It means agent spend stops being a line on a provider invoice and becomes something I can attribute to a team, a repository or a ticket, which is what makes a budget conversation possible at sixty engineers.

What is absent is authentication and authorisation: no directory integration and no user model, so access control is whatever we put in front. Approved with conditions: self-hosted, behind our own gateway, with the accounting exported to finance.

The blocker is the fleet. It runs on macOS and nothing else, so a mixed estate cannot standardise on it and I end up supporting two workflows instead of one. Where the hardware is uniform, the finance side is trivial: no seat price, and the model spend stays on subscriptions we already reconcile.

The build is signed and notarised, which is the one line that makes distribution through our device management a form rather than an argument. There is no single sign-on, no audit trail and nothing that runs in a pipeline. Approved with conditions: uniform hardware, managed distribution, and no expectation that it reports anything upward.

One sentence on the demo: it did something useful while nobody watched. The commercial shape is unusual and in our favour, because the meter follows the workspace instead of the headcount, so adding engineers does not change the invoice. What does change it is overage, which is prepaid on every tier and therefore a second budget line nobody remembers to forecast. Identity integration is not documented anywhere I can find, and nothing here runs inside our pipelines.

Onboarding is a configuration file and an app install. Approved with conditions: one team, overage capped.

Read the deployment before the features. An AppServer we host is an internal service: a machine, a patch cycle, a backup policy and someone on call. In exchange sixty engineers pay no licence fee, and the model spend lands on keys we already reconcile.

For a shared service the access question is not optional, and there is no single sign-on, no directory sync and no audit export in the row. Nothing runs unattended either, so it reports no number into anything I read. Approved with conditions: one instance behind our identity proxy, owned by the platform team, with a named service owner.

The deployment shape is better than most of this category. A server component runs on a machine we operate with clients attaching to it, so this is a service my platform team can put behind existing controls rather than sixty unmanaged desktops. That is a real difference at my scale.

What the server does not bring is any governance. No accounts, no roles, no retention policy and no record of who attached to which session. Cost is the coding subscriptions we already pay for, which is a number I have. Approved with conditions: the server behind our proxy, one team on it first.

It takes the task as a command-line argument and runs to completion, which makes it scriptable, and scriptable is the only property I need before a tool can live on a build agent. Windows is supported too, so unlike most of this category it covers my whole estate.

What it does not have is anything else procurement asks for: no console, no audit, no identity, no vendor. The interesting use is not sixty desktops but one runner doing a repetitive job cheaply against a model we host. Approved with conditions: pipeline use for narrow, well-specified tasks, and a human on every diff it produces.

Testing agent behaviour has been the thing I could not budget, because every run costs tokens and nondeterminism makes the result meaningless. A recorded execution replayed in our automation changes that arithmetic completely: the check costs compute minutes we already buy, and it fails when behaviour changes.

What is missing is a supplier, a support commitment and any operational tooling, so my platform team owns it entirely. Onboarding is a week. Approved with conditions: one service, our own log storage for the recordings, and a named owner.

This is not a tool I roll out, it is a dependency somebody adds, which changes my question from procurement to governance. It arrives through the same artefact repository, the same version pinning and the same review my build already applies to every library, so the control already exists.

The language baseline is met and the cost is engineering time rather than licences. What I own afterwards is the service my team builds with it, including model spend, logging and the on-call rota. Approved with conditions: it belongs inside a service my platform team runs, not in sixty engineers' hands.

The install is the easiest part of my week: one command and a service my platform team runs wherever we already run things. Scheduled tasks are a genuine operational feature, because an assistant that acts on a timer is one I can put on a runbook rather than in somebody's browser tab.

Everything above that is missing. No accounts, no roles, no retention policy, and nothing producing a record of which agent did what for whom. Sixty engineers cost nothing and govern themselves, which is another way of saying nobody governs them. Not yet: identity first, then a pilot team.

The financial review is over in a sentence and the security review is not. A phone application that approves changes and queues work extends the trust boundary to hardware outside our fleet, and my questionnaire has four pages about exactly that. There is no directory integration and no central policy to lean on.

Operationally it stays on the desktop and never becomes a measurable step, so throughput claims cannot be verified against anything we track. Approved with conditions: laptops only, phone companion disabled until mobile device management covers it.

The demo is a review comment that cites the right file. Procurement: Team is $12 a seat on annual, so $720 a month for sixty, or $1,200 on Professional, the tier with Jira and Confluence. Self-hosted is a $5 per seat add-on, another $300, which is cheap for a deployment security will prefer. SSO and SAML sit in Enterprise, so the cheap tiers assume shared logins. SOC 2 Type II is stated.

Onboarding is a Git app install and a config file per repo. Approved with conditions: an Enterprise quote for SSO, and self-hosted if the questionnaire asks where the diff goes.

The ledger is the reason I am still reading. A running record of what the agents spend is the number I have been asking every vendor for, and here it exists. Set against that, Windows support only through WSL means a third of my engineers get a support burden rather than a tool.

The rest is unchanged: no single sign-on, no directory sync, no audit export, nothing that runs in a pipeline. Sixty seats cost nothing and the spend still belongs to whichever subscriptions the engineers hold. Approved with conditions: Linux and macOS desks only, and the ledger reviewed monthly by someone who is not the person spending.

The useful fact is that it runs unattended. A wrapped CLI driven programmatically can become a pipeline step, which means this can produce a number rather than an anecdote. The administration story is one embedded dashboard per installation, so what I get is sixty local views and no fleet view.

Distribution is a global npm package, which makes version pinning our problem on every machine that has one. No single sign-on, no directory sync, no audit export, and the model spend stays on whichever subscriptions the wrapped CLIs use. Approved with conditions: run it in CI where we control the version, not on sixty desktops.

The commercial shape is fine: no seats, no licence, and the running cost lands on an infrastructure account we can already budget and monitor. If we hold that vendor relationship, the governance is our existing governance. Deployment is one button, which is genuinely a memo rather than a project.

What it does not do is fit how we ship. Output is a deployed application, not a change a reviewer approves, and it covers one language family, so it never reaches most of the team. Approved with conditions: internal tools and prototypes only, on a separate account, with export required before anything is treated as a real codebase.

Two channels is one more than I want. The desktop app is signed and notarised on all three platforms, which passes review and installs through the tooling we already use. The terminal build is a global npm package, which is sixty unpinned versions unless somebody owns it, and both will end up on the same machines.

Beyond that the usual gaps: no single sign-on, no directory sync, no audit export, and nothing that runs unattended, so it never becomes a step I can measure. Sixty seats cost nothing beyond provider keys. Approved with conditions: the desktop build only, distributed by us, and the npm route blocked by policy.

Zero cost for sixty engineers and the runtime requirement is one we met years ago, so infrastructure has no new argument. Agents become components inside existing services, which means our deployment, monitoring and on-call arrangements already cover them. That is the cheapest possible adoption curve.

The administrative console is the part that needs a decision. It is another application to host, another surface to protect, and there is no described identity integration for it, so it would sit behind our own controls or not at all. Onboarding is short for a Spring developer. Approved with conditions: framework yes, console only behind our own access layer.

Three thousand a month for my headcount is a legible number, which already puts this ahead of half the shortlist, and a fourteen-day trial of the paid tier means the pilot costs nothing. The output lands as a pipeline check rather than as another dashboard, so adoption does not depend on sixty people forming a habit.

What I do not have is a data answer. Capturing production traffic means customer data enters a supplier's system, and that is a processing agreement and a review, not a checkbox. Approved with conditions: one non-customer-facing service first, with the traffic filter agreed in writing.

The remote mode is what makes this interesting to me rather than to individuals: agents run on servers my team provisions, so the compute is centrally managed and the laptops stay quiet. That turns a personal tool into something resembling infrastructure.

Two things hold it back. The licence is strongly copyleft, which is fine for internal use and a conversation if it ever touches a shipped artefact, and nothing here runs unattended, so it produces no scheduled work and no records. Approved with conditions: internal use only, remote workspaces, and a licence note on file.

Permissions that follow the branch rather than the whole workspace is the first control model in this category I could actually map onto how my teams are organised, and self-hosting keeps the source inside our perimeter. Those two facts get this to a second meeting.

What holds it there is that a person has to be present for anything to happen, so it improves how sixty developers work and produces nothing my reporting can consume. The licence needs counsel's opinion before rollout. Approved with conditions: internal deployment, licence review, and one pilot team.