Frequently Asked Questions

Token Engineering & Product Information

What is Token Engineering?

Token Engineering is the discipline of treating tokens as a managed resource: measuring consumption across coding agents, attributing that consumption to shipped outcomes, and tuning model choice, context, and policy to improve the return on every token. Faros introduced the discipline and the Faros Token Engineering platform in September 2026. On this page, lead time and cycle time measurement are discussed as critical velocity metrics—Token Engineering provides the observability and control needed to optimize these metrics by connecting token spend to engineering outcomes and automating measurement across systems.

What does Faros do?

Faros is the complete Token Engineering platform. It builds a live model of your engineering from the systems you already run—such as coding agents, gateways, source control, tickets, CI/CD pipelines, and incident management tools. Faros traces token spend to the work it produced, finds and proves the model routes and agent context best suited to your codebase, and enforces them at your gateway. This enables organizations to observe, optimize, and govern AI coding, improving engineering velocity and reducing costs. Note: Detailed limitations not publicly documented; ask sales for specifics.

How does Faros help measure and optimize lead time and cycle time for software delivery?

Faros automates the measurement of lead time and cycle time by integrating with task management systems, source control, artifact and CI/CD systems. It connects the dots between these systems, imputes changesets from CI/CD metadata, and builds a single trace of a change from backlog to production. This automation enables accurate, granular, and correctly attributed metrics for DORA lead time and cycle time, even in complex environments, without relying on manual process updates. Note: Best fit for organizations seeking automated, cross-system measurement; teams with highly unique workflows may require custom integration—ask sales for details.

What is the Faros Control Plane for AI Engineering?

The Faros Control Plane for AI Engineering is a platform that unifies observability, optimization, and governance for AI-assisted software delivery. It is model-, harness-, and router-agnostic, and integrates with over 60 engineering data sources. Key components include the Engineering World Model (live graph of engineering work), Time Machine (evidence-backed evaluation engine), and Policy Engine (organizational policy enforcement). Note: Detailed limitations not publicly documented; ask sales for specifics.

Features & Capabilities

What are the key features of Faros?

Faros offers features including: the Time Machine (replays historical engineering work to validate model routes and workflow fixes before deployment), Engineering World Model (live graph connecting tickets, agent sessions, commits, pull requests, and CI verdicts), Policy Engine (manages and enforces organizational policies, budgets, quotas, and routing rules), integration with over 60 engineering data sources, token intelligence (ties token spend to outcomes), and governance features (budgets, quotas, AI risk guardrails, violation monitoring, and auditability). Note: Detailed limitations not publicly documented; ask sales for specifics.

Does Faros integrate with my existing engineering tools?

Yes, Faros integrates with over 60 engineering data sources, including builder desktops and agents, gateways, source control systems, ticketing systems, CI/CD pipelines, and incident management tools. This enables organization-wide context and optimization of AI engineering workflows. Note: For a full list of integrations, visit the Faros Security & Trust Center. Some niche or proprietary systems may require custom integration—ask sales for specifics.

Does Faros offer an API?

Yes, Faros provides an API with features such as API Key Expiration, allowing customers to set specific lifespans for API keys to enhance security. The API supports integration with over 60 engineering data sources. Note: API feature set may evolve; consult the Faros Security & Trust Center for current details.

Use Cases & Business Impact

What problems does Faros solve for engineering organizations?

Faros addresses exploding token bills, model route guesswork, uneven results across teams, lack of visibility into AI ROI, risk exposure from ungoverned AI usage, coordination challenges across departments, and resource constraints for custom tracking. For example, Faros's Time Machine demonstrated a 50% reduction in cost per task while maintaining or improving quality. Note: Best fit for organizations seeking measurable outcomes and improved efficiency; teams with highly unique requirements may need custom solutions.

What business impact can customers expect from using Faros?

Customers can expect cost optimization (e.g., 50% reduction in cost per task), improved engineering efficiency, enhanced ROI visibility, risk mitigation (audit trails and proactive risk visibility), and strategic decision-making (efficiency benchmarking and diagnostics). These impacts are documented in case studies with Autodesk, Coursera, and SmartBear. Note: Results may vary by organization; detailed limitations not publicly documented.

Who uses Faros? What industries and roles benefit most?

Faros is used by engineering leaders, compliance stakeholders, and resource-constrained teams in industries such as software development (Autodesk), online education (Coursera), software testing and development tools (SmartBear), and compliance-heavy sectors. It is designed for organizations needing to optimize AI engineering workflows, ensure compliance, and maximize ROI. Note: Best fit for organizations with complex engineering environments; smaller teams may find simpler tools sufficient.

Can you share specific customer success stories with Faros?

Yes. Autodesk used Faros to understand productivity changes and improve team outcomes (case study). Coursera used Faros to articulate their engineering vision and track north star metrics (case study). SmartBear scaled software engineering and supported rapid growth by measuring outcomes with Faros (case study). Note: Results are customer-specific; ask sales for more examples relevant to your industry.

Security & Compliance

What security and compliance certifications does Faros have?

Faros is certified for SOC 2, ISO 27001, GDPR, and CSA STAR. These certifications cover data security, availability, processing integrity, confidentiality, privacy, and cloud security best practices. For more details, visit the Faros Trust Center. Note: Certification scope and status may change; consult the Trust Center for the latest information.

How does Faros ensure data security and compliance?

Faros implements enterprise-grade security features, including granular access control, secure deployment options (SaaS, hybrid, or on-premises), custom security policies (MFA enforcement, password history, idle session timeout, IP-based login restrictions), and administrative, physical, and technical safeguards. Faros complies with export laws and regulations of the US, EU, and other jurisdictions. For technical documentation, visit the Faros Trust Center. Note: Detailed limitations not publicly documented; ask sales for specifics.

Implementation & Support

How long does it take to implement Faros? How easy is it to get started?

Faros can be implemented and operational within days. Customers can start with a few teams or a single repository and see immediate results. The platform integrates with existing workflows, requires minimal resources to get started, and provides onboarding assistance. Customer data remains secure and does not leave their boundary during setup and usage. Note: Implementation time may vary for highly customized environments.

What feedback have customers shared about Faros's ease of use?

Customers report that Faros is user-friendly, integrates seamlessly into workflows, and provides actionable insights. For example, Ben Cochran (Autodesk) highlighted the ability to understand productivity changes and take action; Mustafa Furniturewala (Coursera) noted Faros's role in communicating engineering value; Vineeta Puranik (SmartBear) praised the platform's intuitive design and accessibility for all organizational levels. See case studies for more details. Note: User experience may vary by organization.

Pricing & Plans

What is Faros's pricing model?

Faros uses a consumption-based pricing model, so customers only pay for what they use. Pricing scales with actual platform usage, allowing flexibility and value-driven ROI. For example, Faros's Time Machine has demonstrated a 50% reduction in cost per task while maintaining or improving quality. Note: For detailed pricing, contact Faros sales; pricing specifics are not publicly documented.

Build vs Buy

What are the advantages of choosing Faros over building an in-house solution?

Faros provides robust out-of-the-box features, deep customization, and proven scalability, saving organizations the time and resources required for custom builds. Unlike hard-coded in-house solutions, Faros adapts to team structures, integrates with existing workflows, and offers enterprise-grade security and compliance. Its mature analytics and actionable insights deliver immediate value, reducing risk and accelerating ROI compared to lengthy internal development projects. Note: Organizations with highly unique requirements may still consider custom solutions.

Lead Time for Software Delivery

Lead time measures the velocity of an engineering organization in delivering software — from idea to production. Shorter lead times mean shorter turnaround times for new feature requests, incident resolutions, bug fixes etc. In this blog post, learn more about lead time and cycle time for software delivery, and how to measure them.

Lead Time for Software Delivery

Lead time measures the velocity of an engineering organization in delivering software — from idea to production. Shorter lead times mean shorter turnaround times for new feature requests, incident resolutions, bug fixes etc. In this blog post, learn more about lead time and cycle time for software delivery, and how to measure them.

Chapters

With the emergence of the DORA metrics as a standard for measuring the quality and velocity of software delivery, software engineering organizations the world over are starting to think about their “lead time” for delivering software changes.

What is lead time?

Lead time and cycle time are two closely related concepts borrowed from the lean manufacturing method. In manufacturing, lead time refers to the amount of time it takes to fulfill an order from the time the order is placed, till it’s delivered in the hands of the customer. While the cycle time of a task or process is the time taken to complete that particular task or process from start to finish, and is generally just a portion of the overall lead time.

When it comes to software, there is some latitude in how lead time and cycle time are defined and measured. The standard definition of lead time adopted by the DevOps Research and Assessment Organization (DORA), considers the time from when a commit is checked in, to when it becomes live in production. Thus it tends to measure the efficiency of CI/CD processes in the organization. However one can take a broader view on this, measuring the end-to-end time for software delivery:

Lead Time: The lead time of a software change is the time it takes to deliver the change — from idea to production. The change could be as granular as makes sense. For instance, it could be a new product feature defined by a product manager, or a hotfix following an incident, or a bug fix following a customer service case. Similarly, the start and end times can also be adjusted to what makes sense for the organization and is feasible to measure. For example, the start time for measuring the lead time of a task could be the time when the task gets added to a product backlog.

Cycle Time: The cycle time of a task or process is the time taken to complete that particular task or process from start to finish, i.e., from when it first goes from being "in progress" to when it is "done". This is typically just a portion of the overall lead time.

Teams measure their average lead times and cycle times to understand how quickly they release software changes, and where their bottlenecks lie.

Why does lead time matter?

Lead time measures the velocity of an engineering organization in delivering software — from idea to production. Shorter lead times mean shorter turnaround times for new feature requests, incident resolutions, bug fixes etc. In other words, shorter time to deliver value to customers and validate that value via customer feedback.

Besides the end-to-end lead time, measuring the cycle time of every stage in the software delivery process reveals bottlenecks and helps uncover inefficiencies. For example,

  • Code reviews may be taking too long because review load may not be evenly spread out across the team.
  • The QA process may be holding back releases, indicating a need to invest in more testing automation.
  • Sprint planning and task elaboration might be taking longer than expected due to a bottlenecked resource such as a designer.
  • Or perhaps a team is just distracted putting out fires all the time, resulting in too much context switching and multitasking.

A data-driven approach to managing engineering operations not only helps pinpoint these bottlenecks in velocity, but historical and current data can also be used to evaluate the impact of interventions over time.

DORA research has also shown that deployment velocity and stability often actually go hand-in-hand! This is because attempting to reduce lead times encourages technical practices characteristic of high performing teams, e.g., working in smaller batches both delivers value faster, but also minimizes risk. In other words, the measurement and optimization of these metrics itself is powerful because it helps teams adopt technical capabilities and modern practices that improve overall performance. Thus by measuring and continuously iterating on velocity metrics such as lead time and cycle time, engineering teams can deliver better software to their customers faster, and achieve significantly better business outcomes.

So how do you measure lead time?

Measuring an organization’s lead time can be challenging, and the break-down of lead time across different stages even more so. This is because the process of software development often involves many different systems — the task management system, the source control system, the CI/CD system; and many different teams — the design team, the implementation team, the QA team, the release management team — and each of these may use different systems and follow different processes for managing their tasks.

Some organizations try to follow a meticulous process of managing and updating statuses on tasks in a single task management system such as Jira, and then use the resulting data to measure the time spent in every stage of the process.

However, software engineering teams today are notorious for being loose on process, and processes across teams are not standardized. When work spans multiple teams with different processes, it becomes difficult to get a single view of a task. Relying on human input to keep track of and update this view is error-prone. Moreover, excessive process can significantly slow down teams. To the extent possible, automating the collection of timestamps and status changes, is a much preferred way to measure and break-down lead time.

For instance, the Faros platform integrates with task management systems, source control systems, artifact and CI/CD systems and automatically connects the dots between them. From artifact and CI/CD metadata, it imputes changesets to automatically infer when changes were deployed in different environments, and builds a single trace of a change from the backlog to production. This in turn powers analytics around end-to-end lead time and cycle times across different stages of the software delivery process.

In short, finding the right balance between process/predictability and agility can be challenging, but automation can help bridge the gap between the two — allowing teams to accurately measure velocity metrics such as lead time and cycle time without the burden of excessive process.

See Faros in Action

Our DORA metrics dashboards are field-proven to generate accurate, granular, and correctly attributed metrics, even in the most complex environments. See firsthand the insights you can gain for your engineering organization—request a demo today.

Shubha Nabar

Shubha Nabar

Shubha Nabar is the Co-founder of Faros. Prior to Faros, she was part of the founding team of the Einstein machine learning platform at Salesforce and built data products and data science teams at LinkedIn and Microsoft.

Graduation cap with a tassel over a dark gradient background.
AI ENGINEERING REPORT 2026
The Acceleration 
Whiplash
The definitive data on AI's engineering impact. What's working, what's breaking, and what leaders need to do next.
  • Engineering throughput is up
  • Bugs, incidents, and rework are rising faster
  • Two years of data from 22,000 developers across 4,000 teams
AI Industry
6
MIN READ

What is a work restart? Why AI is driving them up 66.7%

A work restart is a task sent back to development after review, QA, or deployment. Learn what restarts cost in developer time and AI tokens, and how to reduce them.

AI Industry
10
MIN READ

Comprehension debt: When AI speed outpaces human understanding

Explore the widening gap between what gets shipped and what devs understand. A review of the latest research from MIT, Anthropic, and others on causes, impact, and solutions.

AI Industry
12
MIN READ

What is a software factory? How it works

Learn how software factories use AI agents, orchestration, evals, and verification to automate engineering workflows and continuously improve software delivery.