Ituro ang Aider sa isang OpenAI-compatible API base.

Mabilisang sagot: dalawang env var at isang model prefix.

Eksaktong ganito ang naka-document na OpenAI-compatible na path ng Aider: i-export ang OPENAI_API_BASE gamit ang iyong endpoint, i-export ang OPENAI_API_KEY gamit ang key para dito, at i-prefix ang pangalan ng model ng openai/ para makipag-usap ang Aider sa protocol na chat-completions sa base na iyon. Ang string pagkatapos ng prefix ay ipinapasa nang buo sa endpoint, kaya patas na laruan ang anumang id na si-serve ng gateway, kasama ang mga Claude at DeepSeek id. Iyon na ang buong koneksyon. Sa Mac at Linux gamitin ang export; sa Windows gamitin ang setx at magbukas ng bagong shell, dahil hindi apektado ng setx ang kasalukuyang session. Maaaring manirahan ang parehong mga value sa config file ng Aider o sa isang .env file kung mas gusto mo ang per-project na configuration kaysa sa shell state.

export OPENAI_API_BASE=https://api.apisrouter.com/v1
export OPENAI_API_KEY=sk-APIsRouter-...

aider --model openai/claude-sonnet-4-6

Paano nilulutas ng Aider ang mga model at provider.

Ang Aider (Aider-AI sa GitHub, humigit-kumulang 47K stars) ang orihinal na terminal pair programmer: mine-map nito ang git repo mo, tumatanggap ng mga change request sa chat, direktang nag-e-edit ng mga file, at nagko-commit ng resulta. Sa ilalim, iniruruta nito ang mga tawag sa model sa pamamagitan ng litellm, kaya mahalaga ang openai/ prefix: binabasa ng litellm ang prefix para pumili ng provider protocol, at ang ibig sabihin ng openai/ ay "chat-completions laban sa kahit anong sinasabi ng OPENAI_API_BASE." Ang isang model name na walang prefix ay nagki-conclude ng provider batay sa spelling nito sa halip, na iniruruta ang isang Claude id patungo sa native na API ng Anthropic at sa iyong ANTHROPIC_API_KEY sa halip na sa iyong gateway. May isang gawi na specific sa Aider na mahalagang malaman bago ang unang session mo: nagpapanatili ito ng sariling registry ng mga kakayahan ng model, at ang isang model na hindi nito nakikilala ay nagti-trigger ng babalang "Unknown context window size and costs, using sane defaults", pagkatapos ay ipinapalagay ng Aider na walang limitasyon ang context window at zero ang gastos. Gumagana pa rin ang session, pero dalawang kapaki-pakinabang na subsystem ang nagbababa ng kalidad: hindi maaaring magbabala ang token budgeting bago ka lumampas sa tunay na context limit, at nagbabasa ng zero ang in-session cost display. Ang solusyon ay isang maliit na metadata file, sakop sa ibaba, at sulit ang dalawang minuto para dito. Higit sa isang model din ang pinapatakbo ng Aider kada session. Ang main model ang gumagawa ng coding; hinahawakan ng weak model ang mga commit message at chat summarization; at sa architect mode, may hiwalay na editor model na nagpapatupad ng plano. Tumatanggap ang bawat isa ng parehong openai/ prefix, kaya maaaring dumaan ang lahat ng tatlo sa gateway gamit ang isang key.

Buong setup: koneksyon kasama ang model metadata.

Ang koneksyon ang dalawang variable sa itaas. Ang pino ay ang pagre-register ng metadata para ituring ng Aider ang mga model ng gateway bilang kilalang dami. Gumawa ng .aider.model.metadata.json sa iyong home directory, ang git repo root, o ang working directory (o ipasa ang --model-metadata-file), naka-key sa buong pangalan kasama ang openai/ prefix; dapat tumugma ang litellm_provider field sa prefix na iyon. Kapag naka-register ang max_input_tokens, gumagana ang context budgeting ng Aider laban sa tunay na window ng model sa halip na ipagpalagay na walang hangganan ito. Isang pangalawang opsyonal na file, .aider.model.settings.yml, ang nagtutune ng behavior bawat model: kinokontrol ng edit_format kung paano hihiling ang Aider ng mga pagbabago sa code (diff variants para sa mga model na kayang harapin ang mga ito, whole-file para sa hindi kaya), at kinokontrol ng use_repo_map ang inclusion ng repo-context. Hindi maaaring i-infer ng Aider ang pinakamahusay na edit format para sa isang model na hindi nito nakikilala, kaya ang pagdedeklara nito ang pagkakaiba sa pagitan ng isang model na mukhang katamtaman at isang gumaganap sa antas nito.

{
  "openai/claude-sonnet-4-6": {
    "max_input_tokens": 200000,
    "max_output_tokens": 64000,
    "litellm_provider": "openai",
    "mode": "chat"
  },
  "openai/deepseek-v4-pro": {
    "max_input_tokens": 128000,
    "max_output_tokens": 16000,
    "litellm_provider": "openai",
    "mode": "chat"
  }
}

Pagpili ng main, weak, at editor models.

Mahaba at umuulit ang mga session ng Aider, na ginagawang lalong tapat ang paghahambing ng model dito: patakbuhin ang parehong feature branch gamit ang dalawang main model sa magkaibang araw at lumitaw ang pagkakaiba sa kung gaano ka kadalas mag-type ng /undo. Isang endpoint ang nagpapagawa ng bawat kandidato na maging isang flag change lamang, at pinepresyuhan ng per-key usage ang bawat eksperimento.

• Dinadala ng main model ang bawat edit. Binabasa nito ang repo map, nangangatwiran sa iyong mga file, at gumagawa ng mga diff, kaya rito nabibilang ang claude-sonnet-4-6 o gpt-5.5; ang isang model na napapahamak sa diff syntax ay gumagastos sa iyo ng oras ng review sa bawat pagbabago.
• Isinusulat ng weak model (--weak-model) ang mga commit message at binubuod ang chat history. Madalas itong tumatakbo at hindi kailanman humihipo sa code, kaya iruta ito sa isang mabilis, mababang-presyo na id sa pamamagitan ng parehong gateway sa halip na hayaang mag-default ito sa iba.
• Hinahati ng architect mode ang pagpaplano mula sa pag-e-edit: nagpaplano ang main model, ipinapatupad ng editor model (--editor-model) ang plano. Ang isang malakas na reasoner na nagpaplano na may isang coding-tuned na id tulad ng kimi-k2.7-code na nagpapatupad ay isang pagpapares na hindi kayang ipahayag ng mga single-vendor na key.
• Sulit i-benchmark ang deepseek-v4-pro at gpt-5.4 bilang mga daily-driver na main model sa trabahong puno ng refactor, kung saan tumitindi ang pagkakaiba sa presyo dahil sa per-session na token volume.

Pay-as-you-go · mas mababa sa opisyal na presyo

Selected models are priced below official list prices. Exact input, output, cache, and per-request prices are shown for each model.

Ang mga failure mode na specific sa Aider.

Pagtitiwala sa "sane defaults." Ang unknown-model fallback ay nag-aakalang walang limitasyon ang context at zero ang gastos. Sa praktika, ibig sabihin nito, hahayaan ng Aider ang isang mahabang session na lumaki lampas sa tunay na window ng model hanggang tanggihan ito ng gateway o tahimik na mawala ang unang context ng model, at buong panahon ay walang ipinapakita ang cost tracker. I-register ang metadata; nawawala ang dalawang problema. Ang pagtanggal ng openai/ prefix. Kapag wala ito, nagki-conclude ang litellm ng provider batay sa pangalan ng model. Iniruruta ang mga Claude id patungo sa API ng Anthropic at nabibigo sa nawawalang ANTHROPIC_API_KEY, na tila problema sa key gayong problema sa prefix. Metadata na hindi tumutugma. Ang mga entry sa .aider.model.metadata.json ay naka-key sa buong pangalan, kasama ang prefix, at dapat sumang-ayon ang litellm_provider sa prefix na iyon. Ang isang bare-id na key o isang di-tugmang provider field ay tahimik na nabibigong ma-apply, at nasa defaults ka na naman nang walang error na nagsasabi nito. Windows shell state. Isinusulat ng setx ang variable para sa mga susunod na shell lamang. Ang pagpapatakbo ng aider sa parehong terminal kung saan mo lang pinatakbo ang setx ay gumagamit ng lumang environment, at ang 401 na resulta ay isyu sa shell lifecycle, hindi isyu sa credentials. Ang maling edit format. Ang isang hindi naka-register na model ay tumatanggap ng default na edit format na maaaring hindi ang pinaka-mahusay nitong kaya. Kung patuloy na gumagawa ang isang malakas na model ng mga edit na tinatanggihan ng Aider, itakda nang tahasan ang edit_format sa .aider.model.settings.yml bago tapusin na hindi marunong mag-code ang model.

Sino ang nagru-route ng Aider sa pamamagitan ng isang gateway.

• Mga araw-araw na user ng Aider na gustong mapagpalit-palit ang Claude, GPT, at DeepSeek bawat session gamit ang --model, nang hindi nagpapanatili ng vendor account bawat model family.
• Mga developer na nagpapares ng frontier na main model kasama ang mabilis na weak model para sa mga commit message, pareho bini-bill sa isang key na may per-session na visibility.
• Mga user ng architect mode na naghahalo ng planning model at editing model mula sa magkaibang vendor sa parehong session.
• Mga team na nagpapasok ng mga engineer gamit ang isang secret sa halip na checklist ng vendor key bawat isa, na may per-key usage bilang ulat ng gastos.
• Mga developer na walang access sa billing ng isang partikular na vendor. Inaalis ng top-up based na access na walang kailangang card ang per-provider na sign-up dependency.

I-verify ang endpoint at i-debug ang unang session.

Ilista ang mga model ng gateway bago magsimula; dapat eksaktong tumugma ang id pagkatapos ng openai/ sa isang na-serve na id, kasama ang mga version suffix. Mabilis na maayos ang mga pagkabigo sa unang session. Ang 401 ay nangangahulugang hindi nakikita ng shell na naglunsad ng aider ang OPENAI_API_KEY (mga bagong shell lamang sa Windows pagkatapos ng setx; suriin ang echo sa parehong terminal). Ang model-not-found na error mula sa gateway ay typo sa id. Ang error na binabanggit ang isang ibang vendor na key ay nangangahulugang isang prefixless na model name ang iniruta nang native. At ang unknown-model na babala sa startup ay hindi error, pero ito ang senyales mo na idagdag ang metadata file bago ang isang mahabang session, hindi pagkatapos itong tamaan ang tunay na context limit. Sa session, nagiging tumpak ang sariling token at cost readout ng Aider sa sandaling naka-register ang metadata, at ipinapakita ng APIsRouter console ang parehong mga session mula sa panig ng endpoint: per-request na model, token counts, at gastos. Para sa isang buong-araw na pair programmer, ang per-key na view na iyon ang tapat na sagot sa kung magkano talaga ang gastos ng isang linggo ng Aider.

curl -s https://api.apisrouter.com/v1/models \
  -H "Authorization: Bearer $OPENAI_API_KEY" | head -50

Mga madalas itanong