Paritok token gatewayతో coding agent ఖర్చు తగ్గుతుందా?

అభ్యర్థనపై Paritok చేసే పని

Paritok ఒక token gateway: ఇది మీ coding agent మరియు model API మధ్య ఉండే proxy. ప్రతి అభ్యర్థనను provider కు పంపే ముందు ఇది compress చేస్తుంది. మీ agent provider కు కాకుండా http://127.0.0.1:8080 కు కనెక్ట్ అవుతుంది. Proxy tool schemas, file reads, tool output మరియు పాత turns ను తిరిగి రాస్తుంది. తరువాత చిన్న payload ను upstream కు పంపి, వచ్చిన reply ను మార్పు లేకుండా తిరిగి అందిస్తుంది.

Provider కు చేరిన డేటా ఆధారంగానే మీకు billing జరుగుతుంది. అందువల్ల payload చిన్నగా ఉంటే invoice కూడా చిన్నగా ఉంటుంది. ఇదే మొత్తం ఆలోచన. ఇది “మీ context ఎక్కువసేపు ఉంటుంది” అనే వాదనకు భిన్నమైనది. ఈ కారణంగానే ఈ tool కేవలం tidy చేసే సాధనం కాకుండా ఆసక్తికరంగా ఉంటుంది.

ఈ project ఇంకా ప్రారంభ దశలోనే ఉంది. దీని మొదటి public tags July 2026 నాటివి. ప్రస్తుత tag v1.3.0, తేదీ 5 August 2026. Weights మరియు gateway code Apache 2.0 లైసెన్స్‌లో ఉన్నాయి. Compression model అనేది Qwen3-4B-Instruct-2507 పై రూపొందించిన LoRA (low-rank adaptation) adapter. ఇది నిజమైన coding-agent trajectories నుంచి తీసుకున్న 45,000 teacher-distilled samples పై train చేశారు.

ఇది context trimming ఎందుకు కాదు

Trimming తొలగిస్తుంది. ఒక agent తన context పరిమితికి చేరువైనప్పుడు, అత్యంత పాత turns ను వదిలేస్తే, turn 3లో అది చదివిన file కనిపించదు. turn 20లో ఆ file అవసరమైతే, అది file ను మళ్లీ చదవాలి. అందువల్ల ఆ tokens కోసం రెండోసారి చెల్లించాలి. ఆ saving తాత్కాలిక అప్పు మాత్రమే.

Paritok ఒక segment ను చిన్న రూపం మరియు [REF:id] tag తో భర్తీ చేస్తుంది. పూర్తి text proxy పై అలాగే ఉంటుంది. Model read_original లేదా expand_context ను call చేయడం ద్వారా segment ను తిరిగి పొందుతుంది. దీనివల్ల failure mode మారుతుంది. Trimmer మర్చిపోవడం ద్వారా విఫలమవుతుంది, కానీ అది జరిగినట్లు మీకు ఎప్పుడూ తెలియజేయదు. Compressor model కు సమాచారాన్ని కోల్పోయిన summary ను అందించడం ద్వారా విఫలమవుతుంది. ఆ summary సరిపోనప్పుడు model original ను అడగగలదు.

Tool filter కూడా ఇదే విధంగా పనిచేస్తుంది. Filter చేసిన tool schemas తొలగించబడవు; వాటి స్థానంలో stubs ఉంచబడతాయి. Model gateway_search_tools ను call చేయడం ద్వారా ఒక tool schema ను తిరిగి పొందుతుంది. ఇది ముఖ్యమైనది. Tool ను శాశ్వతంగా దాచే filter, మీ agent చేయగల పనులను మార్చుతుంది. ఆ విషయం మీకు నిశ్శబ్దంగా విఫలమైన task ద్వారా మాత్రమే తెలిసే అవకాశం ఉంటుంది.

మూడు నియంత్రణలు, వాటిలో ఉచితమైనది

మొదటి నియంత్రణ tool-schema filter. ప్రతి అభ్యర్థనలో పూర్తి tools array ఉంటుంది. కొన్ని MCP (model context protocol) servers అనుసంధానించిన Claude Code turn లో, ఈ block పరిమాణం సుమారు 29,000 tokens గా ఉంటుంది. ఈ filter user's request మరియు ప్రతి tool description ను 130 MB పరిమాణం గల BAAI/bge-small-en-v1.5 embedding model తో embed చేస్తుంది, సరిపోలే tools ను ఉంచుతుంది, మిగిలిన వాటికి stubs ను ఉంచుతుంది. అప్పుడు ఈ block సుమారు 8,000 tokens కు తగ్గుతుంది. ఆ embedding model CPUపై నడుస్తుంది.

రెండవ నియంత్రణ content compression. దీనికి GPUపై 4B model అవసరం. File reads, tool output మరియు history అసలు పరిమాణంలో 25.7%కి తగ్గేలా మళ్లీ రాయబడతాయి. 74% అనే ప్రధాన సంఖ్య అక్కడి నుంచే వచ్చింది. దీన్ని జాగ్రత్తగా అర్థం చేసుకోవాలి: 74% అనేది compress అయ్యే content పై compression rate మాత్రమే; మీ బిల్లులో తగ్గే శాతం కాదు.

మూడవ నియంత్రణ history summarization. Context budget నిండిన తర్వాత, recent window కు బయట ఉన్న turns ను సంక్షిప్తం చేస్తారు. అందువల్ల దీర్ఘమైన session limit ను తాకకుండా కొనసాగుతుంది.

GPU అవసరమయ్యేది రెండవ నియంత్రణకు మాత్రమే. ఈ పేజీలో అత్యంత ఉపయోగకరమైన వాక్యం ఇదే. pip install "paritok[toolselect]" సాధారణ CPU VPSపై tool filter ను అందిస్తుంది. ఇది నెలకు మీకు ఎలాంటి ఖర్చు లేని product లోని సగం భాగం. GPU card అద్దెకు తీసుకునే ముందు దీన్ని ప్రయత్నించండి.

ప్రాజెక్ట్ ఏమి కొలిచింది, ఎవరి harness పై కొలిచింది

[
  {
    "label": "Paritok-4B-v1",
    "compressed_to_pct": 25.7,
    "quality_retained_pct": 86.5
  },
  {
    "label": "gpt-4.1-mini",
    "compressed_to_pct": 50.2,
    "quality_retained_pct": 85.6
  },
  {
    "label": "gpt-5",
    "compressed_to_pct": 61.9,
    "quality_retained_pct": 93.6
  }
]

ఇవి ప్రాజెక్ట్ స్వయంగా ప్రచురించిన గణాంకాలు. ఇవి SWE-bench Lite పై ప్రాజెక్ట్ స్వంత harness తో కొలిచినవి. Paritok-4B-v1 కంటెంట్‌ను అసలు పరిమాణంలో 25.7% కు కుదిస్తుంది. అదే సమయంలో, కుదించని solve rate లో 86.5% ను నిలుపుకుంటుంది. compressor గా gpt-5 ను ఉపయోగిస్తే నాణ్యత మరింత మెరుగ్గా నిలుస్తుంది: 93.6%. అయితే కంటెంట్‌ను 61.9% కు మాత్రమే కుదిస్తుంది. అంటే frontier ధరలను ఆదా చేయడానికి frontier ధరలనే చెల్లించాల్సి వస్తుంది.

నాణ్యత column ను వాస్తవికంగా చదవాలి. solve rate లో 86.5% నిలిచిందంటే, కుదించని runs పరిష్కరించిన సమస్యల్లో కొన్ని compressed runs విఫలమయ్యాయని అర్థం. అంటే దాదాపు ప్రతి ఏడింటిలో ఒక solve విఫలమవుతుంది. Benchmark లో ఇది table లోని ఒక సంఖ్య మాత్రమే. మీ repository లో మాత్రం మీరు అదే task ను రెండుసార్లు run చేయాల్సి రావచ్చు.

[
  {
    "label": "Turn 1",
    "saved_pct": 25
  },
  {
    "label": "Turn 5",
    "saved_pct": 39
  },
  {
    "label": "Turn 12",
    "saved_pct": 57
  },
  {
    "label": "Turn 20",
    "saved_pct": 63
  }
]

Session కొనసాగుతున్న కొద్దీ end-to-end saving పెరుగుతుంది. దీనికి కారణం history పేరుకుపోవడం, అలాగే compress చేసేది history కావడం. ప్రాజెక్ట్ ప్రకారం, single turn లో saving సుమారు 25%, turn 5 నాటికి 39%, turn 20 నాటికి 63%. ఈ పెరుగుదల ఎక్కడ ఆగుతుందో కూడా ప్రాజెక్ట్ పేర్కొంది. 200,000 token budget పై absolute saving ప్రతి turn కు సుమారు 48,000 tokens వద్ద స్థిరపడుతుంది. ఇది సాధారణంగా turn 8 నుంచి 12 మధ్య జరుగుతుంది. Context పూర్తయిన తర్వాత history పెరగడం ఆగిపోవడమే దీనికి కారణం. విస్తృతంగా ఉటంకించే "past 85%" గణాంకం context-saturated sessions ను సూచిస్తుంది. అది ఉత్తమ పరిస్థితి. అందువల్ల మీ ప్రణాళికను దానిపై ఆధారపరచకండి.

24GB GPU Paritok ఖర్చును భరిస్తుందా?

ఈ పరిమాణంలోని మోడల్‌కు 24 GB కార్డు సాధారణంగా అద్దెకు తీసుకునే యూనిట్. 7 August 2026 నాటికి, 24 GB కలిగిన RTX 4090 కు ప్రచురించబడిన on-demand రేట్ల మధ్యక విలువ గంటకు $0.44. అతి తక్కువ listings సుమారు $0.20 వద్ద ఉన్నాయి. ఇక్కడ $0.44 ను తీసుకుందాం. నెలంతా నడిపితే 730 గంటలు అవుతాయి, అంటే $321. పని గంటల్లో మాత్రమే, రోజుకు 8 గంటలు మరియు 22 రోజులు నడిపితే 176 గంటలు అవుతాయి, అంటే $77.

ఇప్పుడు token తగ్గింపును dollar తగ్గింపుగా మార్చాలి. ఈ తగ్గింపు input tokens కు మాత్రమే వర్తిస్తుంది. Output tokens proxy ద్వారా మార్పు లేకుండా వెళ్తాయి, కాబట్టి వాటిపై ఎలాంటి ప్రభావం ఉండదు. మీ మొత్తం dollar ఖర్చులో input tokens 80% ఉన్నాయని అనుకుందాం. ఇది coding agent కోసం సాధారణ అంచనా. అయినా, మీ స్వంత bill తో ఆ అంచనా సరిపోతుందో తనిఖీ చేయండి. అప్పుడు మీ dollar saving = token reduction × 0.8.

[
  {
    "label": "Turn 5 (39% saved)",
    "bill_always_on_usd": "1,030",
    "bill_workday_only_usd": 248
  },
  {
    "label": "Turn 20 (63% saved)",
    "bill_always_on_usd": 637,
    "bill_workday_only_usd": 154
  },
  {
    "label": "Saturated (85% saved)",
    "bill_always_on_usd": 472,
    "bill_workday_only_usd": 114
  }
]

85% saturated-session గణాంకం వద్ద bill లో 68% ఆదా అవుతుంది. అందువల్ల నెలవారీ agent ఖర్చు సుమారు $472 దాటినప్పుడు, ఎప్పుడూ నడుస్తున్న కార్డు తన ఖర్చును తానే భరిస్తుంది. పని గంటల వెలుపల instance ను ఆపితే ఈ పరిమితి సుమారు $114. turn-20 గణాంకం 63% వద్ద ఇవి వరుసగా $637 మరియు $154 అవుతాయి. చిన్న sessions వాస్తవంగా కనిపించే turn-5 గణాంకం 39% వద్ద, కార్డును అద్దెకు తీసుకోవడం విలువైనదిగా మారే ముందు నెలకు సుమారు $1,030 ఖర్చు చేయాలి.

పట్టిక సూచించే దానికంటే ఇది మెరుగ్గా ఉండటానికి రెండు కారణాలు ఉన్నాయి. మోడల్‌కు 24 GB అవసరం లేదు: q4 build సుమారు 2.5 GB, bf16 build సుమారు 8 GB మాత్రమే. అందువల్ల చిన్న కార్డు లేదా మీరు ఇప్పటికే మరొక పనికి నడుపుతున్న GPU box ఉంటే, chart లోని ప్రతి సంఖ్య తగ్గుతుంది. ఎవరూ coding చేయనప్పుడు instance ను ఆపడం ఇక్కడ అత్యంత ప్రభావవంతమైన చర్య, ఎందుకంటే దాంతో అద్దె ఖర్చు సుమారు మూడు వంతులు తగ్గుతుంది.

ఇది మరింత ఖరీదుగా మారే ఒక కారణం ఉంది. Compression pass కు నిజమైన compute పని అవసరం. 4B model compress చేసే ప్రతి token ను model ముందుగా చదివి, తరువాత రాయాలి. దీనివల్ల ప్రతి agent turn కు latency పెరుగుతుంది. గంటల ప్రాతిపదికన అద్దెకు తీసుకున్న కార్డులో ఈ ఖర్చు invoice లో ప్రత్యేక line గా కాకుండా waiting time గా కనిపిస్తుంది. అందువల్ల మీరు దాన్ని అనుభవించే వరకు దాన్ని గమనించకపోవచ్చు.

సాధారణంగా rented GPU hours మరియు API tokens మధ్య ఎంపిక చేస్తుంటే, GPU VPS మరియు API tokens మధ్య break-even inference ఖర్చుకే ఇదే లెక్కను అమలు చేస్తుంది.

VPS పై Paritok gateway నడపడం

Python 3.10 లేదా అంతకంటే కొత్త వెర్షన్ అవసరం. Ubuntu 24.04లో Python 3.12 ఉంటుంది. కాబట్టి CPU-only భాగానికి సాధారణ VPS image సరిపోతుంది.

sudo apt update && sudo apt install -y python3-venv curl
python3 -m venv /opt/paritok/venv
source /opt/paritok/venv/bin/activate
pip install "paritok[proxy]==1.3.0"
pip install "paritok[toolselect]==1.3.0"

వెర్షన్‌ను pin చేయండి. Repository 29 July 2026న v1.2.8ను, 5 August 2026న v1.3.0ను tag చేసింది. ఇంత వేగంగా మారే projectలో releases మధ్య config keys పేర్లు మారవచ్చు. సాధారణ pip install paritok లేదా main యొక్క git clone ఉపయోగిస్తే, వచ్చే వారం వేరే gateway లభిస్తుంది. మీరు కొలిచిన సంఖ్యలను ఏ వెర్షన్ రూపొందించిందో కూడా రికార్డు ఉండదు.

Default backend Ollama. ముందుగా modelను pull చేసి, తరువాత proxy ఎదురుచూసే short nameను దానికి ఇవ్వండి.

ollama pull paritok/paritok-4b-v1
ollama cp paritok/paritok-4b-v1 paritok-4b-v1

Local model compress చేసే ప్రతి segment కోసం rewrite రాస్తుంది. అందువల్ల compression pass ఎక్కువసేపు నడిస్తే agent turn నిలిచిపోయినట్లు కనిపిస్తుంది. Output lengthను పరిమితం చేసే నియంత్రణ Ollama యొక్క num_predict పరిమితి.

దాని పక్కన paritok.yaml రాయండి. మీ స్వంత hardwareపై compression కొనసాగడానికి use_gpu_server: false అవసరం.

use_gpu_server: false
local_model:
  base_url: http://localhost:11434

paritok proxy --port 8080 --config-file paritok.yaml

పైన పేర్కొన్న వాటన్నింటికీ paritok up shortcutగా పనిచేస్తుంది. Model లేకపోతే అది pull చేస్తుంది, తరువాత port 8080పై proxyను ప్రారంభిస్తుంది. Agentను proxyకి అనుసంధానించే ముందు proxyను తనిఖీ చేయండి.

curl http://127.0.0.1:8080/health
curl http://127.0.0.1:8080/stats

/healthలో "status":"ok" మరియు version string ఉన్న చిన్న JSON object వస్తుంది. /stats compression totalsను, proxy తాను ఎంత ఆదా చేసిందని అంచనా వేసిందో కూడా చూపిస్తుంది. ఆ అంచనాను proxy తన పనికి తానే ఇచ్చుకున్న మూల్యాంకనంగా పరిగణించండి. Provider usage pageలోని సమాచారంతో దాన్ని నిర్ధారించండి.

సౌలభ్యం కంటే throughput ముఖ్యం అయితే, vLLM base modelపై adapterను serve చేస్తుంది.

vllm serve Qwen/Qwen3-4B-Instruct-2507 \
  --enable-lora \
  --lora-modules paritok-4b-v1=paritok/paritok-4b-v1 \
  --port 8000

Ollamaను త్వరగా ఏర్పాటు చేయవచ్చు. Concurrent requestsను vLLM చాలా మెరుగ్గా నిర్వహిస్తుంది. ఒకే boxను ఒకటికంటే ఎక్కువ agentలు పంచుకున్న వెంటనే ఇది ముఖ్యం అవుతుంది. Ollama మరియు vLLM మధ్య ప్రాయోగిక తేడా ఆధారంగా దీనిలో ఏది ఎంచుకోవాలో నిర్ణయించండి.

Base URL environment variablesతో agentను proxyకి పంపండి.

export ANTHROPIC_BASE_URL=http://127.0.0.1:8080
export OPENAI_BASE_URL=http://127.0.0.1:8080

Codex CLI OPENAI_BASE_URLను పట్టించుకోదు. అందువల్ల paritok.yamlలో codex.enabled: true సెట్ చేసినప్పుడు project మీ కోసం ~/.codex/config.tomlను రాస్తుంది. Variableను మాత్రమే export చేస్తే Codex నేరుగా providerతోనే మాట్లాడుతుంది. మీరు పని చేస్తున్నప్పుడు /stats counter ఎప్పుడూ మారకపోవడం దీనికి సంకేతం.

Listenerను 127.0.0.1పై ఉంచండి; 0.0.0.0పై ఎప్పుడూ ఉంచవద్దు. Proxy మీ provider API keyను upstreamకు forward చేస్తుంది. కాబట్టి internet నుంచి చేరుకోగల proxy ఆ keyకు open relayగా మారుతుంది. Portను కనుగొన్న ఎవరైనా keyను చూడకుండానే మీ డబ్బును ఖర్చు చేయగలరు. Portను తెరవడం బదులుగా SSH tunnel లేదా VPN ద్వారా laptop నుంచి proxyని చేరుకోండి.

Reboot తర్వాత కూడా కొనసాగేందుకు దీన్ని systemd కింద నడపండి. మీ installకు సరిపోయేలా pathsను మార్చండి.

[Unit]
Description=Paritok compression proxy
After=network-online.target

[Service]
User=paritok
WorkingDirectory=/opt/paritok
ExecStart=/opt/paritok/venv/bin/paritok proxy --port 8080 --config-file /opt/paritok/paritok.yaml
Restart=on-failure

[Install]
WantedBy=multi-user.target

sudo systemctl enable --now paritokతో దీన్ని enable చేసి, తరువాత మళ్లీ /healthను curl చేయండి. ప్రారంభమైన వెంటనే exit అయ్యే unit సాధారణంగా config file path తప్పుగా ఉందని సూచిస్తుంది. కారణాన్ని journalctl -u paritok -n 50 చూపిస్తుంది.

హోస్ట్ చేసిన ఎంపిక, దానికి మీరు చెల్లించేది

ఈ ప్రాజెక్ట్ compression ను ఒక service గా కూడా అందిస్తుంది. API key తో use_gpu_server: true ను సెట్ చేస్తే, 4B model ఆ సంస్థ hardware పై నడుస్తుంది. ప్రాసెస్ చేసిన ప్రతి మిలియన్ tokens కు $0.30 ధర ఉంటుంది. అయితే, సంస్థ documentation ప్రకారం, ఈ సేవ August 2026 ముగిసే వరకు ఉచితం. దీనివల్ల GPU rent మరియు పై operations పనులన్నీ తొలగిపోతాయి.

అయితే, మీ prompts మరియు agent చదివే files మీ machine నుంచి బయటకు వెళ్లి, model provider కు చేరే ముందు third party వద్దకు చేరతాయి. ఈ hop ను నివారించడానికే self-hosting ఉపయోగిస్తారు. ఆ flag ను సెట్ చేసే ముందు, ఈ రెండింటిలో మీరు దేనికి ప్రాధాన్యత ఇస్తున్నారో నిర్ణయించండి. ఎందుకంటే flag ను ఒకే line లో మార్చవచ్చు, కానీ దాని ప్రభావం అంత సులభంగా మారదు.

మీ స్వంత before-and-after ఫలితాలను ఎలా కొలవాలి

ప్రచురించిన సంఖ్యలు project యొక్క సంఖ్యలు. అవి project యొక్క harness ను ఉపయోగించి SWE-bench Lite పై పొందినవి. మీ repository SWE-bench Lite కాదు. మీ స్వంత కొలతలు తీసుకోండి.

• proxy లేకుండా, సాధారణ పనులతో ఒక పూర్తి వారం అమలు చేయండి. మీ provider యొక్క usage page నుంచి input tokens, cache-read tokens, output tokens ను వేర్వేరు పంక్తులుగా నమోదు చేయండి. వాటిని ఒకే dollar total గా నమోదు చేయవద్దు.
• తరువాతి వారం proxy ను ముందుంచి, అదే రకమైన పనిని చేయండి.
• input మరియు cache-read పంక్తులను పోల్చండి. output సాధారణంగా స్థిరంగా ఉండాలి, ఎందుకంటే దాన్ని ఏదీ compress చేయదు. outputలో పెద్ద మార్పు ఉంటే proxy కాకుండా మరేదైనా మారి ఉంటుంది.
• మళ్లీ చేయాల్సి వచ్చిన tasks సంఖ్యను లెక్కించండి. ఇది trade-off లోని quality భాగం. ఏ dashboard కూడా దీన్ని నివేదించదు.
• totals ను పోల్చే ముందు week two కు సంబంధించిన GPU hours ను కూడా కలపండి.

input ను output నుంచి వేరు చేయడం ముఖ్యం. ఎందుకంటే వీటి ధరలు చాలా భిన్నంగా ఉంటాయి, అలాగే compressor వీటిలో ఒక్కదానినే ప్రభావితం చేస్తుంది. August 2026 నాటికి, Claude Sonnet 4.6 ధర 1 million input tokens కు $3, 1 million output tokens కు $15. prompt-cache read ధర input rate లో 10%, అంటే 1 million కు $0.30. input మరియు output token ఖర్చుల మధ్య వ్యత్యాసం వల్ల input-side compressor మీకు ఉపయోగకరమా కాదా అనేది నిర్ణయించబడుతుంది. Claude Code tokens వాస్తవంగా ఎక్కడ ఉపయోగించబడతాయి అనే విషయం మీ context లో ఏ భాగం compress చేయడానికి సరిపడా పెద్దదో తెలియజేస్తుంది.

Prompt caching tool-filter లెక్కలను ప్రత్యేకంగా క్లిష్టం చేస్తుంది. tool block request ప్రారంభంలో ఉంటుంది. అందువల్ల మొదటి turn తర్వాత అది సాధారణంగా input ధరలో 10%కి cache hit అవుతుంది. Cached block నుంచి 21,000 tokens తగ్గిస్తే, uncached rate సూచించే $0.063కు బదులుగా, ఒక్కో turn కు 21,000 tokens × $0.30 per million, అంటే సుమారు $0.006 మాత్రమే ఆదా అవుతుంది. Cached prefix మారకుండా ఉండేందుకు project session మొత్తం filtered block ను స్థిరంగా ఉంచుతుంది. ప్రతి turnలో tools ను మళ్లీ ఎంచుకునే filter ఆ prefix ను invalidate చేస్తుంది. దాంతో ఆదా చేసిన దానికంటే ఎక్కువ ఖర్చవుతుంది.

ఇంకా ఏవి ధృవీకరించబడలేదు

పైన పేర్కొన్న ప్రతి పనితీరు సంఖ్యా ప్రాజెక్ట్ నుంచే వచ్చింది. SWE-bench Lite ఫలితాలను స్వతంత్రంగా పునరుత్పత్తి చేసిన ఆధారం లేదు. మొదటి tags July 2026 తేదీతో ఉండటంతో, ఈ code వెనుక ఉన్న operational history కూడా చాలా పరిమితంగా ఉంది. Compression rate మరియు quality-retained figure రెండింటినీ, అవి మెరుగ్గా కనిపిస్తే ప్రయోజనం పొందే పక్షమే కొలిచింది. అందువల్ల అవి తప్పు అని కాదు. అవి ఇంకా ధృవీకరించబడలేదని అర్థం. మీరు స్వయంగా రూపొందించిన సంఖ్యతో పోలిస్తే వాటికి వేరే స్థాయి నమ్మకాన్ని ఇవ్వాలి.

మీ setup ను నిందించే ముందు తెలుసుకోవాల్సిన ఒక documented behaviour ఉంది. ఈ tool ఉపయోగించే filter యొక్క embedding model startup సమయంలో కాకుండా మొదటి request వచ్చినప్పుడు load అవుతుంది. అందుకే project 10 to 15 seconds warm-up సమయాన్ని document చేస్తోంది. ఆ తర్వాత ప్రతి call కు సుమారు 15 ms పడుతుంది. Proxy ప్రారంభమైన తర్వాత ఒక throwaway request పంపండి. అప్పుడు agent యొక్క మొదటి నిజమైన turn ఆగిపోయినట్లు కనిపించదు.

ఒక మధ్యాహ్నంలో మీరు స్వయంగా నిర్ధారించగల నాలుగు విషయాలు ఇవి: proxy ప్రారంభమై నిరంతరం నడుస్తుందా, మీరు పని చేస్తున్నప్పుడు /stats మారుతుందా, మీ provider యొక్క input-token line నిజంగా తగ్గుతుందా, agent ఇప్పటికీ పనిని పూర్తి చేస్తుందా. మీ setup కోసం ఇవే ఏ published benchmark కంటే మెరుగైన నిర్ణయాధారాలు.

ఇది మీ ఇతర tooling పక్కన ఎక్కడ సరిపోతుందో చూస్తే: self-hosted LiteLLM gateway request లను వాటి contents మార్చకుండా route చేసి meter చేస్తుంది. అందువల్ల ఈ రెండూ వేర్వేరు సమస్యలను పరిష్కరిస్తాయి. వీటిని chain చేయవచ్చు; అందులో Paritok agent కు అత్యంత సమీపంలో ఉంటుంది. ఈ నిర్దిష్ట tool కంటే bill తగ్గించడమే అసలు లక్ష్యం అయితే, VPSపై agent కోసం అందుబాటులో ఉన్న విస్తృత cost controls జాబితాలో ముందుగా ఉచితంగా ప్రయత్నించగల అనేక మార్పులు ఉన్నాయి.

FAQ

Paritok నా API బిల్లును తగ్గిస్తుందా, లేక నా context usage ను మాత్రమే తగ్గిస్తుందా?

ఇది బిల్లును తగ్గిస్తుంది, ఎందుకంటే proxy అభ్యర్థన provider కు చేరే ముందు దాన్ని తిరిగి రాస్తుంది, అలాగే provider తనకు అందినదానికి ఛార్జ్ చేస్తుంది. అయితే ఈ తగ్గింపు శీర్షిక సూచించినంత పెద్దది కాదు. 74% సంఖ్య compressed చేస్తున్న content పై compression rate ను సూచిస్తుంది. End to end గా, project ఒకే turn లో సుమారు 25% మరియు turn 20 నాటికి 63% తగ్గింపును నివేదిస్తుంది; మారేది input tokens మాత్రమే. Output tokens ఎలాంటి మార్పు లేకుండా pass through అవుతాయి.

compression model ను self-host చేయడానికి నాకు ఎంత GPU అవసరం?

q4 build పరిమాణం సుమారు 2.5 GB, bf16 build పరిమాణం సుమారు 8 GB. అందువల్ల model 24 GB card లో చాలా ఖాళీతో సరిపోతుంది. చిన్న card కూడా పనిచేస్తుంది. అంతేకాక, అది break-even లెక్కలను మీకు అనుకూలంగా మారుస్తుంది. Tool-schema filter కు GPU అసలు అవసరం లేదు. ఇది CPUపై నడిచే 130 MB embedding model అయిన BAAI/bge-small-en-v1.5 ను ఉపయోగిస్తుంది. సాధారణ VPSలో paritok[toolselect] install చేస్తే, కొద్దిపాటి RAM ఖర్చుతో tool-block reduction లభిస్తుంది.

agent కు అవసరమైనదాన్ని compressor తొలగిస్తే ఏమవుతుంది?

ఏదీ తొలగించబడదు. Compressed segments లో [REF:id] tag ఉంటుంది. Model read_original లేదా expand_context తో పూర్తి text ను తిరిగి పొందుతుంది. Filter చేసిన tool schemas తొలగించకుండా stubs గా ఉంచబడతాయి. Model gateway_search_tools తో వాటిలో ఒకదాన్ని తిరిగి పొందుతుంది. అసలు ప్రమాదం missing file కంటే నిశ్శబ్దంగా ఉంటుంది: model lossy summary ఆధారంగా పనిచేస్తుంది, original కోసం అడగాల్సిన అవసరం ఉందని ఎప్పటికీ గుర్తించకపోవచ్చు. SWE-bench Lite లోని 86.5% quality-retained సంఖ్య కొలిచేది ఇదే.

నా మొదటి request కు పదిహేను సెకన్లు ఎందుకు పడుతున్నాయి?

Tool filter వెనుక ఉన్న embedding model startup సమయంలో కాకుండా మొదటి request వచ్చినప్పుడు load అవుతుంది. Project 10 నుండి 15 సెకన్ల warm-up సమయాన్ని document చేస్తుంది. ఆ తరువాత ప్రతి call కు సుమారు 15 ms పడుతుంది. Proxy ప్రారంభించిన తర్వాత curl తో ఒక throwaway request పంపండి. అప్పుడు మొదటి నిజమైన agent turn ఆగిపోదు.

self-hosting కు బదులుగా hosted GPU server ఉపయోగించాలా?

ఇది GPU rent మరియు maintenance బాధ్యతను తొలగిస్తుంది. August 2026 నాటికి processed చేసిన ప్రతి million tokens కు $0.30 ధర ఉంటుంది. అయితే మీ model provider కు చేరే ముందు మీ prompts మరియు agent చదివే files ను ఇది third party కు పంపుతుంది. మీరు నియంత్రించే infrastructure లో code ను ఉంచడానికి self-hosting చేస్తున్నట్లయితే, ఆ setting మీరు ప్రారంభించిన కారణాన్నే తొలగిస్తుంది. Self-hosting ద్వారా context మరియు provider API key రెండూ మీ స్వంత box లోనే ఉంటాయి.