Opprett multimodell CrewAI-agenter med CometAPI:

Å bygge et multiagent-system med CrewAI blir mer interessant når forskjellige agenter kan bruke ulike modeller.

En forsker kan ha nytte av en rask, økonomisk modell, en analytiker kan trenge en sterkere resonneringsmodell, og en skribent kan kreve en modell optimalisert for høykvalitets langform-generering. Tradisjonelt har det å koble disse agentene til ulike leverandører betydd å håndtere separate API-legitimasjoner, endepunkter, SDK-er, faktureringssystemer og leverandørspesifikk konfigurasjon.

En ryddigere arkitektur er å la CrewAI administrere agentene og arbeidsflyten mens CometAPI administrerer modelltilgang.

CometAPI tilbyr et OpenAI-kompatibelt endepunkt på https://api.cometapi.com/v1, slik at applikasjoner kan rute forespørsler til modeller fra flere leverandører gjennom et felles API-grensesnitt. Dets nåværende hurtigstart-dokumentasjon støtter også bruk av standard OpenAI Python SDK ved å endre API-nøkkel og base-URL. 

I denne veiledningen bygger du en CrewAI-arbeidsflyt med tre agenter:

• Gemini 3.7 Flash til research
• Claude Opus 5 til analyse
• GPT-5.6 til sluttføring av tekst
• Én CometAPI API-nøkkel
• Én API base-URL
• Modellkonfigurasjon per agent
• Begrenset fallback for forbigående feil
• CrewAI-sjekkpunkter for gjenoppretting i produksjon
• Sporing av token- og kjørebruk
• Serverside modellvalidering

Den viktige arkitektoniske grensen er enkel:

CrewAI håndterer agentorkestrering. CometAPI håndterer modelltilgang. Modell-ID-er definerer ruting.

---

Hva er CrewAI multiagent-modellruting?

CrewAI er et Python-rammeverk for å lage agenter, oppgaver, besetninger og multiagent-arbeidsflyter. Hver agent kan ha sin egen LLM-konfigurasjon, mens Crew koordinerer hvordan disse agentene utfører oppgaver og utveksler kontekst.

CrewAIs nåværende LLM-konfigurasjon støtter eksplisitte innstillinger for model, api_key og base_url, inkludert tilpassede OpenAI-kompatible endepunkter. 

Det gjør en multimodell-arkitektur rett fram:

                         CometAPI                            │              https://api.cometapi.com/v1                            │        ┌───────────────────┼───────────────────┐        │                   │                   │   Researcher            Analyst             Writer        │                   │                   │ Gemini 3.7 Flash      Claude Opus 5         GPT-5.6

Agentene forblir separate fra et logisk perspektiv, men tilgangen til modeller blir sentralisert.

Dette er noe annet enn å si at alle modeller er utskiftbare. Et OpenAI-kompatibelt API gir et felles forespørselsgrensesnitt; det garanterer ikke identiske kontekstgrenser, verktøystøtte, resonnementskontroller, utputsadferd, latenstid eller pris.

Den forskjellen er viktig når man utformer ruting i produksjon.

---

Hvorfor bruke CometAPI med CrewAI?

Hovedfordelen er ikke at CrewAI plutselig blir et rammeverk for flere leverandører. CrewAI støtter allerede flere LLM-leverandører.

Fordelen er at modelltilgang kan konsolideres bak ett API-lag.

Uten et forent API-lag kan en arbeidsflyt med tre agenter se slik ut:

Med CometAPI:

CometAPIs nåværende hurtigstart-dokumentasjon beskriver endepunktet som en drop-in-erstatning for OpenAI API base-URL og lister modeller fra flere leverandører gjennom samme tjeneste. 

Dette gir applikasjonen en nyttig separasjon:

CrewAI

• Definerer agentroller
• Definerer oppgaver
• Sender kontekst
• Kontrollerer kjøring
• Håndterer agentiterasjoner
• Håndterer orkestrering på besetningsnivå

CometAPI

• Gir et felles lag for modelltilgang
• Sentraliserer API-autentisering
• Gir modellruting via modell-ID-er
• Gir applikasjonen ett API-endepunkt
• Gir sentralisert innsikt i bruk og fakturering

---

Hva vil denne CrewAI-arbeidsflyten bygge?

Eksemplet oppretter tre sekvensielle agenter.

Dette er en eksempel-rutingspolicy, ikke en benchmark-rangering.

Riktig modell for agenten din avhenger av:

• oppgavens kompleksitet
• nødvendig kontekstlengde
• verktøybruk
• krav til strukturert utdata
• latenstid
• pålitelighet
• tokenkostnad
• utgangskvalitet
• applikasjonsspesifikke evalueringsresultater

En nyttig regel er:

Velg en modell for jobben agenten utfører, ikke bare for leverandøren den kommer fra.

---

Hvilken modell bør hver CrewAI-agent bruke?

For dette eksemplet følger modelltilordningen en enkel kostnad-versus-kapasitet-strategi.

Forsker: Gemini 3.7 Flash

Research innebærer ofte å behandle relativt store mengder informasjon og produsere et kompakt mellomresultat.

En rask modell kan derfor være nyttig for research-oppgaver med høyt volum.

"researcher": "gemini-3.7-flash"

Analytiker: Claude Opus 5

Analytikeren har en smalere, men mer resonnementstung rolle. Den mottar research-resultatet og gjør det om til en anbefaling.

"analyst": "claude-opus-5"

Skribent: GPT-5.6

Den siste agenten konverterer research og analyse til et beslutningsnotat rettet mot utviklere.

"writer": "gpt-5.6"

Det viktige er ikke akkurat disse tre tilordningene. Applikasjonen din bør evaluere kandidatmodeller mot representative oppgaver før rutingspolicyen fastsettes.

---

Hva trenger du før du starter?

Du trenger:

• Python 3.10+
• CrewAI
• Kompatibilitet med OpenAI Python SDK
• python-dotenv
• En CometAPI API-nøkkel
• Modell-ID-ene du har tenkt å bruke

CometAPIs nåværende Python-integrasjon støtter det OpenAI-kompatible API-et, og den offisielle CometAPI Python-pakken dokumenterer COMETAPI_KEY og COMETAPI_BASE_URL som miljøbaserte konfigurasjonsalternativer. 

Standard endepunkt er:

https://api.cometapi.com/v1

Før du setter i produksjon, verifiser at de valgte modell-ID-ene er tilgjengelige og støtter endepunktet og parameterne som kreves av CrewAI-arbeidslasten din. Modellkataloger og priser kan endres.

---

Hvordan installerer du CrewAI og avhengighetene?

Opprett et nytt Python-miljø:

python -m venv .venv

Aktiver det:

source .venv/bin/activate

På Windows:

.venv\Scripts\Activate.ps1

Installer deretter avhengighetene:

pip install "crewai[openai]" openai python-dotenv

Å bruke openai eksplisitt er bevisst fordi fallback-implementeringen nedenfor importerer OpenAI SDKs unntaksklasser direkte.

For produksjon, lås versjonene du tester i stedet for å stole ubegrenset på flytende siste versjoner.

For eksempel:

crewai==YOUR_TESTED_VERSIONopenai==YOUR_TESTED_VERSIONpython-dotenv==YOUR_TESTED_VERSION

CrewAIs LLM-lag er i aktiv utvikling, så den nøyaktige konstruktøren og leverandørkonfigurasjonen bør sjekkes mot CrewAI-versjonen som brukes av applikasjonen din. Nåværende CrewAI-dokumentasjon støtter konfigurasjon av en LLM med en tilpasset base_url og API-nøkkel. 

---

Hvordan konfigurerer du CometAPI API-nøkkelen?

Opprett en .env-fil:

COMETAPI_KEY=your_cometapi_keyCOMETAPI_BASE_URL=https://api.cometapi.com/v1

Last disse verdiene i Python:

import osfrom dotenv import load_dotenvload_dotenv()COMETAPI_KEY = os.environ["COMETAPI_KEY"]COMETAPI_BASE_URL = os.getenv(    "COMETAPI_BASE_URL",    "https://api.cometapi.com/v1",)

Aldri commit .env til Git.

Legg den til .gitignore:

.env.venv/__pycache__/

API-nøkkelen bør forbli en serverside-legitimasjon. CometAPIs nåværende hurtigstartveiledning anbefaler tilsvarende å lagre nøkkelen i miljøvariabler i stedet for i kildekode. 

---

Hvordan kobler du CrewAI til CometAPI?

CrewAIs LLM-objekt kan motta et modellnavn, API-nøkkel og tilpasset base-URL. 

Opprett en hjelper:

from crewai import LLMdef cometapi_llm(model_id: str) -> LLM:    return LLM(        model=model_id,        base_url=COMETAPI_BASE_URL,        api_key=COMETAPI_KEY,        timeout=60.0,        max_retries=0,    )

Dette er å foretrekke fremfor å legge inn samme konfigurasjon separat i hver agent.

Hver agent trenger nå bare en modell-ID:

research_llm = cometapi_llm("gemini-3.7-flash")analysis_llm = cometapi_llm("claude-opus-5")writing_llm = cometapi_llm("gpt-5.6")

Hvorfor sette max_retries=0?

Årsaken er kontroll over fallback.

Hvis den underliggende LLM-klienten automatisk forsøker på nytt og applikasjonen din også implementerer fallback, kan én feil bli til flere skjulte forespørsler før fallback-logikken kjører.

For en veiledning med eksplisitt ruting er det ryddigere å la applikasjonen bestemme når den skal forsøke på nytt eller bytte modeller.

---

Hvordan definerer du modellrutingspolicyen?

Hold ruting utenfor promptene dine:

PRIMARY_MODELS = {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6",}FALLBACK_MODELS = {    "researcher": "gpt-5.6",    "analyst": "gpt-5.6",    "writer": "gemini-3.7-flash",}

Dette skaper en klar konfigurasjonsgrense.

Du kan senere flytte den samme mappingen til:

• miljøkonfigurasjon
• YAML
• JSON
• en database
• feature flags
• en intern modellruting-tjeneste

uten å skrive om agent-promptene.

---

Hvordan bygger du de tre CrewAI-agentene?

Opprett ett LLM-objekt per agent.

from crewai import Agentdef build_agents(model_map: dict[str, str]):    researcher = Agent(        role="Market Researcher",        goal="Collect the facts needed to answer the topic",        backstory=(            "You create concise, source-aware research briefs "            "and clearly separate facts from assumptions."        ),        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 identify evidence, assumptions, risks, "            "and trade-offs before making recommendations."        ),        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 write clear technical explanations "            "without unnecessary marketing language."        ),        llm=cometapi_llm(model_map["writer"]),        max_iter=3,        allow_delegation=False,    )    return researcher, analyst, writer

Modelltilordningen er nå fullstendig uavhengig av agentens rolledefinisjon.

Det er det som gjør modellruting praktisk.

---

Hvordan kobler du agentene med sekvensielle oppgaver?

Opprett tre oppgaver:

from crewai import Taskdef build_tasks(researcher, analyst, writer):    research_task = Task(        description=(            "Research this topic: {topic}. "            "Return the key facts, uncertainties, "            "and relevant sources that the analyst should consider."        ),        expected_output=(            "A compact research brief containing facts, "            "uncertainties, and source references."        ),        agent=researcher,    )    analysis_task = Task(        description=(            "Using the research brief, analyze {topic}. "            "Identify the strongest conclusion and explain "            "the major trade-offs."        ),        expected_output=(            "A decision outline with evidence, "            "assumptions, risks, and trade-offs."        ),        agent=analyst,        context=[research_task],    )    writing_task = Task(        description=(            "Write a concise technical decision memo about {topic}. "            "State the recommendation early and preserve "            "important caveats."        ),        expected_output="A polished technical decision memo in Markdown.",        agent=writer,        context=[research_task, analysis_task],    )    return research_task, analysis_task, writing_task

Avhengighetskjeden er:

Topic  ↓Research  ↓Analysis  ↓Final memo

Analytikeren mottar output fra research-oppgaven, mens skribenten mottar både research- og analyse-kontekst.

---

Hvordan bygger du besetningen?

Kombiner agentene og oppgavene:

from crewai import Crew, Processdef build_crew(model_map: dict[str, str]) -> Crew:    researcher, analyst, writer = build_agents(model_map)    research_task, analysis_task, writing_task = build_tasks(        researcher,        analyst,        writer,    )    return Crew(        agents=[researcher, analyst, writer],        tasks=[            research_task,            analysis_task,            writing_task,        ],        process=Process.sequential,        verbose=True,    )

Nå er modellrutingen helt styrt av konfigurasjon.

Å endre:

"researcher": "gemini-3.7-flash"

til en annen støttet modell krever ikke endringer i research-prompten eller oppgavebeskrivelsen.

---

Hvordan bør CrewAI-modellfallback fungere?

Her må en produksjonsorientert implementering være mer nøye.

En vanlig feil er:

Any error   ↓Switch model

Det er for aggressivt.

For eksempel bør disse feilene generelt ikke utløse modellfallback:

400 Bad Request401 Unauthorized403 Forbidden404 Not Found422 Validation Error

Å bytte modell vil ikke fikse en ugyldig API-nøkkel eller en feilformatert forespørsel.

Fallback er mer passende for midlertidige feil som:

408 Request Timeout429 Rate Limit500 Internal Server Error502 Bad Gateway503 Service Unavailable504 Gateway TimeoutConnection errorTimeout

Fallback-policyen bør derfor være:

Forsøk på nytt eller bytt modeller kun for begrensede, forbigående feil og bare når fallback-modellen støtter samme forespørselskontrakt.

---

Hvordan oppdager du feil som kan forsøkes på nytt?

Du kan bruke OpenAI SDKs feilklasser:

from collections.abc import Iteratorfrom openai import (    APIConnectionError,    APIStatusError,    APITimeoutError,)def exception_chain(error: BaseException) -> Iterator[BaseException]:    current: BaseException | None = error    seen: set[int] = set()    while current is not None and id(current) not in seen:        seen.add(id(current))        yield current        current = (            current.__cause__            or current.__context__        )def should_fallback(error: BaseException) -> bool:    for current in exception_chain(error):        if isinstance(            current,            (APIConnectionError, APITimeoutError),        ):            return True        if isinstance(current, APIStatusError):            return (                current.status_code in {408, 429}                or current.status_code >= 500            )    return False

Dette utelater bevisst 400-nivå konfigurasjonsfeil bortsett fra 408 og 429.

---

Bør du forsøke på nytt hele besetningen eller bare den mislykkede agenten?

Det finnes to ulike fallback-strategier.

Fallback på besetningsnivå

Den enkleste implementeringen er:

Start crew   ↓failure   ↓change routing   ↓run crew again

Dette er lett å forstå, men kan gjenta fullførte oppgaver.

For eksempel:

Research → completedAnalysis → completedWriter → failed

En full kickoff()-retry kan kjøre:

Research → againAnalysis → againWriter → fallback

Det øker:

• tokenbruk
• latenstid
• API-kostnad
• potensielle sideeffekter

Gjenoppretting på oppgavenivå

En produksjonsarbeidsflyt bør i stedet sjekkpunkte fullført arbeid:

Research   ↓checkpoint   ↓Analysis   ↓checkpoint   ↓Writer fails   ↓retry writer with fallback

CrewAI tilbyr for øyeblikket sjekkpunkter som lagrer kjøringsstatus og lar en kjøring gjenopptas etter en feil. Den dokumenterte sjekkpunktadferden hopper over fullførte oppgaver og fortsetter videre arbeid fra lagret tilstand. 

Dette er bedre arkitektur for kostbare eller sideeffektproduserende arbeidsflyter.

---

Hvordan legger du til CrewAI-sjekkpunkter?

For produksjonsarbeidsflyter, aktiver sjekkpunkter på besetningen:

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

CrewAIs sjekkpunkt-system kan persistere kjøringsstatus etter oppgavefullføring og gjenopprette besetningen fra et sjekkpunkt. 

For eksempel kan en gjenopprettet kjøring bruke:

from crewai import CheckpointConfigresult = crew.kickoff(    from_checkpoint=CheckpointConfig(        restore_from="./.checkpoints/checkpoint.json",    ))

Den eksakte sjekkpunktkonfigurasjonen bør følge CrewAI-versjonen som brukes av prosjektet ditt.

Det viktige arkitektoniske poenget er:

Sjekkpunkter først, fallback deretter.

Dette hindrer en midlertidig modellfeil fra å tvinge kostbart fullført arbeid til å kjøre igjen.

---

Hvordan implementerer du en enkel begrenset fallback?

For en veiledning kan du fortsatt demonstrere en enkel fallback på besetningsnivå.

def run_with_fallback(topic: str):    routes = [        PRIMARY_MODELS,        {            **PRIMARY_MODELS,            "writer": FALLBACK_MODELS["writer"],        },        {            **PRIMARY_MODELS,            "analyst": FALLBACK_MODELS["analyst"],            "writer": FALLBACK_MODELS["writer"],        },    ]    last_error = None    for attempt, model_map in enumerate(routes, start=1):        try:            crew = build_crew(model_map)            result = crew.kickoff(                inputs={"topic": topic}            )            return result, model_map        except Exception as error:            last_error = error            if not should_fallback(error):                raise            if attempt == len(routes):                raise            print(                f"Transient failure on attempt {attempt}. "                f"Trying bounded fallback route.",                flush=True,            )    raise RuntimeError(        "Crew execution failed after all fallback routes."    ) from last_error

Legg merke til den viktige forskjellen:

Dette hevder ikke at den mislykkede agenten er identifisert.

Det er en begrenset fallback-strategi på besetningsnivå.

For små, tilstandsløse arbeidsflyter kan dette være akseptabelt. For produksjonsarbeidsflyter med kostbar research, verktøy eller sideeffekter, bruk gjenoppretting basert på sjekkpunkt.

---

Hvordan sporer du CrewAI-tokenbruk?

Brukssporing bør være en del av rutingslaget, ikke en ettertanke.

På slutten av kjøringen, inspiser CrewAI-resultatet:

result, selected_models = run_with_fallback(topic)print("Selected models:")print(selected_models)print("Final result:")print(result.raw)print("Usage:")print(result.token_usage)

De eksakte bruksfeltene som er tilgjengelige kan avhenge av CrewAI-versjon og kjørevei, så behandle det returnerte resultatobjektet som sannhetskilde for versjonen du deployer.

En produksjons bruksregistrering bør ideelt inneholde:

job_idagentmodelinput_tokensoutput_tokenstotal_tokenslatency_msfallback_usedfallback_reasonstatuscreated_at

Dette lar deg besvare spørsmål som:

Hvilken agent bruker mest av budsjettet?

Hvor ofte faller analytikeren tilbake?

Hvilken modell har høyest latenstid?

Hvor mye koster hver arbeidsflyt?

---

Hvordan kontrollerer du kostnad på agentnivå?

Multimodell-ruting er mest nyttig når den reflekterer faktiske arbeidsmengdeforskjeller.

For eksempel:

Researcher→ high volume→ lower-cost modelAnalyst→ low volume→ stronger reasoning modelWriter→ medium volume→ general-purpose production model

Du kan også begrense kostnad gjennom agentkonfigurasjon.

For eksempel:

max_iter=3

avgrenser agentens iterasjons-loop. Det bør ikke tolkes som en hard grense på nøyaktig tre API-kall eller tre token-budsjetter.

Ytterligere kontroller inkluderer:

• begrense oppgavekontekst
• oppsummere mellomliggende utdata
• cache gjentakbar research
• begrense maksimal inputstørrelse
• begrense maks utgangstoken der det støttes
• begrense verktøyskall
• sette budsjetter per bruker
• sette budsjetter per arbeidsflyt
• spore fallback-frekvens

---

Hvordan validerer du modeller før deployering?

Ikke hardkod modell-ID-er for alltid.

En modell kan bli:

• utilgjengelig
• omdøpt
• avskrevet
• begrenset
• endret i kapasitet
• endret i pris
• inkompatibel med en parameter applikasjonen din bruker

CometAPI tilbyr et modellkatalog-endepunkt som kan spørres programmatisk, mens den offentlige modellkatalogen kan brukes for menneskelig modelldiscovery. 

En deployeringssjekk kan se slik ut:

curl -s \  https://api.cometapi.com/api/models \  -H "Authorization: Bearer $COMETAPI_KEY"

Valider deretter at de konfigurerte modell-ID-ene finnes før deployering.

For eksempel kan CI-prosessen din verifisere:

gemini-3.7-flash → availableclaude-opus-5    → availablegpt-5.6          → available

Ikke la tilgjengelighetssjekker erstatte applikasjonstesting. At en modell er til stede i en katalog betyr ikke at hver parameter, verktøy eller utdataformat brukt av CrewAI-agenten din er støttet.

---

Hvordan ser det komplette CrewAI-eksemplet ut?

Her er en konsolidert implementering:

import jsonimport osimport sysfrom collections.abc import Iteratorfrom dotenv import load_dotenvfrom openai import (    APIConnectionError,    APIStatusError,    APITimeoutError,)from crewai import Agent, Crew, LLM, Process, Taskload_dotenv()COMETAPI_KEY = os.environ["COMETAPI_KEY"]COMETAPI_BASE_URL = os.getenv(    "COMETAPI_BASE_URL",    "https://api.cometapi.com/v1",)PRIMARY_MODELS = {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6",}FALLBACK_MODELS = {    "researcher": "gpt-5.6",    "analyst": "gpt-5.6",    "writer": "gemini-3.7-flash",}def cometapi_llm(model_id: str) -> LLM:    return LLM(        model=model_id,        base_url=COMETAPI_BASE_URL,        api_key=COMETAPI_KEY,        timeout=60.0,        max_retries=0,    )def build_crew(model_map: dict[str, str]) -> Crew:    researcher = Agent(        role="Market Researcher",        goal="Collect the facts needed to answer the topic",        backstory=(            "You create concise, source-aware research briefs "            "and distinguish facts from assumptions."        ),        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 evaluate 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 write clear technical explanations "            "without unnecessary hype."        ),        llm=cometapi_llm(model_map["writer"]),        max_iter=3,        allow_delegation=False,    )    research_task = Task(        description=(            "Research this topic: {topic}. "            "Return the key facts, uncertainties, "            "and relevant sources."        ),        expected_output=(            "A concise research brief with facts "            "and open questions."        ),        agent=researcher,    )    analysis_task = Task(        description=(            "Using the research brief, analyze {topic}. "            "Identify the strongest conclusion and "            "explain the major trade-offs."        ),        expected_output=(            "A decision outline with evidence, "            "assumptions, risks, and trade-offs."        ),        agent=analyst,        context=[research_task],    )    writing_task = Task(        description=(            "Write a concise technical decision memo "            "about {topic}. State the recommendation early "            "and preserve important caveats."        ),        expected_output=(            "A polished technical decision memo in Markdown."        ),        agent=writer,        context=[            research_task,            analysis_task,        ],    )    return Crew(        agents=[            researcher,            analyst,            writer,        ],        tasks=[            research_task,            analysis_task,            writing_task,        ],        process=Process.sequential,        verbose=True,    )def exception_chain(    error: BaseException,) -> Iterator[BaseException]:    current = error    seen: set[int] = set()    while current is not None and id(current) not in seen:        seen.add(id(current))        yield current        current = (            current.__cause__            or current.__context__        )def should_fallback(error: BaseException) -> bool:    for current in exception_chain(error):        if isinstance(            current,            (                APIConnectionError,                APITimeoutError,            ),        ):            return True        if isinstance(current, APIStatusError):            return (                current.status_code in {408, 429}                or current.status_code >= 500            )    return Falsedef run_with_fallback(topic: str):    routes = [        PRIMARY_MODELS,        {            **PRIMARY_MODELS,            "writer": FALLBACK_MODELS["writer"],        },        {            **PRIMARY_MODELS,            "analyst": FALLBACK_MODELS["analyst"],            "writer": FALLBACK_MODELS["writer"],        },    ]    last_error = None    for attempt, model_map in enumerate(        routes,        start=1,    ):        try:            crew = build_crew(model_map)            result = crew.kickoff(                inputs={                    "topic": topic,                }            )            return result, model_map        except Exception as error:            last_error = error            if not should_fallback(error):                raise            if attempt == len(routes):                raise            print(                f"Transient failure on attempt "                f"{attempt}; trying fallback.",                file=sys.stderr,            )    raise RuntimeError(        "No model route completed the crew."    ) from last_errordef main():    topic = (        sys.argv[1]        if len(sys.argv) > 1        else (            "Should a small SaaS add "            "AI-generated meeting summaries?"        )    )    result, selected_models = (        run_with_fallback(topic)    )    output = {        "selected_models": selected_models,        "raw": result.raw,        "tasks_output": [            task.raw            for task in result.tasks_output        ],        "token_usage": str(            result.token_usage        ),    }    print(        json.dumps(            output,            indent=2,            default=str,        )    )if __name__ == "__main__":    main()

Den viktige forbedringen over den opprinnelige versjonen er at koden ikke lenger feilaktig antyder at et unntak identifiserer nøyaktig hvilken agent som feilet.

Det er eksplisitt en begrenset fallback-implementering på besetningsnivå.

For produksjon, kombiner den samme rutingspolicyen med CrewAI-sjekkpunkter.

---

Hvordan kjører du CrewAI-arbeidsflyten?

Lagre filen som:

crewai_multi_model.py

Kjør deretter:

python crewai_multi_model.py \  "Should a small SaaS add AI-generated meeting summaries?"

Et vellykket svar vil inneholde informasjon som ligner på:

{  "selected_models": {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6"  },  "raw": "<final decision memo>",  "tasks_output": [    "<research output>",    "<analysis output>",    "<writing output>"  ],  "token_usage": "<usage information>"}

Det eksakte svaret og bruksverdiene avhenger av input, modelladferd, CrewAI-versjon og kjørevei.

Hvis en retrybar feil aktiverer fallback-ruten, viser selected_models objektet ruten som ble brukt for den besetningskjøringen.

---

Hvordan bør du utforme modellruting i produksjon?

En produksjonspolicy for ruting bør vurdere mer enn modellkvalitet.

En nyttig beslutningsfunksjon er:

Model Score =Quality+ Reliability+ Context Fit+ Tool Compatibility- Cost- Latency

Du kan implementere dette på flere nivåer.

Kostnadsbasert ruting

Simple task → economical modelComplex task → premium model

Latenstidbasert ruting

Interactive request → fast modelBackground workflow → higher-quality model

Pålitelighetsbasert ruting

Primary model     ↓transient failure     ↓fallback model

Oppgavebasert ruting

Research → Model AAnalysis → Model BWriting → Model CCode → Model D

Den siste tilnærmingen er spesielt naturlig for CrewAI fordi rammeverket allerede gir hver agent en distinkt rolle.

---

Hvordan gjør du fallback trygg?

Et robust fallback-system bør håndheve fire regler.

Ikke fall tilbake ved autentiseringsfeil

Hvis API-nøkkelen er ugyldig:

401

vil ikke modellbytte løse problemet.

Ikke fall tilbake ved feilformatert forespørsel

Hvis forespørselen er ugyldig:

400422

fiks forespørselen i stedet.

Ikke fall tilbake ubegrenset

Sett en hard grense:

MAX_FALLBACK_ATTEMPTS = 2

Et fallback-system uten grense kan bli en kostbar retry-loop.

Gjør fallback-modeller forespørselskompatible

En fallback-modell må støtte funksjonene agenten din krever.

For eksempel, hvis den primære agenten krever et spesifikt verktøy eller strukturert utdata-adferd, må fallback-modellen støtte den samme kontrakten.

OpenAI-kompatibel betyr ikke funksjonskompatibel.

---

Hva er de vanligste CrewAI + CometAPI-feilene?

---

Hvordan skiller du CrewAI-feil fra modellfeil?

Denne distinksjonen er viktig ved feilsøking.

Konfigurasjonsfeil

Missing API keyInvalid model IDInvalid base URLUnsupported parameter

Disse bør feile raskt.

Leverandør/API-feil

401403404429500503

Disse krever ulik håndtering avhengig av status.

Applikasjonsfeil

Agent output invalidTool returned malformed dataTask context missingSide effect failed

Disse løses ikke nødvendigvis ved å bytte modeller.

Et modent agentsystem bør derfor ha separat håndtering for:

configuration      ↓API transport      ↓model execution      ↓agent logic      ↓tool execution      ↓application side effects

Dette er langt tryggere enn en generisk:

except Exception:    use_fallback()

---

Hvordan beskytter du eksterne sideeffekter?

Fallback blir betydelig mer komplisert når agenter gjør mer enn å generere tekst.

For eksempel, tenk deg en agent som:

1. oppretter en databasepost
2. sender en e-post
3. kaller et eksternt API
4. oppdaterer en CRM

Hvis modellen timeouter etter at den eksterne handlingen har lykkes, kan rerunning av hele besetningen duplisere handlingen.

Bruk:

• idempotensnøkler
• oppgavesjekkpunkter
• transaksjonsgrenser
• kjørings-ID-er
• varig oppgavestatus
• eksplisitt bekreftelse av sideeffekt

For eksempel:

job_id = crew_run_123task_id = writer_456

Lagre disse identifikatorene med eksterne operasjoner slik at en retry kan avgjøre om operasjonen allerede skjedde.

---

Hvordan overvåker du multimodell CrewAI-arbeidsflyter?

Minst, logg:

workflow_idagentmodeltaskstart_timeend_timelatencystatusfallback_usedfallback_reasoninput_tokensoutput_tokenstotal_tokens

Logg ikke:

API keysprivate credentialsfull sensitive promptsprivate user dataunredacted model output

For hver modell, overvåk:

Pålitelighet

success ratetimeout rate5xx ratefallback rate

Ytelse

p50 latencyp95 latencyp99 latency

Kostnad

input tokensoutput tokenscost per taskcost per completed workflow

Kvalitet

task success ratehuman evaluationstructured-output validitytool-call success

Dette gjør modellruting fra en hardkodet preferanse til et observerbart ingeniørsystem.

---

Hvordan velger du mellom direkte leverandør-API-er og CometAPI?

Valget avhenger av arkitekturen din.

Hvis applikasjonen din bare trenger én leverandør og dens native kapabiliteter, kan en direkte integrasjon være helt rimelig.

Hvis CrewAI-applikasjonen din trenger modeller fra flere leverandører og du vil ha ett tilgangslag, blir CometAPI mer attraktivt.

Det viktige poenget er at CometAPI ikke erstatter CrewAI.

I stedet:

CrewAIAgent orchestration       ↓CometAPIModel access       ↓Multiple models

Hvert lag har et annet ansvar.

---

Hvordan skalerer denne arkitekturen?

Når rutingspolicyen er separert fra agentdefinisjonene, krever det ikke å bygge hele applikasjonen på nytt for å legge til en annen modell.

For eksempel:

PRIMARY_MODELS = {    "researcher": "gemini-3.7-flash",    "analyst": "claude-opus-5",    "writer": "gpt-5.6",    "coder": "YOUR_CODE_MODEL",}

Den samme arkitekturen kan deretter støtte:

Research agentAnalysis agentCoding agentReview agentWriting agentFact-checking agent

Hver agent kan ha en annen modell samtidig som den deler det samme CometAPI-tilgangslaget.

Neste steg er å gjøre rutingen dynamisk.

I stedet for:

"analyst": "claude-opus-5"

kan du etter hvert bruke:

select_model(    task="analysis",    budget=budget,    latency_target=latency_target,)

Rutingsystemet kan deretter velge fra godkjente modeller basert på applikasjonskrav.

---

Hva er den beste produksjonsarkitekturen for CrewAI + CometAPI?

For en liten arbeidsflyt:

User Input   ↓CrewAI   ↓CometAPI   ↓Models

For produksjon:

                     ┌───────────────┐                     │ Model Catalog │                     └───────┬───────┘                             │                             ▼User → CrewAI → Routing Policy → CometAPI           │          │             │           │          │             ├── Gemini           │          │             ├── Claude           │          │             └── GPT           │          │           │          ▼           │     Cost / Quality /           │     Latency / Policy           │           ▼      Checkpoints           │           ▼      Usage Tracking

De viktigste produksjonskomponentene er:

1. Modell-allowlist
2. Ruting per agent
3. Begrensede retries
4. Sjekkpunkter per oppgave
5. Brukssporing
6. Kostnadskontroller
7. Kompatibilitetstesting for modeller
8. Observabilitet
9. Idempotente sideeffekter

Den arkitekturen er vesentlig mer robust enn bare å legge til en try/except rundt crew.kickoff().

---

Én CometAPI-nøkkel, ulike modeller, tydeligere agentroller

Den mest nyttige måten å tenke på CrewAI og CometAPI sammen er som to komplementære lag.

CrewAI definerer hva agentene gjør.

CometAPI definerer hvordan disse agentene får tilgang til modeller.

Den separasjonen gjør det mulig å tilordne en rask modell til en research-agent med høyt volum, en sterkere resonnementmodell til en analyseagent, og en general-purpose modell til den endelige skribenten uten å vedlikeholde separate leverandørintegrasjoner inne i arbeidsflyten.

Den enkleste implementeringen bruker én CometAPI-nøkkel og én OpenAI-kompatibel base-URL:

https://api.cometapi.com/v1

For produksjon, ta arkitekturen ett steg videre: hold modellruting i konfigurasjon, valider modelltilgjengelighet før deployering, bruk begrenset fallback kun for forbigående feil, sjekkpunkt fullførte oppgaver, og registrer modell- og bruksmetadata for hver kjøring.

Det gir deg et langt mer robust mønster enn bare å koble CrewAI til én LLM:

CrewAI orkestrerer agentene. CometAPI sentraliserer modelltilgang. Modell-ID-er styrer ruting. Sjekkpunkter beskytter fullført arbeid. Brukssporing kontrollerer kostnad.

---

Ofte stilte spørsmål

Kan CrewAI bruke flere AI-modeller i samme besetning?

Ja. Tilordne en annen LLM-konfigurasjon til hver CrewAI-agent. Hver konfigurasjon kan spesifisere sin egen modell mens den bruker samme CometAPI API-nøkkel og base-URL.

Kan CrewAI koble til et OpenAI-kompatibelt API?

Ja. CrewAIs LLM-konfigurasjon støtter en tilpasset base_url og API-nøkkel for OpenAI-kompatible endepunkter. 

Med CometAPI er base-URL-en:

https://api.cometapi.com/v1

Trenger jeg separate API-nøkler for GPT, Claude og Gemini?

Når du får tilgang til disse modellene gjennom CometAPI, kan applikasjonen bruke CometAPI-legitimasjonen og endepunktet i stedet for å implementere separate leverandørlegitimasjoner i hver CrewAI-agent.

Betyr én API-nøkkel at modellene har identiske kapabiliteter?

Nei. API-grensesnittet kan være forent mens modellkapabilitetene forblir forskjellige. Kontekstvinduer, verktøystøtte, parametere, utputsadferd, latenstid og prising kan variere per modell.

Bør jeg forsøke på nytt hele CrewAI-arbeidsflyten når én modell feiler?

Bare for enkle, tilstandsløse arbeidsflyter. En full besetningsretry kan gjenta fullførte oppgaver og øke kostnad. For produksjon, sjekkpunkt fullførte oppgaver og gjenoppta fra den mislykkede delen der det er praktisk.

CrewAIs nåværende sjekkpunktfunksjonalitet er designet for å bevare kjøringsstatus og gjenoppta etter feil. 

Bør hvert CrewAI-unntak utløse modellfallback?

Nei. Autentisering, feilformatert forespørsel, ugyldige modell-ID-er og ikke-støttede parametere krever generelt konfigurasjonsendringer i stedet for en annen modell.

Fallback er bedre reservert for begrensede forbigående feil som timeouts, ratelimiting og midlertidige 5xx-responser.

Hvordan sporer jeg kostnaden for hver CrewAI-agent?

Registrer agentnavn, modell-ID, tokenbruk, latenstid, kjøringsstatus og fallback-informasjon for hver oppgave. Bruk de resulterende dataene til å beregne kostnad per agent og arbeidsflyt.

Kan jeg dynamisk endre modellen som er tilordnet en agent?

Ja. Hold modell-ID-er i en rutingskonfigurasjon i stedet for å legge dem direkte inn i agentdefinisjonene. Applikasjonen din kan deretter velge modeller basert på kostnad, latenstid, oppgavetype eller tilgjengelighet.

Er CometAPI en erstatning for CrewAI?

Nei. De opererer på ulike lag. CrewAI orkestrerer agenter og oppgaver, mens CometAPI gir et forent lag for modelltilgang.

Hvor kan jeg finne de nåværende CometAPI-modellene?

Bruk CometAPI modellkatalog for menneskelig modelldiscovery og modell-API for programmatisk validering. CometAPIs nåværende hurtigstartside lister 500+ modeller på tvers av tekst-, bilde-, video- og lydkategorier. 

---

Kilder

• CometAPI Hurtigstart
• CometAPI modellkatalog
• CometAPI API-dokumentasjon
• CometAPI Python SDK
• CrewAI-dokumentasjon
• CrewAI LLM-konfigurasjon
• CrewAI-sjekkpunkter