Last reviewed: August 28, 2026

Direct answer

A CometAPI CrewAI integration uses CrewAI to coordinate agents and CometAPI to provide their model access. Configure one CometAPI credential and base URL, create a separate LLM object for each model ID, attach those objects to specialized agents, and run their tasks with Process.sequential.

This boundary is supported by the CometAPI multi-model CrewAI guide , which documents one shared connection with per-agent model assignments. The current CrewAI LLM documentation separately documents model, api_key, base_url, custom_openai, timeout, and max_retries settings for custom OpenAI-compatible endpoints.

Start in an isolated Python environment:

python -m venv .venv
python -m pip install 'crewai[openai]' python-dotenv

Activate the environment using the command appropriate for your operating system. For a reproducible deployment, record the installed versions and pin the versions that pass your tests.

Keep configuration outside the program. Set COMETAPI_BASE_URL to the CometAPI base documented in the integration guide . A local environment file can use placeholders like these:

COMETAPI_KEY=[REDACTED]
COMETAPI_BASE_URL=[SET_TO_THE_DOCUMENTED_COMETAPI_BASE]

Do not commit that file. The following complete example creates a researcher, analyst, and writer. The three model assignments come from the current CometAPI guide and are an example routing policy, not a ranking. Confirm every ID against the live catalog before running it.

import os

from crewai import Agent, Crew, LLM, Process, Task
from dotenv import load_dotenv

load_dotenv()

COMETAPI_KEY = os.environ['COMETAPI_KEY']
COMETAPI_BASE_URL = os.environ['COMETAPI_BASE_URL']

MODEL_MAP = {
    'researcher': 'gemini-3.7-flash',
    'analyst': 'claude-opus-5',
    'writer': 'gpt-5.6',
}


def cometapi_llm(model_id: str) -> LLM:
    return LLM(
        model=model_id,
        custom_openai=True,
        base_url=COMETAPI_BASE_URL,
        api_key=COMETAPI_KEY,
        timeout=60.0,
        max_retries=0,
    )


researcher = Agent(
    role='Market Researcher',
    goal='Collect relevant facts and identify uncertainties',
    backstory='You prepare compact, source-aware research notes.',
    llm=cometapi_llm(MODEL_MAP['researcher']),
    max_iter=3,
    allow_delegation=False,
)

analyst = Agent(
    role='Product Analyst',
    goal='Turn research into a defensible recommendation',
    backstory='You separate evidence, assumptions, risks, and trade-offs.',
    llm=cometapi_llm(MODEL_MAP['analyst']),
    max_iter=3,
    allow_delegation=False,
)

writer = Agent(
    role='Technical Writer',
    goal='Produce a concise technical decision memo',
    backstory='You explain technical decisions clearly and precisely.',
    llm=cometapi_llm(MODEL_MAP['writer']),
    max_iter=3,
    allow_delegation=False,
)

research_task = Task(
    description=(
        'Research {topic}. Return key facts, uncertainties, and the '
        'evidence the analyst should consider.'
    ),
    expected_output='Structured research notes with facts and uncertainties.',
    agent=researcher,
)

analysis_task = Task(
    description=(
        'Analyze the research for {topic}. Identify assumptions, risks, '
        'trade-offs, and a recommendation.'
    ),
    expected_output='A decision outline with evidence, risks, and trade-offs.',
    agent=analyst,
    context=[research_task],
)

writing_task = Task(
    description=(
        'Write a concise decision memo about {topic} using the research '
        'and analysis. Do not invent missing evidence.'
    ),
    expected_output='A clear technical decision memo in Markdown.',
    agent=writer,
    context=[research_task, analysis_task],
)

crew = Crew(
    agents=[researcher, analyst, writer],
    tasks=[research_task, analysis_task, writing_task],
    process=Process.sequential,
    verbose=False,
    max_rpm=20,
)

result = crew.kickoff(
    inputs={'topic': 'Choose a queue design for a small event-processing service'}
)

print(result.raw)
print(result.token_usage)

Setting max_retries=0 is deliberate: it prevents a client retry loop from operating invisibly beneath an application-level fallback policy. If you want automatic client retries instead, make that one layer the documented owner of retries and do not also switch models repeatedly above it.

Who this is for

This pattern is for Python developers who already understand basic API configuration and want multiple CrewAI agents to use different CometAPI models. It is particularly useful when research, analysis, and writing have different latency, cost, context, or output requirements.

It is not a claim that every model supports identical parameters. A shared OpenAI-compatible interface simplifies connection management, but model capabilities, context limits, tool behavior, latency, and pricing can still differ.

Key takeaways

  • CrewAI owns agents, tasks, task order, and context handoff; CometAPI owns model access through the configured model IDs.
  • Create one LLM instance per agent so the routing policy remains separate from prompts and role definitions.
  • Keep the credential and base URL outside source control, and never include either the credential value or full prompts in routine logs.
  • Validate current model IDs and supported parameters before deployment.
  • Give exactly one layer responsibility for retries and bound any model fallback to avoid duplicate requests and runaway cost.
  • Inspect final output, individual task output, and token usage before treating a run as successful.

Sources checked

  • The CometAPI CrewAI integration guide supports the shared base configuration, per-agent model map, bounded fallback, checkpointing, and usage-tracking pattern. It was updated August 27, 2026.
  • The CrewAI LLM guide documents direct LLM configuration and custom OpenAI-compatible endpoints. The documentation currently resolves to version 1.15.18.
  • The CrewAI crews guide documents agents, tasks, sequential execution, rate controls, callbacks, checkpoint configuration, and structured crew output with token usage.
  • The CrewAI project page on PyPI was checked for package identity. The page returned a client-side challenge during review, so this article does not rely on it for a package-version claim.

Contract details to verify

Connection and model contract

Confirm that both environment variables exist before constructing an LLM, but check only presence and never print the credential. Verify the base URL against the current CometAPI guide. Then verify each model ID, its availability, endpoint compatibility, and the parameters your agent sends. The example deliberately avoids optional sampling and reasoning controls because the CrewAI documentation warns that these are model-specific.

Run the researcher model alone before assembling the crew. A successful single-agent call confirms the connection and selected model independently of task handoff. Repeat that preflight for the analyst and writer models. The same request shape reaching three model IDs does not prove that their outputs or limits are interchangeable.

Before deployment, validate the current CometAPI model catalog . If you need a stronger network boundary, apply the client-side timeout pattern as well.

Orchestration and output contract

Process.sequential makes task order explicit: research runs first, analysis receives the research task as context, and writing receives both preceding tasks. The CrewAI crews documentation says sequential tasks run in listed order and that CrewOutput exposes the final raw output, individual task outputs, and token usage.

Validate more than a nonempty final string. Check that all expected tasks completed, that the final memo contains the requested sections, and that usage is present. When partial execution would be expensive, evaluate CrewAI checkpointing in a controlled environment before relying on it for recovery.

Happy-path operator workflow

  1. Pin the dependency versions that passed testing and record them with the deployment artifact.
  2. Confirm configuration presence without printing values.
  3. Verify all three model IDs in the current catalog and run one minimal request through each configuration.
  4. Kick off the crew with a short, non-sensitive topic.
  5. Confirm that research, analysis, and writing complete in order.
  6. Validate the output shape and inspect token usage for unexpected growth.
  7. Emit one sanitized record per agent attempt and one crew-completion record.
  8. Promote the routing map only after the same test passes in the target environment.

A sanitized attempt record can look like this:

{
  "run_id": "run-1042",
  "event": "agent_attempt",
  "agent_role": "researcher",
  "task_name": "research",
  "model_id": "gemini-3.7-flash",
  "status": "ok",
  "attempt": 1,
  "fallback_used": false,
  "latency_ms": 1840,
  "input_size_chars": 96,
  "output_size_chars": 742,
  "http_status": 200,
  "error_class": null
}

Useful logging fields are run_id, event, agent_role, task_name, model_id, status, attempt, fallback_used, latency_ms, input and output sizes, an HTTP status when available, and a short error class. Exclude credential values, request headers, full prompts, raw model output, and unfiltered error bodies. Store the final memo as application data only when the use case requires it; do not duplicate it into routine operational logs.

Error-path operator workflow

  1. Stop the run from printing verbose request or response details.
  2. Record the sanitized fields above and classify the failure as configuration, model availability, parameter compatibility, rate limiting, timeout or connection, upstream service, or output validation.
  3. Do not switch models for a missing credential, wrong base URL, unsupported parameter, or unavailable model ID. Correct the contract first.
  4. For a transient timeout, connection failure, rate limit, or upstream service failure, wait according to the applicable response guidance and permit at most one controlled retry or one fallback transition.
  5. Rebuild the affected agent with the fallback model rather than mutating prompts. Confirm that the fallback supports the same required capabilities.
  6. If the bounded fallback fails, stop. Preserve safe task-state metadata, mark the run incomplete, and escalate with the run ID and error class.
  7. After recovery, rerun the happy path and compare task completion, output validation, latency, and usage against the baseline.

Failure modes

  • Missing or incorrect configuration: A missing environment value should fail locally before work starts. A wrong base URL or rejected credential should not trigger model fallback because another model cannot repair the connection contract.
  • Stale model ID: Catalogs change. An ID copied from an older tutorial may be unavailable even though the gateway is reachable. Revalidate the ID instead of cycling blindly through alternatives.
  • Unsupported model parameter: Temperature, reasoning controls, structured output, tools, and token-limit fields are not universally interchangeable. Remove unsupported optional controls or select a model verified for the requirement.
  • Rate pressure: Three sequential agents still generate multiple model calls, and agent iterations can add more. Use max_rpm, measure actual call counts, and avoid overlapping retries.
  • Timeout or connection interruption: A slow request may leave the operator unsure whether work completed upstream. Use a bounded timeout policy and an application run ID; do not assume that every timeout is safe to replay repeatedly.
  • Partial sequential execution: Research or analysis may finish before writing fails. Re-running the whole crew can duplicate calls and cost. Test checkpoint behavior or persist only the minimum safe task-state metadata needed for deliberate recovery.
  • Fallback mismatch: A fallback model may reject a parameter or produce a different output shape. Validate it with the same representative task set before placing it in the route map.
  • Context growth: Passing earlier task output forward can expand later inputs. Track input size and token usage, constrain expected outputs, and fail validation when an intermediate result becomes unexpectedly large.
  • Excessive logging: Verbose framework output can expose prompts or responses. Keep routine logging structured and sanitized, and grant access to application content separately.
  • Dependency drift: CrewAI’s constructor and provider behavior can evolve. Pin tested dependencies and compare your code with the documentation for the installed release before upgrading.

FAQ

Can every CrewAI agent use a different CometAPI model?

Yes. CrewAI lets an agent carry its own LLM configuration, while CometAPI routes access according to the model ID. Constructing each agent with a separate LLM keeps that choice explicit.

Does OpenAI compatibility make all models equivalent?

No. It provides a common interface, not identical context windows, tool support, sampling behavior, latency, pricing, or output quality. Verify the capability contract for every primary and fallback model.

Should I enable both CrewAI retries and application fallback?

Only with a carefully documented total attempt budget. The simpler tutorial policy disables hidden client retries and permits one application-controlled recovery action. This makes call count, fallback choice, and cost easier to reason about.

How should I choose the three models?

Use representative tasks and measurable acceptance criteria for each role. Evaluate correctness, required capability support, latency, and usage. The model map in this tutorial mirrors the current integration guide; it is not a universal recommendation.

What proves the workflow succeeded?

A successful transport response is not enough. Confirm that every expected task completed, the final output meets its format and evidence requirements, and token usage remains within your guardrail. Keep the sanitized run record for diagnosis.

Can I log prompts while debugging?

Avoid placing full prompts, outputs, headers, or credentials in routine logs. If content-level debugging is necessary, use a separately controlled diagnostic path with redacted test inputs and a defined retention period.

Reader next step

Begin with one agent and one verified model, then add the analyst and writer only after the single-agent call is stable. Run the happy path, force one controlled transient failure, and confirm that your attempt budget stops after the documented recovery action. You can then test shared routing assertions with Promptfoo before promoting the map.

When you are ready to create the shared connection, Start with CometAPI .