kickoff_async(): CrewAI method reference

What is kickoff_async()?

kickoff_async(inputs=None) returns a coroutine that completes when the same logical work as kickoff() would finish, but cooperates with the asyncio event loop so your web server, worker, or streaming pipeline can interleave other IO. CrewAI can await async tools and httpx-style clients without blocking a worker thread pool, which materially improves tail latency when agents fan out to several network dependencies.

You still pass the same inputs dict for template interpolation; the difference is scheduling, not semantics. Pair the call with asyncio.gather when you have independent crews or flows whose outputs merge later, but add explicit semaphores or Crew(max_rpm=...) tuning when you risk provider rate limits. Streaming listeners (LLMStreamChunkEvent) compose the same way as synchronous kickoff as long as your consumer awaits the coroutine and drains events on the bus.

Avoid mixing un-awaited coroutines into background fire-and-forget tasks unless you attach error callbacks — exceptions in orphaned tasks are easy to miss. In FastAPI, return or await inside the route handler so connection closure cancels in-flight work predictably.

Use Cases

• FastAPI endpoints
• Parallel crew batches
• Async streaming pipelines

Key Features

✓ Awaitable
✓ Compatible with asyncio.gather

When NOT to Use

Pure scripts where sync is simpler.

Notes

Still respect rate limits

Async does not magically raise RPM ceilings. Combine kickoff_async with max_rpm on Crew or Agent, or your own semaphore, when fanning out to OpenAI-class providers.

Do not call sync kickoff inside async routes

Blocking kickoff() on the event loop thread stalls every concurrent request in the same loop. Prefer kickoff_async or asyncio.to_thread for legacy sync-only tools.

Cancellation semantics

When the client disconnects, asyncio may cancel your task. Ensure idempotent side effects or transactional boundaries around external writes your crew performs mid-run.

Testing

pytest-asyncio fixtures should await kickoff_async directly. For sync tests of async crews, asyncio.run(suite) at module scope is clearer than mixing loops.

Parameters

Parameter	Type	Required	Purpose
inputs	dict \| None	No	Variables interpolated into task descriptions.

Code Examples

FastAPI

python

@app.post('/run')
async def run():
    return (await crew.kickoff_async(inputs={'topic': 't'})).raw

Bounded concurrency

python

import asyncio

sem = asyncio.Semaphore(3)

async def run_one(topic: str):
    async with sem:
        return await crew.kickoff_async(inputs={'topic': topic})

results = await asyncio.gather(*[run_one(t) for t in topics])

When to Use

FastAPI / asyncio applications, parallel crew runs.

Common Mistakes

❌ Forgetting `await`

✅ Always await the coroutine: result = await crew.kickoff_async(...).

kickoff_async() FAQ

What is kickoff_async() in CrewAI?

Async version of kickoff() — awaitable, suitable for async web servers and parallel runs. kickoff_async(inputs=None) returns a coroutine that completes when the same logical work as kickoff() would finish, but cooperates with the asyncio event loop so your web server, worker, or streaming pipeline can interleave other IO. CrewAI can await async tools and httpx-style clients without blocking a worker thread pool, which materially improves tail latency when agents fan out to several network dependencies. You still pass the same inputs dict for template interpolatio…

Which CrewAI types expose the method kickoff_async()?

DevShelfHub documents kickoff_async() on Crew, Flow. The reference maps it to Python module crewai.Crew — pin your installed crewai version and match imports to the snippet on this page.

When should I use kickoff_async()?