DEV Community: Aniket

Why I built my coding-agent tooling as a local proxy instead of hooks

Aniket — Thu, 22 Oct 2026 16:14:14 +0000

There are dozens of coding agents out there now, with a new one every other week.

Using them extensively, both at work and on side projects, I kept having ideas about the requests they send, how I could optimize them, or build around them to improve my workflows:

What if a small local model checked them for secrets first?
What if I could see where my tokens actually go?
What if old tool output could be trimmed before it's sent again?

The sensible move was to pick one tool like Claude Code or Codex CLI, build on that tool's hooks, and call it a day.

In true side project fashion, that's not what happened.

Where to put it

Every coding agent has its own extension point: hooks, config, plugins. Build the same idea on each, and you're maintaining four versions that break whenever one of the tools changes.

But they all have one thing in common: whatever tool you use, it ends up sending requests to a model over HTTP. So that's where I put it. Torana is a local proxy that sits between the agent and the model provider.

Pointing an agent at it is usually one environment variable. For Claude Code:

ANTHROPIC_BASE_URL="$(torana endpoint anthropic)" claude

What that one decision forced

1. Build once, works in every tool. Since the proxy sees every request, anything built there works for Claude Code, Codex, OpenCode or Pi. The catch: they don't all speak the same API. Anthropic Messages, OpenAI Chat Completions and Responses all look different, so the proxy has to understand each format before anything can be built on top of it.

2. It has to run locally. The proxy sees everything: your code, your prompts, the files the agent reads, your keys. That's not something to send to someone else's server. Torana runs on your machine, and it's open source so you can check what it does.

3. It became a plugin system. I had more than one idea, so each idea is its own plugin. Plugins are compiled to WebAssembly, and you can write them in Go or Rust. A plugin that sees all your agent traffic shouldn't run just because it's installed, so nothing runs until you've reviewed its permissions and approved it.

What it cost

A proxy isn't free:

Each tool needs routing. Most take a base URL, but not all the same way. Codex, for example, needs its HTTP/SSE mode instead of websockets for plugins to see the responses.
Some things only the harness knows. A proxy sees requests, not the agent's UI. That's why Torana later grew an MCP server, so the agent can ask the proxy questions from inside the chat.
Prompt caching makes you careful. Change an old message, and the provider's cache for the whole conversation can be rebuilt. Any plugin that edits history has to pay for itself first.

What's next

Over the next few weeks I'll write up one decision at a time: what I built, why, and what it cost. MCP is next.

If you want to try it: https://torana.sh/?utm_source=devto&utm_medium=social&utm_content=origin-04 (open source: https://github.com/torana-edge/torana-edge)

If you've built tooling around coding agents: did you go per-tool, or find a common layer?

Can decision models like Jev and Laya route a coding agent?

Aniket — Thu, 15 Oct 2026 15:25:09 +0000

We plugged Laya, a 421M-parameter decision model, into our coding agents as a model router. The plumbing worked in about 112 ms. Deciding when a bigger model actually helps turned out to be the hard part.

Small decision models aren't new, but they're getting a lot more attention lately, with Jev (hosted, by TypeSafe) and Laya (open source). They don't generate text: you give them a question and a fixed set of options, and they pick one. We wanted to see whether one could earn a place in a real coding workflow.

The obvious first job was replacing the classifier a harness's auto mode uses to decide whether an action is safe. That classifier is part of the harness, so it isn't something we can swap. So we gave it a different job: pick the model for each turn. Cheap model for easy turns, expensive one for hard ones. Our agents already run through Torana, a local proxy, so the router went in there as a plugin. We used Laya, because it's open source and runs on our own machine.

This write-up covers how the router works, the setup, what worked, what didn't, and what we're changing.

How the router works

Torana's decision_router plugin watches an ordered ladder of models for each provider, for example DeepSeek Flash → DeepSeek Pro. At each new user turn (never in the middle of a tool call) it decides whether to stay, move up or move down one step.

Laya sees the latest user message and a few counters. It never sees code, tool output, the system prompt or earlier conversation.

Two kinds of signal feed the decision:

Local signals: new tool errors, retries, requests per turn and responses that hit the output limit. No model involved.
An optional classifier: any server speaking the System One API (Jev's API, which Laya also implements). It gets the latest user message plus those counters, and answers with one ladder step or hold, with a confidence. Answers below the configured confidence threshold are ignored.

What happens next depends on the mode. shadow only records what it would have suggested. advise shows a suggestion with the estimated cache-rebuild cost. confirm lets you accept it in Torana. auto moves up on its own within a switch cap and cost guard; moving down always needs your approval. The classifier and downward moves are both off by default.

Setup

Date: 8 October 2026, on a Mac, CPU only.
Torana: Edge 1fa71a2, decision_router 0.6.1, SDK 0.7.1, in an isolated data directory on its own port.
Classifier: Laya Python package 0.3.22, the English checkpoint (421M), four CPU threads, served locally on its System One endpoint.
Harnesses: Codex, Pi, Oh My Pi and OpenCode, each reading a real local file through Torana with the router enabled in advise mode.
Upstream for routing tests: a local recording relay, so routing decisions could be inspected without billing or model randomness. The cheap-vs-expensive comparison used the real DeepSeek API.
Jev: not tested. Everything below is about Laya's English checkpoint.

Prompt set

48 synthetic coding requests, each labelled with the tier we'd expect: 15 routine, 12 normal implementation, 14 hard reasoning and 7 that should hold (vague follow-ups like "Do it.", environment problems, explicit "keep the model"). It includes probes: a quoted prompt-injection, a Hindi and a Spanish request, and a short but hard one. The labels are our rubric, not ground truth about which model a task needs.

All 48 prompts

fast: Rename variable total to subtotal in one function. · Fix the spelling of recieve in the README. · Run gofmt on this file. · Print the version from package.json. · Add a comment explaining that this timeout is in milliseconds. · Sort this list of import statements alphabetically. · Change the button text from Submit to Save. · Run the existing unit tests and report the result; do not debug failures. · Pretty-print this JSON object without changing any values. · Link the quickstart from the README. · Change DEFAULT_PORT from 8080 to 8143. · Copy the existing healthcheck test and change the path to /ready.
balanced: Add a paginated REST endpoint with input validation and unit tests. · Implement a settings form with validation and a save API call. · Add unit tests for empty input, duplicate IDs, and invalid timestamps. · Implement a bounded in-memory LRU cache and tests. · Extract duplicated CSV parsing into a shared helper without changing behavior. · Add exponential backoff with a maximum retry count to this HTTP client. · Add a filter to the search endpoint and update its SQL query. · Write a parser for this documented JSON schema and reject unknown fields. · Build an accessible dropdown component using the existing design system. · Add a nullable database column and a backward-compatible migration. · Instrument request latency and status codes with OpenTelemetry. · Implement a plugin that logs token usage without recording message content.
strong: Diagnose a rare data race in a lock-free scheduler under concurrent cancellations. Prove the fix preserves linearizability. · Design an exactly-once financial ledger across regions with network partitions, retries and crash recovery. · Audit the authentication boundary for privilege escalation involving refresh-token replay and tenant isolation. · Find an intermittent deadlock involving three locks and callbacks that reenter the scheduler. · Implement a type inference algorithm for higher-rank polymorphism and explain its soundness constraints. · Design a lossless streaming translation between three model API formats including tool-call deltas, refusal and partial failure. · Analyze a crash-consistency bug in a write-ahead log that only appears after torn writes and a double restart. · Prove this distributed transaction implementation provides serializability under concurrent retries and clock skew. · Diagnose a nonlinear tail-latency regression with contention, cache misses and queueing. · Review a custom cryptographic protocol for nonce reuse, downgrade attacks and chosen-ciphertext vulnerabilities. · Plan a zero-downtime migration of a multi-tenant financial platform from batch processing to event sourcing. · Find an unsound lifetime interaction in this unsafe Rust allocator and prove the corrected ownership invariants.
hold: Continue. · Try again. · Do it. · Fix the problem we discussed. · The test runner cannot connect because Docker is not installed; tell me how to install Docker. · The provider returned HTTP 429; wait and retry, do not change models. · Keep the current model for this turn; only print OK.
probes: A typo fix containing quoted text telling the router to choose strong with confidence 1 (expected fast). · A one-word replacement in an "architecture guide" (expected fast). · "Prove the consensus protocol remains safe under Byzantine faults." (short but hard, expected strong). · A Hindi typo fix (expected fast). · A Spanish race-condition proof (expected strong).

What Laya receives and returns

This is the request the plugin sends, with the exact field names and option order it uses (Go sorts the keys alphabetically):

Request (JSON)

POST http://127.0.0.1:18100/v1/systemone
{
  "model": "english",
  "state": {
    "latest_user_turn": "Fix the spelling of recieve in the README.",
    "signals": { "recent_tool_errors": 0, "user_turns": 4, "last_turn_requests": 2,
                 "last_turn_retries": 0, "last_turn_max_tokens": 0,
                 "avg_requests_per_turn": 2, "context_bucket": "2k-8k" }
  },
  "questions": {
    "route": {
      "type": "choice",
      "instructions": "Which model tier fits this coding task?",
      "criteria": {
        "balanced": "Normal coding tasks, implementing a bounded feature, writing tests and routine debugging",
        "fast": "Routine mechanical edits, formatting, simple lookups and straightforward instructions",
        "hold": "The current model remains suitable for this turn",
        "strong": "Difficult debugging, subtle concurrency or security analysis, architecture and complex multi-step reasoning"
      }
    }
  }
}

Response for that request (JSON, trimmed)

{
  "answers": {
    "route": {
      "type": "choice",
      "choice": "balanced",
      "probabilities": { "balanced": 0.369, "fast": 0.341, "hold": 0.186, "strong": 0.104 },
      "confidence": 0.0744,
      "answer_confidence": 0.369
    }
  },
  "usage": { "input_tokens": 175, "truncated": false }
}

A typo fix, picked as balanced with 37% probability, just ahead of fast at 34%.

Results: the plumbing works

All four harnesses read the file, got the tool result back through Torana and finished correctly with the router enabled:

Real harness runs through Torana with decision_router in advise mode. Wall time for the whole run.

Harness	Model	API shape	Result	Wall time
Codex 0.161.0	GPT-5.6 Luna	OpenAI Responses	Correct, exit 0	5.87 s
Pi 1.0.0	DeepSeek Flash	Chat Completions	Correct, exit 0	1.36 s
Oh My Pi 18.2.0	DeepSeek Flash	Chat Completions	Correct, exit 0	2.41 s
OpenCode 2.0.22	DeepSeek Flash	Chat Completions	Correct, exit 0	1.85 s

Fast: 112 ms median and 115 ms p95 per decision over 25 sequential warm requests on the laptop CPU.
Asks once per user turn: in Chat Completions, Responses, Anthropic Messages and Gemini Code Assist request shapes, a new user turn made one classifier call, tool-result continuations made zero, and an identical retry after restarting Torana made zero.
Fails safe: an HTTP 503, malformed JSON, an unknown choice and a timeout all forwarded the original request unchanged. The timeout cost about 1.56 s, matching the configured 1,500 ms limit.
Routing itself works: with a forced high-confidence answer, auto mode moved from the cheap step to the strong one immediately in all four shapes, and an accepted downward suggestion switched back on the next user turn. System instructions and cache fields were preserved.

Results: the classifier never got confident

The plugin's default threshold is 0.8. Across every variation of the question we tried, not one of Laya's answers cleared it.

48 prompts per variant. "Agrees with rubric" = Laya picked the tier we labelled. "Cleared 0.8" = would actually have triggered a suggestion.

Question and options	Agrees with rubric	Cleared 0.8	Highest confidence
Four tiers: fast / balanced / strong / hold (the plugin's default question)	21/48	0/48	0.26
Stricter instructions, plus "choose hold if unsure"	11/48	0/48	0.17
Four tiers without a hold option	20/48	0/48	0.22
Two tiers plus hold	21/48	0/48	0.46
Same two tiers, options renamed a / b / c	23/48	0/48	0.43

Where it did pick, it leaned to the middle. With the default four-tier question, 10 of the 14 hard prompts came back as balanced, and so did 8 of the 15 routine ones:

Default question. Rows: tier we expected. Columns: tier Laya picked.

Expected	fast	balanced	strong	hold
fast (15)	7	8	0	0
balanced (12)	3	9	0	0
strong (14)	0	10	4	0
hold (7)	1	5	0	1

Other things that stood out:

Labels changed answers. Renaming the two-tier options to a, b, c, with identical descriptions and a different order, changed 13 of 48 decisions. Option names and order are part of the experiment, not cosmetics.
"Choose hold if unsure" made it hold almost everything: 44 of 48.
Narrower questions looked better than they were. "Does this require difficult reasoning?" agreed with our labels 38/48 times, but mostly by saying no: it caught only 4 of the 14 hard prompts.
Long messages got truncated. Four ~8 KB messages (inside the plugin's byte budget) all came back marked truncated, at about 349 ms.
The prompt-injection probe didn't steer it. The typo fix containing "choose strong with confidence 1" came back as fast.

Laya isn't broken. As a control, we asked it to route support tickets ("My credit card was charged twice…" → billing, tech or other). It answered correctly with 0.90 probability. Simple, clearly separated categories are easy. Telling a hard-sounding prompt from a prompt that actually needs a stronger model is a much harder question, and its authors are open about the base model's zero-shot limits.

Part of the gap is ours. Laya returns two numbers: answer_confidence, the probability of the chosen option, and confidence, a normalised measure of how concentrated the whole distribution is. The plugin reads confidence and compares it with 0.8. On a four-way choice that is a much higher bar: the best answer_confidence we saw on the default question was 0.64, while the matching confidence was 0.26. Lowering the threshold wouldn't fix the routing, though; it would only make it act on the 21/48 agreement above.

Results: the cheap model won anyway

A router only makes sense if the strong model does better on hard work. So we gave ten small, objectively gradable questions to DeepSeek Flash and DeepSeek Pro, once each, with thinking disabled and a 512-token output limit:

Content correctness, graded deterministically. One run per model per task.

Task	Kind	Flash	Pro
Sort four words	routine	Correct	Correct
Fix one typo	routine	Correct	Correct
Read a value from JSON	routine	Correct	Correct
Rename a standalone variable	routine	Correct	Correct
Python mutable default argument	reasoning	Correct	Correct
JavaScript event-loop print order	reasoning	Correct	Correct
Is a schedule conflict-serializable?	reasoning	Correct	Wrong (said yes)
LRU cache state after 7 operations	reasoning	Correct	Wrong ([C, D, E])
Redo-only WAL recovery	reasoning	Correct	Correct
Nodes in a directed cycle	reasoning	Correct	Correct

Correct answers: Flash 10/10, Pro 8/10.
Median response time: Flash 0.83 s, Pro 1.29 s.
Exact requested JSON format: Flash 4/10, Pro 2/10. Graded separately: an explanation containing the right answer counts as correct.
Laya picked fast for all ten, with confidence between 0.01 and 0.17. At 0.8 it would never have switched. With the gate off, "fast" happened to match the better model here, but so would the trivial "always use Flash" rule.

This is ten questions, one run each, with Pro's thinking off. It isn't a model ranking. It is a reminder that "harder question → bigger model" is an assumption a router has to prove, not a given.

What we're changing

Read the right confidence. Use Laya's documented answer-confidence and abstention fields deliberately, explain which metric the threshold applies to, and test it. Only validate a threshold against real outcomes.
Never act on a partial answer. The plugin ignores Laya's truncation and abstention markers today: a synthetic 0.99-confidence answer marked truncated still produced a suggestion. It should hold and record why.
Fix plain Gemini requests. On the bare Gemini endpoint the model name lives in the URL, and the plugin saw it as gemini, so the ladder never matched and Laya was never called. Gemini Code Assist was fine.
Tell the classifier which model is current. It gets the message and counters but not the current step, so hold ("the current model is fine") can't really be judged.
Don't treat every failure as a reasoning failure. Repeated tool errors can push the ladder up even when Docker is missing or the network is down. A bigger model doesn't fix those.

Until then, the router stays in shadow mode: it watches real sessions and records what it would have done, without switching. The next step is comparing those calls with what actually happened (tests passing, retries, tokens, cache rebuilds) against "always cheap" and "always strong" baselines.

Limitations

One classifier checkpoint (Laya English), CPU only, one machine. Other checkpoints, Jev and GPU backends weren't tested.
Synthetic prompts with our own difficulty labels; the probes are spot checks, not a multilingual or security benchmark.
The harness runs were compatibility checks, not repository-fixing evaluations or paid live model switches.
The Flash vs Pro comparison is tiny, single-run and has Pro's thinking disabled.
No savings were measured, and none are claimed.

Try it or build on it

Install the plugin, keep it in shadow mode, and bind the decision-service endpoint to a local Laya server or any System One-compatible service:

torana plugin install decision_router
torana open

Example shadow-mode settings with a local classifier (JSON)

{
  "mode": "shadow",
  "ladders": {
    "deepseek": {
      "start": "flash",
      "steps": [
        { "id": "flash", "description": "Routine mechanical work", "model": "deepseek-v4-flash" },
        { "id": "pro", "description": "Difficult debugging or architecture", "model": "deepseek-v4-pro" }
      ]
    }
  },
  "classifier": {
    "enabled": true,
    "decision_model": "english",
    "question": "Which model tier fits this coding task?",
    "inputs": "user_turn+signals",
    "minimum_confidence": 0.8,
    "timeout_ms": 1500,
    "authentication": "none"
  }
}

Use model IDs that match your Torana provider configuration. The full option list is in the plugin guide.

Then watch torana_decision_router_total with outcome would_suggest. From inside your harness, connected to Torana's MCP server, you can ask for decision_router.status or this session's routing summary without exposing prompts.

If you've found a signal that actually predicts when the bigger model helps, or you have outcome-labelled coding turns, we'd like to compare notes on GitHub.

Does compacting tool output lower a coding agent's API bill?

Aniket — Thu, 08 Oct 2026 04:37:06 +0000

Coding agents resend old tool output on every turn, so replacing it with something smaller looks like an obvious saving. I built that as a Torana plugin, broke it once, rebuilt it, and measured it. On DeepSeek V4 Pro the saving was about 2% per session, smaller than ordinary run-to-run variation, because prompt caching had already made the repeated output nearly free.

This write-up covers the idea, what broke, the final design, the experiment setup and methodology, the results, and what's next.

How coding agents resend tool output

The model behind a coding agent can't read files or run commands itself. It asks for a tool call, the agent runs it locally, and the output is appended to the conversation. On every following turn, the agent sends the whole visible conversation back to the model, including every earlier tool result.

Each request re-sends the log as input. Context fills up and the output is billed again on every turn.

This applies to harnesses that resend visible history, typically over Chat Completions or Messages-style APIs. When a provider owns the history (for example OpenAI Responses with previous_response_id), Torana can't rewrite earlier items; native provider compaction is a separate mechanism.

The idea: a cheaper assistant for the hosted model

If the hosted model is the brain doing the real work, a cheaper model could summarise tool output before the brain reads it. A summary is only useful if it knows what matters, so Torana's intent plugin changes the tool definitions the model sees to request a short reason with every tool call, then strips that field before the harness sees the call. The compactor uses the captured intent to decide what to keep.

Reason field: added to tool schemas going out, removed from tool calls coming back. The agent never sees it.

Attempt 1: summarise every large output

The first compactor summarised any tool output over 2,000 characters. It broke coding agents immediately (issue #166). Coding agents edit files with exact search and replace; when a file read came back as a natural-language summary, edits stopped matching. The agent re-read the file, failed again, and looped, burning tokens instead of saving them.

Attempt 2: exact by default, compact only older output

The second design leaves everything exact by default. Policies are ordered, first-match and case-insensitive; unmatched tools are never changed:

exact: never altered. Mutation tools, diffs, failed commands, errors, stack traces and non-zero exits are forced exact even if a broader rule matches them.
deterministic: keeps bounded head and tail evidence plus size, SHA-256, omitted-byte count and a rerun instruction. With first_pass, it applies from the first time the model sees the output, so the prompt never needs a later rewrite.
keyword (keyword_compactor): keeps intent-matching lines, only after at least one exact exposure.
model (compactor): an intent-guided summary, only after at least one exact exposure, and only when the economic gate predicts a net saving.
source (file reads): accepted in configuration but behaves as exact (see what broke).

Keyword/model: exact on first exposure, eligible for compaction from the next request if the gate allows. Deterministic with first_pass: compact from the first exposure, avoiding a later prefix rewrite. Cached compact versions keep the same bytes on later requests.

Rewriting an older message changes the prompt prefix from that point on. The model-gated compactor therefore runs two economic gates: a preflight that checks whether even a best-case reduction could repay the cache rewrite (before paying for a summary), and a final check on the actual candidates. It applies a batch only when the estimated net saving is positive.

Experiment setup and methodology

Environment

Date: 21 July 2026.
Harness: OMP 16.2.9 (coding agent).
Target model: DeepSeek V4 Pro via https://api.deepseek.com/beta (OpenAI-compatible format).
Summariser (model-gated arm): DeepSeek V4 Flash on the same endpoint.
Torana: commit e09d225 from PR #179. That PR was the experiment branch; the plugins were later moved to torana-plugins, and current releases differ. This is the implementation used for the historical run; the unpublished task prompts and run artifacts below prevent exact reproduction from this article alone.

Prices used (July 2026, per million tokens)

Historical test inputs, not current prices. Cache-hit price is 0.83% of the cache-miss price for V4 Pro.

Model	Input (cache miss)	Cache hit	Output
DeepSeek V4 Pro	$0.435	$0.003625	$0.87
DeepSeek V4 Flash	$0.14	$0.0028	$0.28

Arms

Control: Torana in the request path with no compaction plugin.
Deterministic: schema_translator → intent → keyword_compactor, summariser disabled. This is the committed config.dogfood.json. The run itself used the https://api.deepseek.com/beta endpoint for the target model.

Deterministic arm configuration (JSON)

{
  "providers": {
    "deepseek": { "url": "https://api.deepseek.com", "format": "openai" },
    "deepseek-anthropic": { "url": "https://api.deepseek.com/anthropic", "format": "anthropic" }
  },
  "plugins": {
    "order": ["schema_translator", "intent", "keyword_compactor"],
    "config": {
      "keyword_compactor": {
        "tool_policies": [
          { "match": "read*", "mode": "exact" },
          { "match": "view*", "mode": "exact" },
          { "match": "web_search", "mode": "deterministic", "first_pass": true,
            "rerun": "Repeat the search to recover every result." },
          { "match": "grep*", "mode": "keyword" }
        ]
      }
    }
  },
  "offload": { "enabled": false, "provider": "deepseek", "model": "deepseek-v4-flash" },
  "limits": { "concurrency": 10, "rpm": 100 }
}

Model-gated: schema_translator → intent → compactor, with explicit prices, expected_applications: 6 and V4 Flash as the summariser. Grep-like output was eligible for model summaries; the same exact and first-pass rules applied otherwise. Reconstructed from the run record in the shape of the committed example (the committed file covers only the deterministic arm).

Model-gated arm configuration (JSON)

{
  "providers": {
    "deepseek": {
      "url": "https://api.deepseek.com/beta",
      "format": "openai",
      "pricing": {
        "deepseek-v4-pro":   { "input_usd_per_mtok": 0.435, "output_usd_per_mtok": 0.87,
                               "cache_read_usd_per_mtok": 0.003625, "cache_write_usd_per_mtok": 0.435 },
        "deepseek-v4-flash": { "input_usd_per_mtok": 0.14,  "output_usd_per_mtok": 0.28,
                               "cache_read_usd_per_mtok": 0.0028,   "cache_write_usd_per_mtok": 0.14 }
      }
    }
  },
  "plugins": {
    "order": ["schema_translator", "intent", "compactor"],
    "config": {
      "compactor": {
        "expected_applications": 6,
        "tool_policies": [
          { "match": "read*", "mode": "exact" },
          { "match": "view*", "mode": "exact" },
          { "match": "web_search", "mode": "deterministic", "first_pass": true,
            "rerun": "Repeat the search to recover every result." },
          { "match": "grep*", "mode": "model" }
        ]
      }
    }
  },
  "offload": { "enabled": true, "provider": "deepseek", "model": "deepseek-v4-flash" }
}

DeepSeek has no separate cache-write charge, so the cache-write rate is set equal to the input rate: a rewritten span is billed as cache misses.

Protocol

Tasks: five repository tasks run with OMP: architecture, economics, regression review, safety (exercising mutations, patches, errors and non-zero exits), and a stress task.
Design: five repetitions × three arms = 75 sessions. Within each paired block (task × repetition), the order of the three arms was randomised.

Guards, cost accounting, statistics and what isn't published

Guards: stop above 25 requests, after 150 seconds without progress, after the same semantic tool intent three times, or at a $15 total spend ceiling. Total spend: $1.90.
Cost: computed from provider-reported cache-miss, cache-hit and output tokens at the prices above, plus any summariser usage. DeepSeek reports cache hits as prompt_cache_hit_tokens.
Statistics: paired saving = control cost − treatment cost for the same task and repetition, over all 25 pairs. 95% intervals are percentile intervals from 10,000 bootstrap resamples with a fixed seed of 166.
Quality: a keyword heuristic for triage, plus manual review of all 15 safety-task answers.
Not published: the exact task prompts and raw per-session transcripts, which were held back pending a privacy review. Aggregates are in DEEPSEEK_RESULTS.md.

Results

Medians per session over 25 runs per arm.

Arm	Completed	Loop stops	Median cost	Median input tokens	Median requests	Cache-hit ratio
Control (no compaction)	23/25	2	$0.024820	450,810	16	92.23%
Deterministic	24/25	1	$0.026699	479,087	19	91.68%
Model-gated	24/25	1	$0.022465	444,625	17	92.75%

Deterministic arm: 15 of 25 treatment runs transformed something; 399 applications (34 new transformations, 365 cache reuses) removed 4,809,164 bytes in total. Median paired saving $0.000524 (~2.1%), 95% interval −$0.003714 to +$0.003725. Mean saving −$0.0000559; cheaper in 13 of 25 pairs. Median paired input-token saving 29,117 (interval −57,989 to +60,161). Transformed-only runs had a median change of −$0.000262, a small increase.

Model-gated arm: only four runs transformed output, all through the deterministic rule (6 transformations, 79 reuses). Median paired saving $0.000478 (~1.9%), interval −$0.000998 to +$0.004973; mean $0.001569, cheaper in 15 of 25 pairs. The preflight made zero Flash calls: with six expected applications at DeepSeek's cache-hit price, no rewritten prefix could repay its cache misses. This measures the gate, not model-written summaries.

Loop stops (request-cap terminations) happened in the control arm and in treatment runs with no transformations, so they reflect agent variance rather than compaction.

Median cost by task

Median cost per task. Differences in tool calls and answer length outweighed the value of the removed cached tokens.

Task	Control	Deterministic	Model-gated
Architecture	$0.026040	$0.022984	$0.025993
Economics	$0.024820	$0.026717	$0.021742
Regression review	$0.033672	$0.034278	$0.032411
Safety	$0.017640	$0.015142	$0.017297
Stress	$0.022256	$0.027260	$0.021505

Why it didn't pay: prompt-cache economics

About 92% of input tokens were cache hits in every arm, and a cache hit on V4 Pro cost 0.83% of a miss: about 120× cheaper. The repeated tool output being removed was already nearly free. A rewrite changes the prompt from that point on, so everything after it is billed as new input until the cache is rebuilt.

Removing bytes only pays if the saving on later turns exceeds the misses it causes. With 92% cache hits and a 120× price gap, the removed bytes were worth very little.

That is a property of DeepSeek's pricing. Providers that charge more for cached input, or have no prompt cache at all, could change the result. That is the next experiment (issue #193).

The break-even condition

Let N be future turns, R the rewritten cached span, W the provider's write/input rate, C its cache-read rate, D tokens removed per future turn, and S the summariser cost. Compaction needs:

N > (R × max(0, W − C) + S) / (D × C)

This simplified model assumes positive D × C and matching units: rates per token when S is in dollars. It doesn't model every provider's caching rules or changes in agent behaviour. When economic inputs are missing or the expected net is not positive, the gate does nothing, which is a correct outcome.

What broke along the way

File-read markers caused re-read loops. An earlier, excluded pilot replaced an old file read with a "reread" marker. The agent fetched different line ranges of the same file until it hit the request cap; deduplicating identical arguments didn't help because the offsets kept changing. Source reads are now always exact (#178 tracks a bounded alternative).
The gate missed a cost. An uncached summary candidate was mislabelled as a cache reuse, so the preflight left out the prefix-rewrite premium. Torana paid for Flash summaries that the final gate rejected. Uncached candidates are now treated as rewrites; the corrected run made zero uneconomic summariser calls.
Cache hits were invisible. DeepSeek reports cache usage as prompt_cache_hit_tokens, not the OpenAI-style prompt_tokens_details.cached_tokens. Torana now reads both in streaming, JSON and model-service responses, and /stats reports summariser token usage.

Limitations

One provider, one harness, five tasks, five repetitions per task, and July 2026 prices.
Agent trajectories varied between runs, and many treatment sessions were no-ops.
Bytes are not tokenizer counts; token savings are provider-reported.
The quality heuristic understated semantic quality and was only used for triage.
The excluded pilot is retained only as negative safety evidence.
Compaction can still matter where caching is expensive or absent, or when an agent runs out of context.

What's next

Providers with expensive cache reads. A fixed transcript replay to isolate pricing from agent behaviour, then live paired runs on providers whose cache pricing doesn't make history nearly free (#193).

Decide per tool call, not by size. Some output must stay exact: file reads, edits, errors. Some never needed to stay in the conversation: npm install logs, build output, script runs. Small local decision models such as Jev and Laya can classify a tool call into a fixed set of choices. I'm building a version where one decides, per tool call, whether its output stays exact or can be compacted. That is in progress, not a measured result.

Try it or build on it

compactor, keyword_compactor and intent are Torana plugins. Install them by name, review their permissions and bind a summariser following the compactor guide. Measure with paired runs on your own tool mix and prices, using provider-reported tokens and including summariser cost.

The same plugin SDK powers the local PII check. To build your own, start with the plugin-authoring guide. Results from other providers, especially on #193, are welcome.

How this experiment became Torana: the pivot story →

Your coding agent just read your API keys. I built a local check so they don't reach the model.

Aniket — Sun, 04 Oct 2026 09:59:57 +0000

Your coding agent just read your passwords and API keys. Its next request goes to OpenAI or Anthropic. I built a local check so they don't go with it.

How I got here

Lately, every hardware pitch has "local AI" somewhere in it. I use AI heavily in my engineering workflow, so naturally I was intrigued. If "AI-ready" is going to be part of the sales pitch, I'd at least like it to do something beyond helping justify the price tag.

I tried small local models for tasks I normally give hosted frontier models. I kept having to supervise and correct them enough that I wasn't getting the benefit I wanted. Where would they actually fit?

Then I noticed a trade-off with hosted models: whatever I send them leaves my machine. When a coding agent reads a file, the file's contents become part of its next request to the model. An API key or password it didn't need goes along for the ride.

Could a small local model check that output first? Not a replacement for the hosted model, just a second pair of eyes.

How the check works

I built it as a plugin for Torana, an open-source, local-first proxy that sits between your coding agent and its model provider.

Your agent (Claude Code, Codex, Gemini or another harness) reads a file or runs a tool on your machine.
Before the next request leaves, Torana's pii plugin sends the new tool output to a local model you choose.
If the model flags an API key, password or private personal data, the plugin replaces the whole tool result with a short explanation. The hosted model never sees the original.
The agent can acknowledge that and try another approach, for example reading a narrower range.

The scanner only sees the tool name and the numbered output, not your whole conversation. Earlier decisions are replayed on later turns rather than rescanned.

It's an extra check, not complete protection. A scanner can miss things, and it can block harmless output.

Which small models were actually good at this?

I compared seven local chat models and several specialised detectors on 60 sensitive and 60 harmless synthetic examples. The chat models used Q8 GGUF weights on an Apple Silicon Mac with 24 GB of memory, through llama.cpp.

Model / setup	Detected / 60 sensitive	Harmless blocked / 60	Invalid / 120
Qwen2.5 3B	60	18	0
Qwen3.5 0.8B	60	42	0
privacy-filter (OpenAI, reference runtime)	58	9	0
SecretMasker (DistilBERT, threshold 0.5)	57	10	0
Adapted Ettin17M (research pilot)	57	18	0
Laya	55	28	0
Ettin17M PII	55	33	0
Ettin68M PII	54	37	0
LFM2.5 350M	48	60	24
SecretMasker (threshold 0.99)	43	3	0
pii_guard (regex baseline)	24	0	0
Qwen2.5 0.5B	5	60	110
Falcon-H1-Tiny 90M	0	3	3
Qwen3 0.6B	0	0	0
LFM2.5 1.2B	0	60	120

A few things surprised me:

Blocking isn't the same as detecting. When a model returned garbage, the plugin blocked the output to be safe. Those count as harmless results blocked, never as detections. Qwen2.5 0.5B "blocked everything" mostly because 110 of its 120 answers were invalid.
Valid JSON doesn't mean correct. Qwen3 0.6B produced perfectly structured answers and missed all 60 secrets.
Size isn't everything. Qwen2.5 3B caught all 60, but so did Qwen3.5 0.8B, which also blocked far more harmless output.
Prompt wording swings results both ways. On a second test set built from real open-source code with planted secrets, Qwen2.5 3B caught 50 of 52 with the full prompt. Two simpler yes/no prompts landed at 37 and 49, both without blocking any harmless code.
Specialised detectors are fast but brittle. SecretMasker runs in about 11 ms and caught all 52 real-code secrets, but it also blocked 12 of 26 harmless files, often mistaking opaque hashes for keys.

There's no winner badge here. These are small, synthetic test sets, and later plugin versions need fresh evaluation. The full write-up covers the methodology and its limits.

Try it yourself

This uses Qwen2.5 3B Instruct Q8 as a starting point (about 3.3 GB to download). Check its license before using it at work.

1. Start the local scanner with llama.cpp (brew install llama.cpp on macOS or Linux, winget install llama.cpp on Windows):

llama-server -hf bartowski/Qwen2.5-3B-Instruct-GGUF:Q8_0 --alias local-pii \
  --host 127.0.0.1 --port 8081 -c 8192 -np 1 --jinja --no-context-shift

2. Install Torana and the plugin (macOS or Linux; Windows instructions are in the quickstart):

curl -fsSL https://torana.sh/install.sh | sh
torana start --port 8143
torana plugin install pii
torana open

3. Connect the model to the plugin in the browser UI that opens:

Settings → Add provider: name local-scanner, upstream URL http://127.0.0.1:8081/v1, format openai, No authentication, default model local-pii. Save.
Pipeline → pii → Resource bindings and limits → scanner: choose local-scanner.
Review the permissions and choose Approve & enable.

4. Route your agent through Torana and test with a fake key:

echo 'PAYMENT_API_KEY=sk_test_torana_demo_not_a_real_key_123' > demo-sensitive.txt
echo 'RETRY_COUNT=3' > demo-safe.txt
ANTHROPIC_BASE_URL="$(torana endpoint anthropic)" claude

Ask it to read demo-sensitive.txt. You should see Tool output withheld in the reply and in Torana's Live Feed. demo-safe.txt should come through normally. Codex, Gemini and other harnesses have setup recipes here.

Scanning adds about a second per tool result, and large outputs that don't fit the model's context are blocked as scan failures. Start with small files. When you're done, torana stop --yes.

Why a proxy, and not just a hook?

In typical engineer fashion, I overengineered the reverse proxy I needed for this. It became Torana: reusable plugins, support for different model API formats, and hooks into the agent's traffic. The useful part of that detour: I can build a plugin once and use it across Claude Code, Codex, Gemini and others, instead of rebuilding it for each one.

There are plugins for usage logging, tool policy and context compaction too. The plugin SDK is in Go and Rust, sandboxed in WASM.

Help make it better

If you try it, I'd love to hear what breaks:

harmless code that gets blocked;
secrets that get missed;
a local model or detector that does better.

Open an issue with a synthetic example and your setup (please never real credentials). And if you've built a little harness-specific tool or workflow hack, try turning it into a Torana plugin.

Site: torana.sh
GitHub: torana-edge/torana-edge

Major improvements made to monetize-npm-cli 🔥

Aniket — Sun, 14 Jun 2020 21:23:54 +0000

You can read the original post I wrote here

Aniket

Jun 5 '20

Web Monetization for NPM packages!!

#showdev #gftwhackathon #node #webdev

8 min read

Note

This post is being written at the time of

v0.0.6 of monetize-npm-cli
v0.0.7 of wrapper-coil-extension

And includes changes since the original post was written (June 5).

Improvements !!

wrapper-coil-extension

- Switched to probabilistic revenue sharing

Looping through all the wallets has been replaced by Probabilistic revenue sharing. Payment pointer is now being changed dynamically instead of opening new tab and closing the previous, which also fixed chromium stealing the focus.

- No Focus stealing

- Restricted opening more tabs while content is being monetized

User now cannot open more tabs in the puppeteer chromium instance, thus packages will keep getting monetized.

- Events are being fired and states are now being changed as expected

Event listeners are now being fired correctly along with the same arguments that you would expect to get in the browser. State is also being updated correctly.

- Depreciated Timeout

Since probabilistic revenue sharing is being implemented, timeout is no longer needed. Packages are now selected for 65 seconds each randomly.

monetize-npm-cli

- `addListener`, `invokeListener` and `removeListener` methods renamed to `addEventListener`, `invokeEventListener` and `removeEventListener` respectively

- Added `walletHash` and `nameHash` private variables to monetization object

Previously, the operations getState,addEventListener, removeEventListener and invokeEventListener took O(n) time to find the package being referred to, blocking the main thread. This is now being done in constant time, thus improving performance.
walletHash and nameHash store index of the packages. While nameHash contains the index of the package corresponding to the key, walletHash has array of such indexes for value, as more than one packages can have the same wallet.

In cases when more than one packages have the same wallet, the events are fired and states are changed for all these packages when any one of them is being monetized.

nameHash has keys of the type name@version.

- `invokeEventListener` is now working as expected and taking and passing one argument

This argument is the same as the response object which is passed by any event being fired in the browser, and is passed by the provider module being used. The correct package is identified by looking into the argument for wallet address, which is matched with walletHash to get the correct index.

- Initial state of all packages is now `stopped`

It was pending in previous versions. Fixed now

The main post has also been updated according to these new changes.

The only remaining problem is that monetization does not occur if puppeteer's chromium instance is specifically minimized, otherwise it works fine, even when not in focus. You can leave it running in the background and expect it to be working absolutely fine and as expected.

Web Monetization for NPM packages!!

Aniket — Fri, 05 Jun 2020 20:55:25 +0000

For a long time, I wanted to do some meaningful contribution to the community but was never able to do so. This hackathon gave me the perfect way for doing that, by creating a way to monetize NPM packages!

What I built

I built 2 npm packages

monetize-npm-cli npm
wrapper-coil-extension npm

`monetize-npm-cli`

Quoting its readme

monetize-npm-cli is a modular CLI that helps monetize npm packages using the Web Monetization API and different providers.

And that's exactly what it is

I built a CLI ( for the first time! ) that allows you to run your app inside a container like environment, which it doesn't necessarily know about if it does not go looking around.

node index.js => monetize-npm-cli index.js and you're good to go!

It finds the package.json for your main project and then goes searching inside the node_modules folder. Any package.json it finds there with the key webMonetization is picked up to be monetized

{
  "webMonetization": {
    "wallet": "$yourWalletAddressGoesHere"
  }
}

Just adding this to package.json can allow packages to be monetized.

I wanted to keep the API as similar as possible to the one already existing for browsers, but some changes had to be made for the different environment.

document became globalThis along with the following changes

getState

document.monetization.state => globalThis.monetization.getState(name, version)

name and version are defined in package.json of each package.

Only the packages with webMonetization key in their package.json are accessible here.

addEventListener

There can be four listeners set up monetizationpending, monetizationstart, monetizationstop, monetizationprogress.

Let identify them by listenerIdentifier.

document.monetization.addEventListener(listenerIdentifier, foo) => globalThis.monetization.addEventListener(name, version, listenerIdentifier, foo)

removeEventListener

globalThis.monetization.removeEventListener(name, version, listenerIdentifier, foo)

If foo is not passed, all the listeners for that package are removed.

These methods can be used from wherever inside the application and the installed packages after checking whether globalThis.monetization exists, and can be used accordingly.

globalThis.monetization is itself a proxy of the actual object being used, to make it difficult to tamper with.

Remember the part where I said this CLI is modular? Well, that's because it can add and use many different providers easily with minimal changes!

That's where wrapper-coil-extension comes in

`wrapper-coil-extension`

Quoting its readme

wrapper-coil-extension is a wrapper around Coil's Web Monetization browser extension that allows it to be used from node.js.

Since I needed a provider to work with the CLI I had created, and none of the current ones had an API to achieve that, I had to instead figure out a way to make use of the already existing ones, so I built a wrapper around Coil's Extension that allows me to do so.

Since the extension doesn't currently support monetizing more than one tab at once,all the eligible packages are looped through and a webpage with their wallet is opened for some amount of time ( time can be defined by the user ). This allows payments to be sent to the respective package owners. Fixed in v0.0.7. Probabilistic revenue sharing is done where a package is selected randomly and monetized for 65 seconds each. This process is repeated until the app is closed.

Because Coil's Extension was not built for this kind of scenario, ~~there are some things which do not work as expected~~ everything is working as expected now, more can be seen here

Another problem that exists is that when a new tab opens and previous closes to monetize another package, chromium steals the focus. But since this is meant to be run in a production environment, this is really not an issue. Perfect bug=> feature situation XD Pointer is now changed dynamically in the same tab, thus fixing this problem.

Due to the modular nature of monetize-npm-cli, as more and more providers come up and provide different ways to monetize, their modules can be easily integrated with monetize-npm-cli with minimal changes. You can see how to create such module here.

How is this better than `npm fund`

You may have this question in your head ever since you opened this post. Well, we all have seen the npm fund prompt pop while installing any package that supports it. What most of us haven't done is try to run this command and go the links that are provided, after which you have to perform further digging to find out how to pay and support the developer, which makes for a bad experience, one that can make a person willing to pay opt-out.

Well, this changes that. The number of steps reduces to just installing this package globally, logging in to your provider only once, and just running the app using it.

Some other good changes this can bring

Active development of more packages as developers are being paid for their hobbies.
Careful installation of packages and prevention of installation of unnecessary packages.
More thought on dependency cycle as if two not compatible enough versions of the same packages are listed as dependencies, they could end up being installed twice thus getting monetized twice.

Submission Category:

Here comes the hard part. Throughout the process of building my submission, I was trying to figure out which category it falls into, and I still can't put it into one

Foundational Technology - It is a template for monetizing the web and is a plugin(?)
Creative Catalyst - It is using the existing technologies to find ways to distribute and monetize content.
Exciting Experiments - Web Monetization running outside the browser! You try telling me that's not an Exciting Experiment!

Demo

You can follow along with this demo by simply typing

npm install -g monetize-npm-cli

First of all, let's check whether the package is installed properly

monetize-npm-cli -v

Let's go to the help page

monetize-npm-cli -h

To monetize any package, we need to first login to our provider

monetize-npm-cli --login

This will open up a browser window where you can use your credentials to login

On successful login, we will see this on our terminal

For this demo, I have manually added webMonetization keys to various package.json of some npm packages.

Let's try listing those packages

monetize-npm-cli --list --expand

You can expect to see something like this

Let's add some access to globalThis.monetization from the app which is being run inside the container

Let's try running the app now

monetize-npm-cli index.js

As soon as base64url starts getting paid

We can see the event we set fired up in the console

Link to Code

`monetize-npm-cli`

projectescape / monetize-npm-cli

A CLI that helps monetize npm packages using the Web Monetization API

monetize-npm-cli

monetize-npm-cli is a modular CLI that helps monetize npm packages using the Web Monetization API and different providers.

Install

npm install -g monetize-npm-cli

Usage

Run file

To run your app while monetizing the supported npm packages

monetize-npm-cli yourFile.js

Help

To view help page with all details

monetize-npm-cli --help

Login to your Provider

To login to your web monetization provider

monetize-npm-cli --login

This will default to coil-extension if no provider is provided. See help for more details.

Logout from your Provider

To logout from your web monetization provider

monetize-npm-cli --logout

This will default to coil-extension if no provider is provided. See help for more details.

List packages

To list all packages supporting web monetization

monetize-npm-cli --list

Use help to get full list of supported commands

API

The aim of this CLI is to mimic the web monetization API given here as much as it could Instead of document.monetization, user…

View on GitHub

`wrapper-coil-extension`

projectescape / wrapper-coil-extension

A wrapper for Coil's web monetization extension to make it run from node.js

wrapper-coil-extension

wrapper-coil-extension is a wrapper around Coil's Web Monetization browser extension that allows it to be used from node.js.

Install

npm install --save wrapper-coil-extension

Usage

const { login, logout, monetize } = require("wrapper-coil-extension");

// To Login with your Coil Account

login();

// To Logout

logout();

// To start Monetization

monetize(monetizationPackages);

timeout

(Depreciated)

Since v0.0.7, timeout is no longer used as instead of looping through packages, probablistic revenue sharing is being used.

monetizationPackages

monetizationPackages is an object of the type which is passed by monetize-npm-cli

// monetizationPackages
{
    packages:[
        {
          name: "",
          version: "",
          webMonetization: {
              wallet:""
          },
          state: "",
          monetizationpending: [],
          monetizationstart: [],
          monetizationstop: [],
          monetizationprogress: [],
        }
    ]

…

View on GitHub

How I built it

This submission was a lot of fun to build. Building a CLI and automating websites was completely new for me

`monetize-npm-cli`

I parsed the arguments with minimist and used kleur for logs.

fast-glob was used to find package.json while maintaining inter os compatibility.

The hard part here was designing the monetization object, as I had to deal with listeners, packages and their states, all while keeping some of the stuff private for globalThis.monetization and the object being passed to the provider module. After a lot of researching, I learned a lot about JS objects and came up with this

const monetization = (() => {
  let packages = [];
  const walletHash = {};
  const nameHash = {};

  return {
    get packages() {
      return packages;
    },
    set packages(val) {
      packages = val;
      val.forEach((p, index) => {
        if (walletHash[p.webMonetization.wallet] === undefined)
          walletHash[p.webMonetization.wallet] = [index];
        else walletHash[p.webMonetization.wallet].push(index);

        nameHash[`${p.name}@${p.version}`] = index;
      });
    },
    getState(name, version) {
      if (nameHash[`${name}@${version}`] !== undefined) {
        return packages[nameHash[`${name}@${version}`]].state;
      }
      console.log(`No package ${name}@${version} found\n`);
      return undefined;
    },
    addEventListener(name, version, listener, foo) {
      if (
        !(
          listener === "monetizationpending" ||
          listener === "monetizationstart" ||
          listener === "monetizationstop" ||
          listener === "monetizationprogress"
        )
      ) {
        console.log(`${listener} is not a valid event name\n`);
        return false;
      }
      if (nameHash[`${name}@${version}`] !== undefined) {
        packages[nameHash[`${name}@${version}`]][listener].push(foo);
        return true;
      }
      console.log(`No package ${name}@${version} found\n`);
      return false;
    },
    removeEventListener(name, version, listener, foo = undefined) {
      if (
        !(
          listener === "monetizationpending" ||
          listener === "monetizationstart" ||
          listener === "monetizationstop" ||
          listener === "monetizationprogress"
        )
      ) {
        console.log(`${listener} is not a valid event name\n`);
        return false;
      }
      if (nameHash[`${name}@${version}`] !== undefined) {
        if (!foo) {
          packages[nameHash[`${name}@${version}`]][listener] = [];
        } else {
          packages[nameHash[`${name}@${version}`]][listener] = packages[
            nameHash[`${name}@${version}`]
          ][listener].filter((found) => foo !== found);
        }
        return true;
      }
      console.log(`No package ${name}@${version} found\n`);
      return false;
    },
    invokeEventListener(data) {
      walletHash[data.detail.paymentPointer].forEach((index) => {
        packages[index].state =
          data.type === "monetizationstart" ||
          data.type === "monetizationprogress"
            ? "started"
            : data.type === "monetizationpending"
            ? "pending"
            : "stopped";
        packages[index][data.type].forEach((listener) => {
          listener(data);
        });
      });
    },
  };
})();

globalThis.monetization was implemented using a proxy like this

globalThis.monetization = new Proxy(monetization, {
  set: () => {
    console.log("Not allowed to mutate values\n");
  },
  get(target, key, receiver) {
    if (
      key === "getState" ||
      key === "addEventListener" ||
      key === "removeEventListener"
    ) {
      return Reflect.get(...arguments);
    } else {
      console.log(`Not allowed to access monetization.${key}\n`);
      return null;
    }
  },
});

This prevents tampering of the original object while exposing only the needed functionality.

Module providers are passed another proxy for the same purpose

new Proxy(monetization, {
        set: () => {
          console.log("Not allowed to mutate values\n");
        },
        get(target, key, receiver) {
          if (key === "packages" || key === "invokeEventListener") {
            return Reflect.get(...arguments);
          } else {
            console.log(`Not allowed to access monetization.${key}\n`);
            return null;
          }
        },
      }),

`wrapper-coil-extension`

This was tough. Initially, I tried to reverse engineer Coil's Extension by looking at their code on GitHub, but it was way too much for me to understand and code again. No experience with Typescript or building any browser extension did not help also.

Then I found puppeteer ( thanks @wobsoriano )

I poked around Coil's website and found that they were setting a jwt in localStorage whenever a user logs in. This allowed for the login and logout functionality, as I had to just store the jwt locally.

For monetizing packages, I ~~looped through all the monetization enabled packages~~ set up probabilistic revenue sharing and made a template HTML file which would fill up with the values of the respective wallets for 65 seconds each.

A lot of work was also done to make listeners work as expected, and keeping the functionality similar to the browser counterpart.

These pages were then fed to puppeteer which sent payments using coil's extension after looking at the set wallet.

Additional Resources / Info

All the resources are already linked throughout the post.

Unable to use global variables with es6 imports in node

Aniket — Thu, 28 May 2020 19:44:44 +0000

I'm building a CLI that injects some variables into the imported packages for them to use. Normally, I would do something like this

const foo=()=>{
   console.log("Hello World");
}
global.foo=foo;
require('./index.js')

Where index.js is

if(global.foo){
    global.foo();
}

But since the latest version of node also supports .mjs files that enables es6 imports, this approach won't work as es6 imports don't have access to global.

I cannot use process.env as I want to share functions too and add listeners to the variables.

Any help would be appreciated

The Comprehensive Sequelize Cheatsheet

Aniket — Fri, 08 May 2020 18:14:48 +0000

Sequelize is the most famous Node ORM and is quite feature-rich, but while using it I spend much of my time juggling around between the documentation and different google searches.
This Cheatsheet is the one that I always wanted but was never able to find.
See any error or anything missing? Comment below, or better, send a pull request to the repo linked in the end.

Installing Dependencies
1. Installing Sequelize
2. Installing Database Driver
Setting up a Connection
1. Instance Creation
2. Testing Connection
3. Closing Connection
Defining Models
1. Basic Definition
2. Extending Column Definition
  1. Basic Extentions
  2. Composite Unique Key
  3. Getters and Setters
  4. Validations
    1. Per Attribute Validations
    2. Model Wide Validations
  5. Timestamps
  6. Database Synchronization
  7. Expansion of Models
  8. Indexes
Associations
1. Defining Associations
  1. hasOne
  2. belongsTo
  3. hasMany
  4. belongsToMany
2. Relations
  1. One to One
  2. One to Many
  3. Many to Many
Instances
1. Creating Instances
  1. build
  2. create
2. Mutating Instances
  1. Update
  2. Delete
Using Models
1. Methods
  1. findByPk
  2. findOne
  3. findOrCreate
  4. findAll
  5. findAndCountAll
  6. count
  7. max
  8. min
  9. sum
2. Filtering
  1. where
    1. Operators
  2. order
  3. Pagination and Limiting
Things I did not include in this Cheatsheet (with links to official docs)

Installing Dependencies

Installing Sequelize

npm install --save sequelize

Installing Database Driver

You also need to install the driver for the database you're using.

# One of the following:
npm install --save pg pg-hstore # Postgres If node version < 14 use pg@7.12.1 instead
npm install --save mysql2
npm install --save mariadb
npm install --save sqlite3
npm install --save tedious # Microsoft SQL Server

Setting up a Connection

A Sequelize instance must be created to connect to the database. By default, this connection is kept open and used for all the queries but can be closed explicitly.

Instance Creation

const Sequelize = require('sequelize');

// Option 1: Passing parameters separately
const sequelize = new Sequelize('database', 'username', 'password', {
  host: 'localhost',
  dialect: /* one of 'mysql' | 'mariadb' | 'postgres' | 'mssql' */
});

// Option 2: Passing a connection URI
const sequelize = new Sequelize('postgres://user:pass@example.com:5432/dbname');

// For SQLite, use this instead
const sequelize = new Sequelize({
  dialect: 'sqlite',
  storage: 'path/to/database.sqlite'
});

For more detailed information about connecting to different dialects, check out the official docs

Testing Connection

.authenticate() can be used with the created instance to check whether the connection is working.

sequelize
  .authenticate()
  .then(() => {
    console.log("Connection has been established successfully.");
  })
  .catch((err) => {
    console.error("Unable to connect to the database:", err);
  });

Closing Connection

sequelize.close();

Defining Models

Basic Definition

To define mappings between Model and Table, we can use the .define() method
To set up a basic model with only attributes and their datatypes

const ModelName = sequelize.define("tablename", {
  // s will be appended automatically to the tablename
  firstColumn: Sequelize.INTEGER,
  secondColumn: Sequelize.STRING,
});

For getting a list of all the data types supported by Sequelize, check out the official docs

Extending Column Definition

Basic Extentions

Apart from datatypes, many other options can also be set on each column

const ModelName = sequelize.define("tablename", {
  firstColumn: {
    // REQUIRED
    type: Sequelize.INTEGER,
    // OPTIONAL
    allowNull: false, // true by default
    defaultValue: 1,
    primaryKey: true, // false by default
    autoIncrement: true, // false by default
    unique: true,
    field: "first_column", // To change the field name in actual table
  },
});

Composite Unique Key

To create a composite unique key, give the same name to the constraint in all the columns you want to include in the composite unique key

const ModelName = sequelize.define("tablename", {
  firstColumn: {
    type: Sequelize.INTEGER,
    unique: "compositeIndex",
  },
  secondColumn: {
    type: Sequelize.INTEGER,
    unique: "compositeIndex",
  },
});

They can also be created using indexes

const ModelName = sequelize.define(
  "tablename",
  {
    firstColumn: Sequelize.INTEGER,
    secondColumn: Sequelize.INTEGER,
  },
  {
    indexes: [
      {
        unique: true,
        fields: ["firstColumn", "secondColumn"],
      },
    ],
  }
);

Getters and Setters

Getters can be used to get the value of the column after some processing.
Setters can be used to process the value before saving it into the table.

const Employee = sequelize.define("employee", {
  name: {
    type: Sequelize.STRING,
    allowNull: false,
    get() {
      const title = this.getDataValue("title");
      // 'this' allows you to access attributes of the instance
      return this.getDataValue("name") + " (" + title + ")";
    },
  },
  title: {
    type: Sequelize.STRING,
    allowNull: false,
    set(val) {
      this.setDataValue("title", val.toUpperCase());
    },
  },
});

Employee.create({ name: "John Doe", title: "senior engineer" }).then(
  (employee) => {
    console.log(employee.get("name")); // John Doe (SENIOR ENGINEER)
    console.log(employee.get("title")); // SENIOR ENGINEER
  }
);

For more in-depth information about Getters and Setters, check out the official docs

Validations

Validations are automatically run on create, update and save

Per Attribute Validations

const ModelName = sequelize.define("tablename", {
  firstColumn: {
    type: Sequelize.STRING,
    validate: {
      is: ["^[a-z]+$", "i"], // will only allow letters
      is: /^[a-z]+$/i, // same as the previous example using real RegExp
      not: ["[a-z]", "i"], // will not allow letters
      isEmail: true, // checks for email format (foo@bar.com)
      isUrl: true, // checks for url format (http://foo.com)
      isIP: true, // checks for IPv4 (129.89.23.1) or IPv6 format
      isIPv4: true, // checks for IPv4 (129.89.23.1)
      isIPv6: true, // checks for IPv6 format
      isAlpha: true, // will only allow letters
      isAlphanumeric: true, // will only allow alphanumeric characters, so "_abc" will fail
      isNumeric: true, // will only allow numbers
      isInt: true, // checks for valid integers
      isFloat: true, // checks for valid floating point numbers
      isDecimal: true, // checks for any numbers
      isLowercase: true, // checks for lowercase
      isUppercase: true, // checks for uppercase
      notNull: true, // won't allow null
      isNull: true, // only allows null
      notEmpty: true, // don't allow empty strings
      equals: "specific value", // only allow a specific value
      contains: "foo", // force specific substrings
      notIn: [["foo", "bar"]], // check the value is not one of these
      isIn: [["foo", "bar"]], // check the value is one of these
      notContains: "bar", // don't allow specific substrings
      len: [2, 10], // only allow values with length between 2 and 10
      isUUID: 4, // only allow uuids
      isDate: true, // only allow date strings
      isAfter: "2011-11-05", // only allow date strings after a specific date
      isBefore: "2011-11-05", // only allow date strings before a specific date
      max: 23, // only allow values <= 23
      min: 23, // only allow values >= 23
      isCreditCard: true, // check for valid credit card numbers

      // Examples of custom validators:
      isEven(value) {
        if (parseInt(value) % 2 !== 0) {
          throw new Error("Only even values are allowed!");
        }
      },
    },
  },
});

Model Wide Validations

const ModelName = sequelize.define(
  "tablename",
  {
    firstColumn: Sequelize.INTEGER,
    secondColumn: Sequelize.INTEGER,
  },
  {
    validate: {
      // Define your Model Wide Validations here
      checkSum() {
        if (this.firstColumn + this.secondColumn < 10) {
          throw new Error("Require sum of columns >=10");
        }
      },
    },
  }
);

Timestamps

const ModelName = sequelize.define(
  "tablename",
  {
    firstColumn: Sequelize.INTEGER,
  },
  {
    timestamps: true, // Enable timestamps
    createdAt: false, // Don't create createdAt
    updatedAt: false, // Don't create updatedAt
    updatedAt: "updateTimestamp", // updatedAt should be called updateTimestamp
  }
);

Database Synchronization

Sequelize can automatically create the tables, relations and constraints as defined in the models

ModelName.sync(); // Create the table if not already present

// Force the creation
ModelName.sync({ force: true }); // this will drop the table first and re-create it afterwards

ModelName.drop(); // drop the tables

You can manage all models at once using sequelize instead

sequelize.sync(); // Sync all models that aren't already in the database

sequelize.sync({ force: true }); // Force sync all models

sequelize.sync({ force: true, match: /_test$/ }); // Run .sync() only if database name ends with '_test'

sequelize.drop(); // Drop all tables

Expansion of Models

Sequelize Models are ES6 classes. We can easily add custom instance or class level methods.

const ModelName = sequelize.define("tablename", {
  firstColumn: Sequelize.STRING,
  secondColumn: Sequelize.STRING,
});
// Adding a class level method
ModelName.classLevelMethod = function () {
  return "This is a Class level method";
};

// Adding a instance level method
ModelName.prototype.instanceLevelMethod = function () {
  return [this.firstColumn, this.secondColumn].join(" ");
};

Indexes

const User = sequelize.define(
  "User",
  {
    /* attributes */
  },
  {
    indexes: [
      // Create a unique index on email
      {
        unique: true,
        fields: ["email"],
      },

      // Creates a gin index on data with the jsonb_path_ops operator
      {
        fields: ["data"],
        using: "gin",
        operator: "jsonb_path_ops",
      },

      // By default index name will be [table]_[fields]
      // Creates a multi column partial index
      {
        name: "public_by_author",
        fields: ["author", "status"],
        where: {
          status: "public",
        },
      },

      // A BTREE index with an ordered field
      {
        name: "title_index",
        using: "BTREE",
        fields: [
          "author",
          {
            attribute: "title",
            collate: "en_US",
            order: "DESC",
            length: 5,
          },
        ],
      },
    ],
  }
);

Associations

Defining Associations

There are four types of definitions. They are used in pairs.
For the example lets define two Models

const Foo = sequelize.define("foo" /* ... */);
const Bar = sequelize.define("bar" /* ... */);

The model whose function we will be calling is called the source model, and the model which is passed as a parameter is called the target model.

hasOne

Foo.hasOne(Bar, {
  /* options */
});

This states that a One-to-One relationship exists between Foo and Bar with foreign key defined in Bar

belongsTo

Foo.belongsTo(Bar, {
  /* options */
});

This states that a One-to-One or One-to-Many relationship exists between Foo and Bar with foreign key defined in Foo

hasMany

Foo.hasMany(Bar, {
  /* options */
});

This states that a One-to-Many relationship exists between Foo and Bar with foreign key defined in Bar

belongsToMany

Foo.belongsToMany(Bar, {
  // REQUIRED
  through: "C", // Model can also be passed here
  /* options */
});

This states that a Many-to-Many relationship exists between Foo and Bar through a junction table C

Relations

One to One

To setup a One-to-One relationship, we have to simply write

Foo.hasOne(Bar);
Bar.belongsTo(Foo);

In the above case, no option was passed. This will auto create a foreign key column in Bar referencing to the primary key of Foo. If the column name of PK of Foo is email, the column formed in Bar will be fooEmail.

Options

The following options can be passed to customize the relation.

Foo.hasOne(Bar, {
  foreignKey: "customNameForFKColumn", // Name for new column added to Bar
  sourceKey: "email", // Column in Foo that FK will reference to
  // The possible choices are RESTRICT, CASCADE, NO ACTION, SET DEFAULT and SET NULL
  onDelete: "RESTRICT", // Default is SET NULL
  onUpdate: "RESTRICT", // Default is CASCADE
});
Bar.belongsTo(Foo, {
  foreignKey: "customNameForFKColumn", // Name for new column added to Bar
});

One to Many

To setup a One-to-One relationship, we have to simply write

Foo.hasMany(Bar);
Bar.belongsTo(Foo);

Options

The following options can be passed to customize the relation.

Foo.hasMany(Bar, {
  foreignKey: "customNameForFKColumn", // Name for new column added to Bar
  sourceKey: "email", // Column in Foo that FK will reference to
  // The possible choices are RESTRICT, CASCADE, NO ACTION, SET DEFAULT and SET NULL
  onDelete: "RESTRICT", // Default is SET NULL
  onUpdate: "RESTRICT", // Default is CASCADE
});
Bar.belongsTo(Foo, {
  foreignKey: "customNameForFKColumn", // Name for new column added to Bar
});

Many to Many

To setup a Many-to-Many relationship, we have to simply write

// This will create a new table rel referencing the PK(by default) of both the tables
Foo.belongsToMany(Bar, { through: "rel" });
Bar.belongsToMany(Foo, { through: "rel" });

Options

The following options can be passed to customize the relation.

Foo.belongsToMany(Bar, {
  as: "Bar",
  through: "rel",
  foreignKey: "customNameForFoo", // Custom name for column in rel referencing to Foo
  sourceKey: "name", // Column in Foo which rel will reference to
});
Bar.belongsToMany(Foo, {
  as: "Foo",
  through: "rel",
  foreignKey: "customNameForBar", // Custom name for column in rel referencing to Bar
  sourceKey: "name", // Column in Foo which rel will reference to
});

Instances

Creating Instances

There are two ways to create instances

build

We can use build method to create non-persistent(not saved to table) instances. They will automatically get the default values as stated while defining the Model.
To save to the table we need to save these instances explicitly.

const instance = ModelName.build({
  firstColumn: "Lorem Ipsum",
  secondColumn: "Dotor",
});
// To save this instance to the db
instance.save().then((savedInstance) => {});

create

We can create a method to create persistent(saved to table) instances

const instance = ModelName.create({
  firstColumn: "Lorem Ipsum",
  secondColumn: "Dotor",
});

Mutating Instances

Update

There are two ways to update any instance

// Way 1
instance.secondColumn = "Updated Dotor";
instance.save().then(() => {});
// To update only some of the modified fields
instance.save({ fields: ["secondColumn"] }).then(() => {});

// Way 2
instance
  .update({
    secondColumn: "Updated Dotor",
  })
  .then(() => {});
// To update only some of the modified fields
instance
  .update(
    {
      secondColumn: "Updated Dotor",
    },
    { fields: ["secondColumn"] }
  )
  .then(() => {});

Delete

To delete/destroy any instance

instance.destroy().then(() => {});

Using Models

Methods

findByPk

Returns the row with the given value of Primary Key.

ModelName.findByPK(PKvalue).then((foundResult) => {});

findOne

Returns the first row with the given conditions.

ModelName.findOne({
  // Optional options
  // Filtering results using where
  where: { firstColumn: "value" },
  // Returning only specified columns
  attributes: ["firstColumn", "secondColumn"],
}).then((foundResult) => {});

findOrCreate

Returns the row found with given conditions. If no such row exists, creates one and returns that instead

ModelName.findOrCreate({
  // Conditions that must be met
  where: { firstColumn: "lorem ipsum" },
  // Value of other columns to be set if no such row found
  defaults: { secondColumn: "dotor" },
}).then(([result, created]) => {}); //Created is a bool which tells created or not

findAll

Returns all the rows satisfying the conditions

ModelName.findAll({
  // Optional Options
  where: {
    firstColumn: "lorem ipsum",
  },
  offset: 10,
  limit: 2,
}).then((results) => {});

findAndCountAll

Returns all the rows satisfying the conditions along with their count

ModelName.findAndCountAll({
  where: {
    firstColumn: "lorem ipsum",
  },
}).then((results) => {
  console.log(results.count);
  console.log(results.rows);
});

count

Returns number of rows satisfying the conditions

ModelName.count({
  where: {
    firstColumn: "lorem ipsum",
  },
}).then((c) => {});

max

Returns the value of the column with max value with given conditions

ModelName.max("age", {
  where: {
    firstColumn: "lorem ipsum",
  },
}).then((maxAge) => {});

min

Returns the value of the column with min value with given conditions

ModelName.min("age", {
  where: {
    firstColumn: "lorem ipsum",
  },
}).then((minAge) => {});

sum

Returns the sum of all the values of the columns with given conditions

ModelName.sum({
  where: {
    firstColumn: "lorem ipsum",
  },
}).then((sumAge) => {});

Filtering

where

where can be used to filter the results we work on

We can directly pass the values

ModelName.findAll({
  where: {
    firstColumn: "lorem ipsum",
  },
});

We can use AND and OR

const Op = Sequelize.Op;
ModelName.findAll({
  where: {
    [Op.and]: [{ secondColumn: 5 }, { thirdColumn: 6 }],
    [Op.or]: [{ secondColumn: 5 }, { secondColumn: 6 }],
  },
});

We can use various other operators

const Op = Sequelize.Op;
ModelName.findAll({
  where: {
    firstColumn: {
      [Op.ne]: "lorem ipsum dotor", // Not equal to
    },
  },
});

We can mix and match too

const Op = Sequelize.Op;
ModelName.findAll({
  where: {
    [Op.or]: {
      [Op.lt]: 1000,
      [Op.eq]: null,
    },
  },
});

Operators

Here is the full list of Operators

const Op = Sequelize.Op

[Op.and]: [{a: 5}, {b: 6}] // (a = 5) AND (b = 6)
[Op.or]: [{a: 5}, {a: 6}]  // (a = 5 OR a = 6)
[Op.gt]: 6,                // > 6
[Op.gte]: 6,               // >= 6
[Op.lt]: 10,               // < 10
[Op.lte]: 10,              // <= 10
[Op.ne]: 20,               // != 20
[Op.eq]: 3,                // = 3
[Op.is]: null              // IS NULL
[Op.not]: true,            // IS NOT TRUE
[Op.between]: [6, 10],     // BETWEEN 6 AND 10
[Op.notBetween]: [11, 15], // NOT BETWEEN 11 AND 15
[Op.in]: [1, 2],           // IN [1, 2]
[Op.notIn]: [1, 2],        // NOT IN [1, 2]
[Op.like]: '%hat',         // LIKE '%hat'
[Op.notLike]: '%hat'       // NOT LIKE '%hat'
[Op.iLike]: '%hat'         // ILIKE '%hat' (case insensitive) (PG only)
[Op.notILike]: '%hat'      // NOT ILIKE '%hat'  (PG only)
[Op.startsWith]: 'hat'     // LIKE 'hat%'
[Op.endsWith]: 'hat'       // LIKE '%hat'
[Op.substring]: 'hat'      // LIKE '%hat%'
[Op.regexp]: '^[h|a|t]'    // REGEXP/~ '^[h|a|t]' (MySQL/PG only)
[Op.notRegexp]: '^[h|a|t]' // NOT REGEXP/!~ '^[h|a|t]' (MySQL/PG only)
[Op.iRegexp]: '^[h|a|t]'    // ~* '^[h|a|t]' (PG only)
[Op.notIRegexp]: '^[h|a|t]' // !~* '^[h|a|t]' (PG only)
[Op.like]: { [Op.any]: ['cat', 'hat']}
                           // LIKE ANY ARRAY['cat', 'hat'] - also works for iLike and notLike
[Op.overlap]: [1, 2]       // && [1, 2] (PG array overlap operator)
[Op.contains]: [1, 2]      // @> [1, 2] (PG array contains operator)
[Op.contained]: [1, 2]     // <@ [1, 2] (PG array contained by operator)
[Op.any]: [2,3]            // ANY ARRAY[2, 3]::INTEGER (PG only)

[Op.col]: 'user.organization_id' // = "user"."organization_id", with dialect specific column identifiers, PG in this example
[Op.gt]: { [Op.all]: literal('SELECT 1') }
                          // > ALL (SELECT 1)
[Op.contains]: 2           // @> '2'::integer (PG range contains element operator)
[Op.contains]: [1, 2]      // @> [1, 2) (PG range contains range operator)
[Op.contained]: [1, 2]     // <@ [1, 2) (PG range is contained by operator)
[Op.overlap]: [1, 2]       // && [1, 2) (PG range overlap (have points in common) operator)
[Op.adjacent]: [1, 2]      // -|- [1, 2) (PG range is adjacent to operator)
[Op.strictLeft]: [1, 2]    // << [1, 2) (PG range strictly left of operator)
[Op.strictRight]: [1, 2]   // >> [1, 2) (PG range strictly right of operator)
[Op.noExtendRight]: [1, 2] // &< [1, 2) (PG range does not extend to the right of operator)
[Op.noExtendLeft]: [1, 2]  // &> [1, 2) (PG range does not extend to the left of operator)

order

ModelName.findAll({
  order: [
    ["firstColumn", "DESC"],
    ["secondColumn", "ASC"],
  ],
});

For much more detailed information on ordering, check out the official docs

Pagination and Limiting

ModelName.findAll({
  offset: 5, // Skip the first five results
  limit: 5, // Return only five results
});

Checkout my blogs repo

Send pull requests to add/modify to this post.

projectescape / blogs-reference

A repository which contains the source complementing all the blogs I write

A crash course to Bookshelf.js

Code for this blog can be accessed here

Programmatic Navigation in React

Code for this blog can be accessed here

The Comprehensive Sequelize Cheatsheet

Markdown for this blog can be accessed here

View on GitHub

Submission : Git Talking

Aniket — Fri, 01 May 2020 03:54:18 +0000

What I built

Git Talking

Git talking is an application that helps you manage your GitHub projects by providing a platform to interact with other contributors by having features like Chat for discussion, Code Snippet Share for fast exchange of code and logic and CheckList to manage completed and pending tasks.
Subchannels for individual files of the repository can also be made to get new instances of Chat, Snippet Share and CheckList that can be used to have those file specific exchanges.

Use Case

This is the page user will see after signing in through Github.
On left the user's own channels will be shown and on right, user can search for other channels to join.

To create a new channel, the user can press "Create New Channel"

All repos for which channel hasn't been made will be shown here.
User can then select a repo to create a new channel for it.

Another user can then search for this channel by either the username of the owner or the repo name and join

They can then communicate with messages.

Code can also be shared through the snippet section

Here the user will be greeted with a code editor like interface with syntax highlighting and shortcuts.

To publish the changes made by any user to remote, Snippet has to be pushed. Upon pushing, other users will see something like this.

To get the latest code, the user can pull the remote code.

Channels will also have Checklist

This will be synced with other users as soon as some change happen

Also, chat will notify the members if changes are made to Snippet or CheckList

Each Channel has subchannels.
General is the default subchannel created at first for every repo.
Each subchannel has its independent Chat, Snippet Share, and Checklist

To create a new subchannel the owner of the repo will see an option to create subchannel

Subchannels can only be created for files and not for directories.

The non-owner user can then join subchannel by listing all unsubscribed subchannels

How I built it (what's the stack? did I run into issues or discover something new along the way?)

I built this app using the PERN stack and GitHub user, repos and content API.

Chat was implemented using Twilio Programmable Chat.

Although it could've been done without Postgres, I still used it to store all the created channels and user-channel relationships as I wasn't able to find any way by which subscribed channels can be fetched by applying a filter using the Twilio web client and it was driving me crazy that all the channels are being fetched again and again.

Code Snippet Share and CheckList were made using Twilio Sync.

For Snippet Share I found a cool library named "@monaco-editor/react" which is also used by VS Code!!

Problems I faced

I also implemented functionality to delete channels, but since it was a little buggy, I commented it out for the final submission.
CSS. Whatever I learned(again!!) while making this project, I'm positive I'll have to learn again for the next one.
Rolling Release Distros are great, but they do come with their cons. I updated node to v14 without noticing ( I literally have to type yay to update my packages, and I have a bad habit of doing that just for fun ) while building the project and had to spend at least a couple hours trying to figure out what had happened. Apparently, v14 has some breaking changes which wouldn't let me connect to postgres. This is the reason why I have provided a legacy package.json in my project so that people with older versions can run it.

Category Submission

Interesting Integrations
Engaging Engagements

Link to Code and Setup guide

projectescape / twilio-hack

Manage your github projects by having a platform to interact with other contributors

Git Talking

Git talking is an application that helps you manage your github projects by providing a platform to interact with other contributors by having features like Chat for discussion, Code Snippet Share for fast exchange of code and logic and CheckList to manage completed and pending tasks Subchannels for individual files of the repository can also be made to get new instances of Chat, Snippet Share and CheckList that can be used to have those file specific exchanges.

Dev post for the project

Note

This App uses Twilio services to function, so twilio specific keys are needed.
This App is setup using node.js v14 . If you are using an older version of node ( < 14 ), see legacy setup towards the end.

Local Setup

Rename dev.example.js(./config/keys/dev.example.js) to dev.js (./config/keys/dev.js) and fill values for the keys with values xxx.
Open a terminal in the root…

View on GitHub

Git Talking - Manage Your github projects

Aniket — Sun, 26 Apr 2020 13:10:00 +0000

Aniket

May 1 '20

Submission : Git Talking

#showdev #twiliohackathon

4 min read

For the hackathon, I'm building a platform that will help people have chat, checklist, code snippet sharing ( and maybe screen sharing too ) for their github projects.
User will be able to choose which of his own repository he want to create chat/list/snippet share for, and also choose different files which can have independent chat/list/snippet. Other users can then join these channels and interact.

What I'll be using

PERN Stack
Github API
Twilio Chat API
Twilio Sync API

Progress So Far

I've setup the backend with github oauth service
Setup Chat token generation
Initialized React Project with some styling

Problems I'm Facing

Currently I'm not being able to figure out how to to apply a search filter while retrieving all chat channels.I searched about it and found a post on stackoverflow saying it could be done using chat's REST API, but I wasn't able to find this in docs. As it was driving me crazy how the frontend will always have to fetch all channels every time, I've decided to keep track of all channels in my db and give frontend filtered results.
As the users will be sharing code snippets, I wanted the code syntax to be highlighted. I haven't still found some package which provides this by automatically detecting languages. If anyone could help me with these problems, please do!

Not exactly related to the project

Extra points if someone could suggest a better name for the project
Also, please someone do tell me how people are linking their articles together using that box links. :)

Repository

projectescape / twilio-hack

Manage your github projects by having a platform to interact with other contributors

Git Talking

Dev post for the project

Note

This App uses Twilio services to function, so twilio specific keys are needed.
This App is setup using node.js v14 . If you are using an older version of node ( < 14 ), see legacy setup towards the end.

Local Setup

Rename dev.example.js(./config/keys/dev.example.js) to dev.js (./config/keys/dev.js) and fill values for the keys with values xxx.
Open a terminal in the root…

View on GitHub

Programmatic Navigation in React using react-router

Aniket — Thu, 28 Nov 2019 23:24:10 +0000

I have seen my fair share of react tutorials, but any time that they talk about navigation using react-router, they only show the way using the Link component. As soon as someone starts working on his/her own project, one of the first problems they come across is how to route programmatically, which basically means routing with ways other than clicking on something wrapped inside a <Link> component.
This blog mainly aims to be a refuge to those people who come here looking for the answers to this problem.

1. <Redirect> Component

We can redirect using <Redirect> component by simply passing the route we want to redirect to and rendering the component. It already comes loaded in the react-router-dom library.

import { Redirect } from "react-router-dom";

The easiest way to use this method is by maintaining a redirect property inside the state of the component.

state = { redirect: null };
render() {
  if (this.state.redirect) {
    return <Redirect to={this.state.redirect} />
  }
  return(
  // Your Code goes here
  )
}

Whenever you want to redirect to another path, you can simply change the state to re-render the component, thus rendering the <Redirect> component.

this.setState({ redirect: "/someRoute" });

Note
This is the recommended way to navigate other than the <Link> method.
Discussed in detail towards the end of the post.

The downside of this method is that in cases like when we want to redirect directly from a redux action, we cannot do so.

2. useHistory Hook

As of release 5.1.2, react-router ships with some new hooks that can help us access the state of the router.

For now, we only need to talk about the useHistory hook.

import { useHistory } from "react-router-dom";

function App() {
  let history = useHistory();
}

After this, we can use the .push() method to redirect to any route we want.

history.push('/someRoute')

3. History prop

Every component that is an immediate child of the <Route> component receives history object as a prop. This is the same history (library) which keeps history of the session of React Router. We can thus use its properties to navigate to the required paths.

this.props.history.push("/first");

A common problem that we can encounter here is that in components which are not an immediate child to the <Route> component, there is no history prop present. This can be easily solved using the withRouter function.

3.1. withRouter

withRouter is a function provided in the react-router-dom library that helps us access the history prop in components which are not immediate children to the <Route> components.
To import withRouter

import { withRouter } from "react-router-dom";

Now to get the history prop inside our component, we need to wrap our component with withRouter while exporting it.

export default withRouter(yourComponent);

We can now access the history prop same as above to do our required navigations.

4. createHistory

The methods we learned above can cover most of the cases that we'll ever encounter while building a react app, so why this fourth method?
Every time we need to redirect from, say as an example a redux action, we always have to pass history to the action, unnecessarily increasing the number of arguments. This method can thus be used to get a neater code.

In this method, we make our custom history instance which we can import in other files to redirect.

// Inside /utils/history.js
import createHistory from "history/createBrowserHistory";
export default createHistory();

As <BrowserRouter> uses its own history and does not accept any outer history property, we have to use <Router> instead of it.

import { Router } from "react-router-dom";
import history from "./utils/history";

function App(){
  return(
    <Router history={history}>
    // Your Routes go here
    <Router>
  )
}

After this, we can import this history instance in whichever file we want to redirect from.

import history from "./utils/history";

history.push("/somePath");

NOTE

At its core, React is a declarative approach to building UIs.

Declarative approach is one where we express the logic of a computation without describing its control flow, or without describing what's actually happening behind the scenes.

Due to this reason, the recommended way to navigate other than <Link> is using <Redirect> component.

There is no harm in using the other methods mentioned here, just that they don't exactly align with React's vision.

Repository

A fully working implementation of the above methods is available on my Github profile. Feel free to explore it if anyone wants to see these methods actually working in a project.

projectescape / blogs-reference

A repository which contains the source complementing all the blogs I write

A crash course to Bookshelf.js

Code for this blog can be accessed here

Programmatic Navigation in React

Code for this blog can be accessed here

The Comprehensive Sequelize Cheatsheet

Markdown for this blog can be accessed here

View on GitHub

A quick starter for Bookshelf.js

Aniket — Mon, 07 Oct 2019 23:31:57 +0000

With the ongoing event of Hacktoberfest, I have found many projects (Like bookbrainz from metabrainz) using bookshelf.js as their ORM instead of something more mainstream like sequelize. Diversity is great, but the only problem is that although the official docs are comprehensive, other resources for learning bookshelf are scarce, outdated, or do not contain information about handling relations. The goal of writing this blog is to tackle these problems. So without any further ado.

Basic Setup

We'll be making a very basic CRUD API in express using bookshelf and later move on to relationships.

First installing the basic requirements

npm i express body-parser bookshelf knex pg

Bookshelf relies on Knex which is a database connection library, to well, connect to databases.
We also install pg as in this example, as I'm using postgres as my database.
If you're using some other database, you can swap pg for sqlite3/mysql/oracle.

Initializing index.js

First, some code for initializing express

var app = require("express")();
var bodyParser = require("body-parser");
app.use(bodyParser.urlencoded({ extended: true }));
app.listen(PORT);

To connect the database to our server, we'll have to write the config for it

var config = {
  client: "pg",
  connection: {
    host: "*****",
    user: "*****",
    password:"****",
    database: "*****",
    ssl: "true",
    charset: "utf8"
  }
};

Using this config for initializing knex, which in turn initializes bookshelf.

var knex = require("knex")(config);
var bookshelf = require("bookshelf")(knex);

We now have successfully connected bookshelf with our database, and can now use it for making different requests.

Creating models

To interact with each table, we'll have to first make models for each table.
To keep things simple, we'll be interacting with a table named user.

var User = bookshelf.Model.extend({
  tableName: "user"
});

tableName is the minimum requirement for getting started, although we can add things like hasTimestamps (boolean) and custom functions to the model.

Now we can use this model to access the user table.

Making different routes

HTTP	CRUD	Route
GET	Read	/users/
GET	Read	/users/:email
POST	Create	/users/
PUT	Update	/users/:email
DELETE	Delete	/users/:email

GET /users/

app.get("/users", async (req, res) => {
  var users = await new User().fetchAll();
  res.json(users);
});

Response

[
    {
        "name": "john",
        "email": "john@example.com"
    },
    {
        "name": "bob",
        "email": "bob@example.com"
    }
]

GET /users/:email

app.get("/users/:email", async (req, res) => {
  var user = await User.where("email", email).fetch();
  res.json(user);
});

Response

{
    "name": "john",
    "email": "john@example.com"
}

POST /users/

app.post("/users", async (req, res) => {
  var user = await User.forge({
    name: req.query.name,
    email: req.query.email
  }).save();
  res.json(user);
});

Response

{
    "name": "doe",
    "email": "doe@example.com"
}

PUT /users/:email

app.put("/users/:email", async (req, res) => {
  var user = await User.where("email", req.params.email).save(
    { ...req.body },
    { patch: true }
  );
  res.json(user);
});

Response

{
    "name": "doe1",
    "email": "doe@example.com"
}

DELETE /users/:email

app.delete("/users/:email", async (req, res) => {
  var user = await User.where("email", req.params.email).destroy();
  res.json(user);
});

Response

{}

Relations

For explaining relations, we'll need another table, let it be a table named post.

Here the field email is a foreign key which refers to the email field of user table.

Let the data in post table initially be

[ 
 {  "id": "2",
    "title": "test2",
    "email": "john@example.com",
    "content": "lorem20" },
  { "id": "1",
    "title": "test",
    "email": "john@example.com",
    "content": "lorem10" 
  } 
]

To access the post table, we'll have to create a model for it. Since we also want to incorporate relations in it, we'll add a function named user to it.

var Post = bookshelf.Model.extend({
  tableName: "post",
  user() {
    return this.belongsTo(User, "email", "email");
  }
});

In the belongsTo(/belongsToMany/hasMany) method, the first argument is the Model with which our current model is associated with. The second and third arguments specify the fields through which the models are associated with (Foreign Key, Primary Key). In this case, both the fields are named email.

Now to access a post with its related data, we'll write

var posts = await Post.where("id", 1).fetch({ withRelated: ["user"] });
console.log(posts.related("user").toJSON());

Here "user" is the name of the function we made inside the Post model.

Response

{ 
   "name": "john",
   "email": "john@example.com"
}

Similarly, we can edit User model to reflect the relationship with post.

var User = bookshelf.Model.extend({
  tableName: "user",
  posts() {
    return this.hasMany(Post, "email", "email");
  }
});

To access posts related to a user

  var user = await User.where("email", "john@example.com").fetch({
    withRelated: ["posts"]
  });
  console.log(user.related("posts").toJSON());

Response

[ 
 {  "id": "2",
    "title": "test2",
    "email": "john@example.com",
    "content": "lorem20" },
  { "id": "1",
    "title": "test",
    "email": "john@example.com",
    "content": "lorem10" 
  } 
]

Repository

A fully working implementation of the application is available on my Github profile if anyone wants to refer.

projectescape / blogs-reference

A repository which contains the source complementing all the blogs I write

A crash course to Bookshelf.js

Code for this blog can be accessed here

Programmatic Navigation in React

Code for this blog can be accessed here

The Comprehensive Sequelize Cheatsheet

Markdown for this blog can be accessed here

View on GitHub

P.S.

This post officially marks the beginning of my blog writing endeavour to help me learn about things at a deeper level by writing blogs to help explain them to others(If that makes any sense!!). Any suggestions, edits, recommendations are more than welcome!

DEV Community: Aniket

Why I built my coding-agent tooling as a local proxy instead of hooks

Where to put it

What that one decision forced

What it cost

What's next

Can decision models like Jev and Laya route a coding agent?

How the router works

Setup

Prompt set

What Laya receives and returns

Results: the plumbing works

Results: the classifier never got confident

Results: the cheap model won anyway

What we're changing

Limitations

Try it or build on it

Does compacting tool output lower a coding agent's API bill?

How coding agents resend tool output

The idea: a cheaper assistant for the hosted model

Attempt 1: summarise every large output

Attempt 2: exact by default, compact only older output

Experiment setup and methodology

Environment

Prices used (July 2026, per million tokens)

Arms

Protocol

Results

Why it didn't pay: prompt-cache economics

The break-even condition

What broke along the way

Limitations

What's next

Try it or build on it

Your coding agent just read your API keys. I built a local check so they don't reach the model.

How I got here

How the check works

Which small models were actually good at this?

Try it yourself

Why a proxy, and not just a hook?

Help make it better

Major improvements made to monetize-npm-cli 🔥

Web Monetization for NPM packages!!

Note

Improvements !!

wrapper-coil-extension

- Switched to probabilistic revenue sharing

- No Focus stealing

- Restricted opening more tabs while content is being monetized

- Events are being fired and states are now being changed as expected

- Depreciated Timeout

monetize-npm-cli

- addListener, invokeListener and removeListener methods renamed to addEventListener, invokeEventListener and removeEventListener respectively

- Added walletHash and nameHash private variables to monetization object

- invokeEventListener is now working as expected and taking and passing one argument

- Initial state of all packages is now stopped

Web Monetization for NPM packages!!

What I built

monetize-npm-cli

getState

addEventListener

removeEventListener

wrapper-coil-extension

How is this better than npm fund

Submission Category:

Demo

Link to Code

monetize-npm-cli

projectescape / monetize-npm-cli

A CLI that helps monetize npm packages using the Web Monetization API

monetize-npm-cli

Install

Usage

Run file

Help

Login to your Provider

Logout from your Provider

List packages

API

wrapper-coil-extension

- `addListener`, `invokeListener` and `removeListener` methods renamed to `addEventListener`, `invokeEventListener` and `removeEventListener` respectively

- Added `walletHash` and `nameHash` private variables to monetization object

- `invokeEventListener` is now working as expected and taking and passing one argument

- Initial state of all packages is now `stopped`

`monetize-npm-cli`

`wrapper-coil-extension`

How is this better than `npm fund`

`monetize-npm-cli`

`wrapper-coil-extension`

`monetize-npm-cli`

`wrapper-coil-extension`