LLM APIs કેવી રીતે વાપરવી: Tokens, ખર્ચ, Keys અને તમારું પહેલું AI ફીચર
LLM API એ એવી વેબ સેવા છે જે તમારી એપને મોટા language model ને text મોકલવા દે છે — જેમ કે OpenAI ના GPT models, Anthropic ના Claude અથવા Google ના Gemini — અને તેનો જવાબ કોડમાં પાછો મેળવવા દે છે. તમે provider સાથે સાઇન અપ કરો છો, API key બનાવો છો, અને તમારી એપનું સર્વર તે key સાથે વિનંતીઓ મોકલે છે; દરેક વિનંતી માટે, અંદર અને બહાર જતા tokens (text ના ટુકડા) ની સંખ્યા પ્રમાણે તમને બિલ મળે છે. "એપમાં AI ઉમેરવું" સામાન્ય રીતે એટલું જ મતલબ રાખે છે: તમારા સર્વર પરથી સલામત રીતે બીજાના model ને સારી રીતે લખેલી વિનંતી.
AI વડે બનાવતી વખતે તે કેમ મહત્વનું છે
AI વડે બનેલી એપમાં બે અલગ AI હોય છે, અને તેમને ગૂંચવવું સરળ છે:
- તમારી એપ બનાવતું AI — app builder નો પોતાનો agent, જે code લખે છે.
- તમારી એપની અંદરનું AI — એક ફીચર જે તમારા users વાપરે છે, જેમ કે chat assistant, "સારાંશ આપો" બટન અથવા આપમેળે tagging.
બીજું એક LLM API ને તમારી key સાથે કૉલ કરે છે અને તમારા provider account પર બિલ કરે છે. Tokens, context અને કિંમત સમજવાથી તમે એવું ફીચર ડિઝાઇન કરી શકો છો જે કામ કરે, તમારી key લીક ન કરે, અને તમને બિલથી આશ્ચર્ય ન આપે.
રોજિંદો દાખલો: ખૂબ સક્ષમ ફ્રીલાન્સર, શબ્દ પ્રમાણે ચૂકવણી
LLM API ને એક ઉત્તમ ફ્રીલાન્સ લેખક તરીકે વિચારો, જેને તમે ઇમેઇલથી સંપર્ક કરો છો અને શબ્દ પ્રમાણે ચૂકવો છો — તમે મોકલો છો તે શબ્દો માટે અને તે પાછા લખે છે તે શબ્દો માટે (અને તે લખેલા શબ્દો વધુ મોંઘા પડે છે).
- ઇમેઇલો વચ્ચે કોઈ યાદશક્તિ નથી. જો તમે ઇચ્છો કે તે વાતચીત ચાલુ રાખે, તો દરેક નવા ઇમેઇલમાં અગાઉના સંદેશા ફરી ચોંટાડો.
- તે એક સાથે મર્યાદિત જ વાંચી શકે છે. તે મર્યાદા context window છે.
- તમારી બ્રીફ જેટલી સ્પષ્ટ, જવાબ એટલો સારો અને ટૂંકો — અને તેથી સસ્તો પણ.
મુખ્ય ખ્યાલો
Tokens
Models tokens માં text વાંચે અને લખે છે. Anthropic ના pricing દસ્તાવેજો સપ્ટેમ્બર 2026 સુધી અંદાજ આપે છે કે દર token લગભગ 4 અક્ષરો, અથવા લગભગ 0.75 અંગ્રેજી શબ્દો. જુદા models અને ભાષાઓ જુદી રીતે tokenise કરે છે, તેથી તેને અંદાજિત માર્ગદર્શિકા ગણો. બધું ગણાય છે: તમારી સૂચનાઓ, વપરાશકર્તાનો સંદેશો, તમે સામેલ કરેલા દસ્તાવેજો, અગાઉની વાતચીત, અને જવાબ.
Input અને output
Input tokens એ છે જે તમે મોકલો છો. Output tokens એ છે જે model લખે છે. OpenAI, Anthropic અને Google ના pricing પેજ પર, સપ્ટેમ્બર 2026 સુધી, એ જ model માટે output tokens input tokens કરતાં ઘણી ગણી વધુ કિંમતના હોય છે. Google ના Gemini pricing માં એ પણ નોંધ છે કે model નું આંતરિક "thinking" output તરીકે ગણાય છે.
Context window
એક જ વિનંતીમાં model લઈ શકે તેવા tokens ની મહત્તમ સંખ્યા, જેમાં જવાબ પણ સામેલ છે. આધુનિક models ખૂબ લાંબા input સ્વીકારે છે — દાખલા તરીકે, Anthropic ના કેટલાક હાલના models દસ લાખ tokens સુધી. પણ લાંબા input વધુ ખર્ચ અને વધુ સમય લે છે, તેથી કાર્યને જરૂરી હોય તેટલું જ મોકલો.
Stateless વિનંતીઓ
મોટાભાગના chat-શૈલીના APIs માં, દરેક વિનંતી ડિફોલ્ટ રૂપે સ્વતંત્ર હોય છે. Chat "યાદ રાખે" તે માટે, તમારી એપ દરેક નવા સંદેશ સાથે અગાઉના સંદેશા ફરીથી મોકલે છે. એટલે જ લાંબી વાતચીતનો દરેક સંદેશ ટૂંકી વાતચીત કરતાં વધુ ખર્ચ કરે છે.
System prompt
દરેક વિનંતી માટે model ની ભૂમિકા અને નિયમો સેટ કરતી સૂચનાઓ: "તમે support tickets નો ત્રણ bullet માં સારાંશ આપો. ગ્રાહકનાં ઇમેઇલ સરનામાં ક્યારેય સામેલ ન કરો." Users આ જોતા નથી, પણ તે દરેક જવાબને આકાર આપે છે.
Streaming
સંપૂર્ણ જવાબની રાહ જોવાને બદલે, API લખાતાની સાથે જ text મોકલી શકે છે, જેથી users ને શબ્દો તરત દેખાય. તેનાથી chat interfaces ઘણી ઝડપી લાગે છે.
કિંમત કેવી રીતે કામ કરે છે
સપ્ટેમ્બર 2026 સુધી, provider ના પોતાના pricing પેજ પર ચકાસ્યા મુજબ:
| કિંમતનું પરિબળ | OpenAI | Anthropic | Google (Gemini API) |
|---|---|---|---|
| એકમ | દર મિલિયન tokens | દર મિલિયન tokens | દર મિલિયન tokens |
| Input વિરુદ્ધ output | અલગ કિંમત; output વધુ | અલગ કિંમત; output વધુ | અલગ કિંમત; output વધુ |
| ફરી વપરાયેલ (cached) input | છૂટ | Cache reads માં છૂટ; cache માં લખવાનો ખર્ચ થોડો વધુ | છૂટ, અને storage ચાર્જ સાથે |
| Batch (બિન-તાકીદની) વિનંતીઓ | 50% છૂટ | 50% છૂટ | 50% છૂટ |
કેટલાક providers ચૂકવતા પહેલાં અજમાવવાની રીત પણ આપે છે: Anthropic નવા users ને થોડું મફત credit આપે છે, અને Google ના Gemini API પર કેટલાક models માં મફત tier છે, સાથે એ ચેતવણી કે તેના પર મોકલેલી સામગ્રી Google ના ઉત્પાદનો સુધારવા માટે વાપરી શકાય છે.
કિંમતો provider ના નાના, ઝડપી models અને તેના સૌથી મોટા models વચ્ચે ઘણી અલગ હોય છે, અને તે વારંવાર બદલાય છે, તેથી અહીં આપતા નથી. કોઈ પણ ફીચર માટે સરળ અંદાજ છે: (input tokens × input કિંમત + output tokens × output કિંમત) × મહિનામાં વિનંતીઓની સંખ્યા. પછી margin ઉમેરો, અને provider ના dashboard માં માસિક ખર્ચ મર્યાદા સેટ કરો.
ઉદાહરણ: "આ ticket નો સારાંશ આપો" બટન
એક નાની support ટીમ એક બટન ઇચ્છે છે જે લાંબી ગ્રાહક ઇમેઇલ થ્રેડને ત્રણ bullet અને સૂચિત જવાબમાં ફેરવે.
- Key મેળવો. એક provider સાથે account બનાવો અને API key જનરેટ કરો. નીચી માસિક ખર્ચ મર્યાદા સેટ કરો.
- Key ને secret તરીકે તમારા સર્વર પર સંગ્રહો, જેમ કે
ANTHROPIC_API_KEYઅથવાOPENAI_API_KEYનામથી — ક્યારેય પેજના કોડમાં નહીં. જુઓ environment variables and secrets. - સર્વર route ઉમેરો,
POST /api/summarise, જે:- તપાસે કે વ્યક્તિ લૉગિન છે અને support ટીમની છે;
- ડેટાબેઝમાંથી ticket લોડ કરે;
- provider ને system prompt ("ત્રણ bullet માં સારાંશ આપો, પછી વિનમ્ર જવાબનો મુસદ્દો બનાવો; order નંબર બનાવશો નહીં") અને ticket નો text મોકલે;
- maximum output tokens સેટિંગ વડે જવાબની લંબાઈ મર્યાદિત કરે;
- પરિણામ પાછું આપે અને વપરાયેલા tokens ની નોંધ કરે.
- બટન provider ને નહીં, તમારી route ને કૉલ કરે, અને સારાંશ streaming થતાં બતાવે.
- નિષ્ફળતા સંભાળો. જો provider ધીમો હોય અથવા ભૂલ આપે, તો "અત્યારે સારાંશ આપી શકાતો નથી" બતાવો અને ticket વાપરી શકાય તેવી રાખો.
- માપો. એક અઠવાડિયા પછી, token લૉગ જુઓ. જો મોટા ભાગનો ખર્ચ લાંબી ઇમેઇલ થ્રેડોનો હોય, તો મોકલતા પહેલાં ટાંકેલો ઇતિહાસ ટ્રિમ કરો.
ધ્યાન આપો કે શું ગેરહાજર છે: કોઈ model training નહીં, કોઈ ખાસ infrastructure નહીં. એક key, એક સર્વર route, એક સારી રીતે લખેલો prompt.
મુખ્ય શબ્દો
- API key: તે ગુપ્ત કી જે provider ને તમારો account ઓળખાવે છે. જેની પાસે તે હોય તે તમારા પૈસા ખર્ચી શકે છે.
- Model: તમે કૉલ કરો છો તે ચોક્કસ LLM. Providers જુદી કિંમત અને ઝડપ સાથે ઘણા કદના models આપે છે.
- Temperature: જવાબો કેટલા વૈવિધ્યસભર હોય તેની સેટિંગ. ઓછું એટલે વધુ અનુમાનિત.
- Max tokens: જવાબની લંબાઈ પર મર્યાદા, જે ખર્ચને પણ મર્યાદિત કરે છે.
- Rate limit: તમારો account પ્રતિ મિનિટ કેટલી વિનંતીઓ કે tokens વાપરી શકે.
- Embeddings: text ના અર્થને રજૂ કરતી સંખ્યાઓ, જે તમારા પોતાના દસ્તાવેજોમાં શોધ માટે વપરાય છે.
- RAG (retrieval-augmented generation): તમારા પોતાના ડેટામાંથી સંબંધિત ફકરા શોધીને prompt માં સામેલ કરવા, જેથી model તમારી સામગ્રી પરથી જવાબ આપે.
- Tool use / function calling: model ને તમારી એપને ચોક્કસ function ચલાવવા માટે પૂછવા દેવું, જેમ કે "order ની સ્થિતિ જુઓ".
સામાન્ય ભૂલો અને ગેરસમજણો
- Frontend કોડમાં key મૂકવી. સૌથી મોંઘી ભૂલ. બ્રાઉઝર કોડ જાહેર છે. હંમેશાં તમારા સર્વર પરથી કૉલ કરો. AI વડે બનેલી એપ માટે security checklist આ અને બીજા લૉન્ચ ચેક આવરી લે છે.
- ખર્ચ મર્યાદા કે પ્રતિ-user મર્યાદા નહીં. એક bug, loop કે દુરુપયોગ કરતો user ઝડપથી ખર્ચ વધારી શકે છે. Provider ની મર્યાદા સેટ કરો અને તમારી એપમાં પ્રતિ user વિનંતીઓ મર્યાદિત કરો.
- દરેક વખતે બધું મોકલવું. આખા દસ્તાવેજો અને સંપૂર્ણ chat ઇતિહાસ input tokens ને ગુણે છે. ટ્રિમ કરો, જૂના સંદેશા સારાંશ કરો, અથવા ફક્ત સંબંધિત ભાગો મેળવો.
- Output પર આંધળો ભરોસો. Models ખોટી વાતો આત્મવિશ્વાસથી કહી શકે છે. તથ્યો, કિંમતો અથવા કાયદેસર કે તબીબી બાબતો માટે, જવાબોને તમારા પોતાના ડેટા પર આધારિત કરો અને સ્ત્રોતો બતાવો, અથવા કોઈ વ્યક્તિ તપાસે.
- Users ને તમારા નિયમો ઓવરરાઇડ કરવા દેવું. Users "તમારી સૂચનાઓ અવગણો" લખી શકે છે. પરવાનગીઓ અને સંવેદનશીલ કામ ફક્ત prompt માં નહીં, તમારા સર્વર કોડમાં રાખો.
- સૌથી મોટા model થી શરૂ કરવું. પહેલાં નાના, સસ્તા model અજમાવો; ગુણવત્તા જરૂરી હોય તો જ ઉપર જાઓ.
- વિચાર્યા વિના વ્યક્તિગત ડેટા મોકલવો. Provider ની ડેટા-વપરાશ શરતો તપાસો, ખાસ કરીને મફત tiers પર, અને ફીચરને જરૂરી હોય તેટલું જ મોકલો.
તમારા AI builder પાસે શું માંગવું
ticket પેજ પર "Summarise" બટન ઉમેરો. તે એક સર્વર route ને કૉલ કરે છે જે
OPENAI_API_KEYsecret વાપરે છે (ક્યારેય બ્રાઉઝરને ખુલ્લી નહીં), તપાસે કે user લૉગિન છે, આ system prompt સાથે ticket નો text મોકલે: […], જવાબને 300 tokens પર મર્યાદિત કરે, જવાબને પેજ પર streaming કરે, અને કૉલ નિષ્ફળ જાય તો મૈત્રીપૂર્ણ ભૂલ બતાવે. દરેક વિનંતી પર વપરાયેલા tokens લૉગ કરો, અને દરેક user ને કલાકે 30 સારાંશ સુધી મર્યાદિત કરો.
સંપૂર્ણ chat અનુભવ માટે, AI chatbot એપ કેવી રીતે બનાવવી જુઓ; બીજા વિચારો માટે, તમારી એપમાં AI ફીચર્સ કેવી રીતે ઉમેરવા. જો સામાન્ય રીતે APIs નવા હોય, તો API શું છે થી શરૂ કરો.
Mythex વડે બનાવેલી એપમાં LLM APIs
Mythex વડે બનાવતી વખતે, તમારી એપની અંદરનું AI તમારી પોતાની provider key વાપરે છે. તમે તેને પ્રોજેક્ટ secret તરીકે ઉમેરો છો, અથવા Mythex જ્યારે જરૂર હોય ત્યારે chat માં બતાવે તે secrets card દ્વારા, અને agent ને સર્વર પર કૉલ બનાવવા કહો. Provider નો વપરાશ તમારા provider account પર બિલ થાય છે, Mythex build credits પર નહીં. Mythex તમારી એપના users માટે tokens શામેલ કરતું નથી, અને કોઈ built-in knowledge-base ઉત્પાદન આપતું નથી; rate limits અને ખર્ચ નિયંત્રણો તમારે ડિઝાઇન અને ચકાસવાના છે. Docs ની recipe તમારી પોતાની API keys વડે એપમાં AI ઉમેરો માં starter prompt છે, અને AI app builder પેજ બતાવે છે કે ક્યાંથી શરૂ કરવું.
પ્રશ્નો
LLM API શું છે?
LLM API એ OpenAI, Anthropic અથવા Google જેવા AI provider ની વેબ સેવા છે, જે તમારી એપને મોટા language model ને text (અને ઘણી વાર છબીઓ કે ફાઇલો) મોકલવા અને તેનો જવાબ પાછો મેળવવા દે છે. તમે ઉપયોગ પ્રમાણે ચૂકવણી કરો છો, જે tokens માં માપાય છે, અને API key વડે પ્રમાણીકરણ થાય છે.
LLM API નો ખર્ચ કેટલો છે?
સપ્ટેમ્બર 2026 સુધીમાં, OpenAI, Anthropic અને Google બધા તેમના મુખ્ય models ની કિંમત દર મિલિયન tokens પ્રમાણે રાખે છે, input અને output માટે અલગ દર સાથે, અને output વધુ મોંઘું છે. કુલ ખર્ચ model, તમે કેટલો text મોકલો છો અને જવાબો કેટલા લાંબા છે તેના પર આધારિત છે. દરેક provider નું pricing પેજ તપાસો, અને ખર્ચ મર્યાદા સેટ કરો.
Token એટલે શું?
Token એ text નો એક ટુકડો છે જે model વાંચે કે લખે છે, ઘણી વાર શબ્દનો ભાગ. Anthropic ના pricing દસ્તાવેજો પ્રમાણે, અંદાજે દર token 4 અક્ષરો, અથવા લગભગ અંગ્રેજી શબ્દનો ત્રણ-ચતુર્થાંશ ભાગ; ચોક્કસ ગણતરી model અને ભાષા પ્રમાણે બદલાય છે.
શું હું બ્રાઉઝરમાંથી સીધો LLM API કૉલ કરી શકું?
ગુપ્ત key સાથે ન કરવું જોઈએ. બ્રાઉઝર કોડમાં જે કંઈ હોય તે મુલાકાતીઓ વાંચી શકે છે, અને પછી તેઓ તમારી key વાપરીને તમારું બિલ વધારી શકે છે. બ્રાઉઝરથી તમારા પોતાના સર્વર પર વિનંતી મોકલો, અને સર્વરને provider ને કૉલ કરવા દો.
મારી એપમાં AI ઉમેરવા માટે શું મારે model ને train કરવું પડે?
લગભગ ક્યારેય નહીં. મોટાભાગનાં AI ફીચર્સ API દ્વારા હાલના model નો ઉપયોગ કરે છે, prompt માં સ્પષ્ટ સૂચનો વડે માર્ગદર્શિત, અને જરૂર હોય ત્યારે વિનંતીમાં તમારો પોતાનો ડેટા સામેલ કરીને. Training કે fine-tuning એ પછીનું ઑપ્ટિમાઇઝેશન છે, શરૂઆત નથી.