What you would ask before you try it.

Access is by invitation. Send us a few lines about one real project: what it is, a task you would hand to a team, and the checks you trust. A person replies, and we talk through whether it is a good fit.

No. Plenty of tools can now run several agents at once. What AceLM adds is what the team is held to: a plan a person accepted, a reviewer that did not write the code, checks that run against the final revision, and a record of all of it that stays with your repository. The aim is to finish larger pieces of work with the proof attached, not to answer faster.

No. AceLM works alongside the tools you already use. It supports several model providers and agent runtimes, and keeps its record in Git with your code. Jack, the CLI, is there when you want a home for the whole team.

Not for small things. A small, low-risk change takes one chat message: AceLM makes it, runs your tests and an independent check, commits it, and replies "done", with no spec, plan, or merge for you to handle. See how. For larger work, delegation is a dial, and policy controls let a team choose review depth and required checks for each kind of work. Much of the checking is done by ordinary programs, which run in seconds, and small subtasks go to fast models. You see progress the whole time. And you can see exactly what each step costs, so you can turn down any that are not paying their way. More on the hard parts.

No. AceLM scales the process to the size and risk of the change. A one-line fix or a small, low-risk change takes a single chat message: AceLM makes it in its own worktree, runs your tests and an independent check, and commits it, with no spec, no plan, and no merge to approve. The full lifecycle with specs, reviewed plans, and release gates is for work that needs it: several files or concerns, a public API, stored data, security, or dependencies. See a small change.

No. A small change skips the paperwork, not the checks. Your tests run, and a checker that did not write the change confirms it does what was asked before it is committed. AceLM commits to your current branch and never pushes. If the request turns out to touch a public API, stored data, security, or dependencies, AceLM stops before committing and proposes the fuller route. How the lifecycle scales.

Model access works with your own provider keys or through AceLM-managed model access. You bring your own key for the model providers you already use, under the terms you already agreed with them. Deck, the engine, runs where your code lives.

Model calls go through Dealer, AceLM's central services. That means the prompts, code, and tool calls sent to a model pass through our servers, just as they pass through the vendor's servers with any other coding agent. The difference is what happens next. You set the retention schedule for your data, for yourself or your team, and we do not keep what you tell us not to keep.

What we always keep is de-identified telemetry: which of our own prompts ran, the model and provider, timing, tokens, and cost, and simple counts. It never includes your prompts or your code. AceLM runs on AceLM's own dedicated servers. Organizations that must meet NIST SP 800-171 can have AceLM hosted in their own environment under a negotiated license.

Model usage is a real cost in any agent workflow, and more agents could mean more of it. We keep it down by handing checks to programs instead of models, using inexpensive models for small subtasks, and giving each step only the context it needs. Reporting tracks tokens, costs, and time per project, and keeps estimates separate from measured numbers.

To be straight about it: in our own work, building something costs about the same as before. The payoff is what you get for it. Better architecture, design, and code quality cut rework and maintenance, so the savings grow over the months that follow, and the product is better too.

Ask a model to check its own work in the usual way and you do mostly get a rubber stamp. AceLM does not review that way. We have developed and proven a review method that lets a model check its own work as rigorously as a second frontier model would; in our testing the two find the same material problems. On top of that, verification rests on things that run, such as tests, regression checks, and scans against the final revision, and people still approve plans and releases. You can add a different model whenever your policy calls for one. How we handle review quality.

Yes. The planner, builder, reviewer, and verifier are agents, not colleagues you have to hire, so one experienced developer can direct a whole AceLM team. You approve the plan and decide on release, and the dial decides how much else comes back to you. When more people join, they work from the same record and the same policy, so nobody has to rebuild the context you already have.